Da minha leitura das páginas da Esri, o Collector for ArcGIS está fortemente ligado a essa plataforma. Eu ficaria encantado em saber que estou errado sobre isso.
Tenho um grande interesse em aplicativos genéricos de coleta de dados móveis para dispositivos iOS e Android com GPS. Especialmente aqueles que podem coletar dados fora da cobertura e sincronizar quando voltarem à cobertura. Idealmente, eles também seriam capazes de armazenar em cache partes dos dados localmente para uso quando estiverem off-line.
O que eu imagino é um aplicativo baseado na Web que permita especificar seu layout de dados, restrições, etc. e que gerará o banco de dados back-end e permitirá o acesso por meio de uma API tranqüila.
O que eu preciso fazer é inserir dados de um formulário em um dispositivo móvel, de preferência iOS e Android, que atualizará as tabelas em um banco de dados back-end, potencialmente algo com extensões GIS, como PostGIS. Isso me permitiria incorporar facilmente os dados no QGIS. Ele deve poder trabalhar offline e muitas das áreas em que trabalhamos não têm cobertura 3G. Idealmente, você também poderá armazenar em cache os dados selecionados no dispositivo para uso offline. As integrações de mapas não são importantes.
Encontrei algumas boas soluções baseadas em nuvem, mas quero realmente algo em que tenha controle da coleta de dados de back-end, pois alguns dados são potencialmente sensíveis. por exemplo, relatar avistamentos de répteis raros que são uma ameaça de contrabando.
Quais são as alternativas para os aplicativos móveis colocarem dados no QGIS.
fonte
Respostas:
ODK
Como o @flippinGeo diz, o ODK é ótimo. Mas não é um produto integrado (ou seja, os formulários são configurados em uma área, a agregação é feita em outra e o aplicativo é apenas para Android). Porém, funciona de maneira fantástica, e nós a usamos no trabalho e é simples e rápido de usar. Hospedamos no AppEngine do Google e não custa basicamente nada, mesmo armazenando alguns milhares de fotos. Consigo enviar dados para uma tabela de fusão que pode ser visualizada com o Leaflet, consulte: http://maps.gcc.tas.gov.au/graffiti.html .
Fulcro
Atualmente, estou brincando com o Fulcrum , que não é de código aberto, mas é um bom produto SaaS que é razoavelmente barato e tem uma interface da web muito boa. Eu não gosto da API deles (embora não tenha me esforçado muito).
QField
Há também o QField for QGIS, que é o QGIS com uma interface simplificada para interação por toque. Ele suporta restrições definidas em projetos QGIS, formulários definidos em projetos QGIS e uma ampla variedade de provedores de dados on e offline. Entre eles PostGIS e GeoPackage. A sincronização com uma cópia offline de um banco de dados deve ser feita manualmente como uma etapa de preparação em um computador desktop com QGIS, mas um plug-in QGIS QFieldSync está disponível para facilitar o trabalho. Infelizmente, só é possível usá-lo no Android até agora, seria fácil portá-lo para o Windows e provavelmente também possível para o iOS.
Configurabilidade
O que a ESRI faz bem é que, se você tiver um geodatabase configurado com um domínio de recurso, publique essa tabela no ArcGIS Online e use o Collector, todos os seus formulários serão criados automaticamente. Se você precisar manipular ainda mais os dados após o envio usando a programação, poderá usar a API do ArcGIS for Python para obter dados dentro e fora do AGOL.
QGIS para Android
A outra resposta para essa pergunta foi sugerir o QGIS para Android, mas acho que é muito grande para o que você deseja fazer. Eu acho que uma interface mínima, com quase nenhum conteúdo espacial do lado da coleção, é a melhor, o que torna o ODK tão bom. Ele coleta um ponto, o suficiente, e a precisão do ponto, o que é importante, mas não coloca tudo em uma interface grande e completa do mapa, o que também é realmente importante para as pessoas que coletam informações, porque são NÃO GIS FOLKS!
Entrada
O Input é um aplicativo móvel gratuito e de código aberto baseado no QGIS. Está disponível para iOS e Android. A entrada é fornecida com a função de sincronização integrada, que permite que os usuários carreguem / baixem suas alterações quando houver uma conexão de rede. Os dados de entrada e a preparação do projeto são feitos no QGIS; portanto, todos os formatos de arquivo suportados no QGIS podem ser carregados no Input.
fonte
NextGIS Mobile, GIS móvel nativo para Android - http://nextgis.com/nextgis-mobile
Edição offline - marque.
Sincronização - verifique.
Cache de ladrilhos de varredura - verifique.
Conecta-se à instância do servidor da web (NextGIS Web) para carregar / baixar dados - verifique.
Muitas outras coisas, como formulários personalizáveis, adição de TMS, etc:
fonte
Embora tecnicamente não seja uma resposta para sua pergunta, "Existe um código aberto equivalente ...?", Essa é a base para uma solução.
O OGC está trabalhando em uma nova especificação para um contêiner de armazenamento, que está sendo votado agora (em janeiro de 2014), com esses tipos de fluxos de trabalho, especialmente móveis, em mente: GeoPackage .
É semelhante e originalmente baseado no Spatialite , um banco de dados espacial de plataforma simples, portátil e de arquivo simples. Uma vez / se a especificação for finalizada, a incorporação no QGIS provavelmente ocorrerá rapidamente, possivelmente para a versão 2.4, uma vez que já existe suporte preliminar via GDAL / OGR , um provedor espacial essencial no QGIS.
Você pode jogar com o formato agora, com suporte preliminar por meio dos conjuntos de ferramentas listados no site do OGC GeoPackage. Além desses, há um suporte atualizado recentemente na própria libspatialite, que pode ser compilada para iOS e Android , e via projeto Homebrew para Mac usando a fórmula libspatialite (use a opção --HEAD).
O novo lispatialite agora pode ser carregado com mais facilidade no SQLite como uma extensão, via qualquer ligação de idioma que você precisar .
Se você tiver os meios, considere ajudar a financiar o desenvolvimento de uma solução acoplada ao QGIS Web Client ou outro cliente baseado em OpenLayers .
fonte
Sua melhor aposta é o QGIS para Android: http://www.opengis.ch/2012/01/31/qgis-on-android-gets-gps-support/, mas não tenho certeza sobre seu status atual em relação ao rastreamento e sincronização.
Veja um exemplo de vídeo com um tablet Windows com rastreamento e sincronização de trabalho: http://www.youtube.com/watch?v=0WevRW4tbzs
fonte
Quanto ao código aberto, consulte o Open Data Kit (ODK). Eu o usei para grandes projetos de coleta de dados (mais de 10.000 envios neste momento) e é bastante fácil configurar o Postgres / Postgis para coleta em toda a empresa com o componente Agregado. As limitações incluem atualmente apenas o Android e não uma interface de mapeamento.
O desenvolvimento de formulários é baseado no padrão Xform e você pode fazer uma lógica bacana com seus formulários, como condicionais, agrupamentos e parâmetros de exibição de controle. Também pode ser executado sem um Postgres. Também suporta muitos relacionamentos se você estiver lidando com coleções mais complexas.
Suporta tipos de dados típicos, GPS, foto, vídeo e áudio. O suporte ao sensor também é bastante extenso.
fonte
Pensei em dar uma alternativa às respostas aqui, pois estamos fazendo algo semelhante. Temos planejadores de serviços públicos planejando futuros trabalhos de manutenção, e esse é o nosso processo. Lembre-se, esses caras definitivamente não são do GIS, e podemos ter sorte se eles já usaram um computador antes.
Em vez de uma plataforma web, estamos usando um aplicativo de desktop do Windows. Nosso aplicativo usa uma interface de mapa licenciada, embora você possa facilmente (e deveríamos ter) usado uma versão de código aberto como DotSpatial ou SharpMap para os componentes de mapeamento. O restante do aplicativo é apenas alguns formulários para controles de entrada cujos valores são mapeados para um shapefile que estamos usando no backend. Os shapefiles não são ótimos, mas são super compatíveis.
Também configuramos uma API em nosso servidor que lida com o download de novos recursos (por exemplo, encomendas, linhas de serviços públicos, etc.) e o upload de recursos coletados / editados. Portanto, o armazenamento em campo não importa, porque tudo é transmitido para / do uso de geoJSON e apenas analisado / desserializado em cada ponto final.
Esse processo exige um pouco mais de trabalho inicial, mas a versatilidade é bastante grande. Você pode simplificar a interface do aplicativo para que tudo o que o usuário precise fazer seja clicar em um rótulo (nome da camada), desenhar uma figura e preencher alguns campos. O resto é feito automaticamente por eles. Você pode ficar mais complexo se quiser e fazer automaticamente coisas para o usuário, como junção espacial, cordas GPS, validar entradas de campo etc., codificando-a no back-end.
Ponto da história .. Você pode usar componentes de código aberto para criar um aplicativo para lidar com tudo. As interfaces da Web terão algumas limitações, como limites para o armazenamento local, etc. Se você quiser algo mais complexo e realmente menos estúpido, isso pode ser feito, mas é preciso um pouco de esforço.
Eu estimaria que, se você soubesse exatamente o que queria fazer, seria possível montar uma versão viável do aplicativo de desktop e da interface da web em algumas semanas.
fonte