Como usar o PostGIS para lidar com fluxos de trabalho de geoprocessamento complexos?

12

Nossa organização está considerando mudar nosso fluxo de trabalho de geoprocessamento para o PostGIS. Atualmente, estamos usando o ArcGIS, com uma infinidade de ferramentas Python personalizadas usadas no ModelBuilder. Estamos movendo a maioria dos nossos dados para o PostGIS para serem consumidos por uma variedade de aplicativos, e agora estamos perguntando se também faz sentido executar o processamento de dados lá.

Processamos os dados para serem compatíveis com o nosso software. Um cliente compra nosso software, nos fornece seus dados e processamos para ser otimizado para uso em nosso software. Isso exige que construamos uma variedade de ferramentas para lidar com diferentes qualidades dos dados de entrada. Não podemos esperar receber dados em um formato ou esquema específico, por isso desenvolvemos ferramentas para mapear campos de entrada para campos de saída, analisar campos únicos em vários campos, mesclar vários conjuntos de dados, etc. Também realizamos junções espaciais, interseções, aparar espaços em branco e concatenar campos e muitas outras operações comuns. O PostGIS parece ser perfeitamente capaz de executar todas as nossas necessidades de processamento.

Para aqueles que usam o PostGIS para o processamento de dados, você tem algum conselho para organização, ferramentas para usar etc.?

você o usa em conjunto com o processamento python QGIS?
as pessoas estão usando um ORM Python para processamento não Web? Eu tenho me inclinado a usar o GeoDjango, pois ele possui um Python ORM para PostGIS. Nosso teste inicial do uso do PostGIS para processar dados possui muitos grandes blocos de texto SQL no código Python e estamos pensando que o ORM do GeoDjango pode ajudar na criação de código mais gerenciável e legível. Há também o ORo do GeoAlchemy que interage de maneira semelhante com o PostGIS e não parece ser tão específico da Web quanto o Django.

Eu nunca ouvi falar de pessoas que usam o PostGIS para fazer geoprocessamento tanto quanto as pessoas que usam QGIS ou ArcGIS, por isso quero saber se é uma alternativa comparável.

— Curtidor
fonte

1

Todo o seu processo é "back-end"? Não sou usuário do Django ou do GeoDjango, mas penso nesses produtos apenas para desenvolver sites (e mais problemas do que valem, IMHO). Por que não apenas um monte de scripts shell ou python executados na linha de comando (obviamente do Unix) ou periodicamente via "cron"? (Menos clickey-clickey é sempre melhor em minha mente.) Você provavelmente desejaria organizá-los sistematicamente, pelo menos pelo fluxo de dados recebido. Além disso, o Postgis provavelmente pode fatiar e cortar seus dados sem o QGIS - que tipos específicos de operações você tem em mente?

— forkandwait

1

Sim, nosso processamento é de back-end. No entanto, teremos um mapa da Web OpenLayers para que os clientes visualizem e editem seus dados. Podemos usar o Django para as contas de usuário e administrador do aplicativo. Nesse caso, achei que poderia ser outro motivo para analisar o GeoDjango para processamento, mesmo que o Django tenha sido construído principalmente para sites. Esta escala Processamento com Django apresentação Grande sugerem que Django não é apenas para web sites: slideshare.net/dibau_naum_h/large-scale-processing-with-django

— Tanner

1

Para o trabalho de back-end, eu usaria o PostGIS, um pouco de ogr2ogr, uma linguagem de script (Python, Ruby, Tcl, o que for) e uma linha de comando unix. Eu evitaria tentar misturar o Django nisso, exceto para manter seu banco de dados o mais compatível possível. Depois, coloque um front-end, se necessário. Minha regra é: menos clickey = mais produtivo (embora os analistas de GIS se sintam mais à vontade com essa porcaria de clickey-clickey ... quero dizer "interfaces intuitivas").

— forkandwait

Em relação ao compartilhamento de slides - isso parece loucamente complicado e talvez apropriado se você estiver sobrecarregando seu poder de processamento tentando acompanhar, mas, de outra forma, é um pesadelo.

— forkandwait

1

Um casal de genéricos ETL perguntas que podem ser úteis: " comparações de Spatial ETL " e " Existe alguma alternativa FME seguros? "

— RyanKDalton

8

Eu realmente gosto de usar o PostGIS para fins de geoprocessamento.

Minhas duas principais ressonâncias são:

1) Geralmente, é muito mais rápido executar tarefas complexas no banco de dados, porque você recebe a ajuda do planejador de consultas para fazer as coisas na ordem certa.

2) Apenas salve as linhas sql usadas em um arquivo de texto e você terá uma documentação muito boa do que fez.

Meu fluxo de trabalho, se as tarefas envolverem muitas "etapas", costumam ser algo como:
1- Crie partes da consulta ou todas elas, dependendo da natureza da tarefa
2- Teste a consulta em uma pequena parte do conjunto de dados para ver como ele funciona
3- Faça alguns ajustes, se necessário
4- Execute a consulta em todo o conjunto de dados
5- Salve as linhas em um arquivo de texto com algumas anotações.
Geralmente, tudo isso é tão rápido quanto iniciar o ArcGIS e aguardar uma licença do servidor de licenças.

— Nicklas Avén
fonte

5

Usamos o PostGIS e algum tipo de ambiente de programação Python para vários serviços web de geoprocessamento de produção que desenvolvemos; sem queixas!

O GeoDjango é uma ótima opção se você estiver trabalhando principalmente (ou exclusivamente) com recursos para um aplicativo da web. Ele não suporta o tipo de dados raster do PostGIS Raster ou PostGIS 2.0. Ele vem nativamente com a versão mais recente do Django, agora. Você pode compensar a falta de suporte a varredura e a robustez geral usando consultas SQL brutas e personalizadas no Django.

Para aplicativos de geoprocessamento mais robustos e, principalmente, se você deseja usar um modelo relacional de objetos, tente GeoAlchemy2. A biblioteca GeoAlchemy original, que estende o SQLAlchemy, fornece suporte para dados de recursos; O GeoAlchemy2 o estende, fornecendo suporte (limitado) ao novo tipo de dados raster no PostGIS 2.0.

E sempre há as ligações Python para GDAL e OGR!

— Arthur
fonte

YMMV, mas acho que as bibliotecas objeto-relacionais realmente não adicionam nada ao SQL antigo comum. Como eu disse em outro comentário, seria mais interessante ouvir detalhes.

— forkandwait

4

Posso descrever um estudo de caso: um serviço da Web para gerar entradas de varredura para um modelo de erosão pós-incêndio. Basicamente, vários rasters precisam ser subconjuntos e adicionados um ao outro. Selecionei GeoAlchemy2 (GA2) para fazer interface com o PostGIS, onde os dados são armazenados. Usando o GA2, posso criar consultas PostGIS compactas e reutilizáveis. Uma consulta cria um produto "cobertura da terra queimada" (uma reclasse de uma cobertura da terra, subconjunto). Este produto é necessário por si só para modelagem, mas também é adicionado a outra varredura, uma camada de solo, para produzir um terceiro produto de saída. O GA2 me permite misturar, combinar e serializar em Python.

— Arthur

3

Embora seja possível, é difícil imaginar que você queira fazer muito geoprocessamento dentro de um mecanismo de banco de dados ou de uma estrutura da web. Eu recomendo que você analise as bibliotecas de código subjacentes - geos, proj.4 e gdal. Existem ligações ou bibliotecas Python para os três. Outra opção para analisar é o plug-in de geoprocesso Sextante para QGIS, pois permite a criação de modelo / fluxo de trabalho.

Alguns outros pensamentos:

Não descarte o uso do PostGIS. Ele fornece boas capacidades de armazenamento e servidor e expõe algumas funcionalidades geo e proj.4 através do SQL. Também funciona bem com as outras ferramentas mencionadas: Django, QGIS e Python.

Além do possível uso do plug-in Sextante mencionado acima, o QGIS é bom para visualização, possui algumas ferramentas para trabalhar com o postgres e também inclui um console Python.

Se você está procurando por ORM e deseja um front end da Web, o Django fará isso. Se você não se importa com uma interface nada sexy, as páginas de administração oferecem uma interface CRUD com relativamente pouco esforço - até a edição de geometria se você usar o GeoDjango.

— Scro
fonte

2

Embora eu concorde que não seria usada uma estrutura da Web para fazer o geoprocessamento, discordo totalmente de que não seria usado o PostGIS (ou outro mecanismo de banco de dados) para fazer o geoprocessamento. Precisamos de detalhes para avançar na discussão, mas eu faço uma enorme quantidade de fatias / cubos de geometria e análises point-in-poly usando PostGIS e SQL.

— forkandwait

2

@forkandwait Oh, eu concordo com você no PostGIS. No entanto, tive a impressão de que eles usam vários scripts pequenos que podem ser encadeados de maneira diferente para cada projeto. Meu objetivo era levá-los a investigar as bibliotecas subjacentes para que pudessem escolher o ambiente que melhor funcionasse.

— Scro

3

Veja o ETL , especificamente o FME para operações espaciais (ou o GeoKettle de código aberto ).

Eu realmente gosto de usar o FME, pois ele cria um fluxo de trabalho visual, e você pode separar a lógica para operações espaciais, unir, mesclar ... tudo, e você pode trabalhar com formatos que não são de banco de dados e com diferentes bancos de dados ... faça muito, fácil e rápido. Se você tem experiência com o construtor de modelos, você o encontrará rapidamente, além de haver muita documentação online.

A única desvantagem do FME é que custa dinheiro. Mas acho que vale a pena.

Uma alternativa ao uso do FME é provavelmente o GDAL e o OGR, juntamente com o Python, talvez, para conectá-lo. Ou, como você diz, fazendo tudo isso no PostgreSQL. Eu acho que um ETL tem um forte papel na disputa de dados espaciais e faz muito que você não pode fazer apenas no seu banco de dados.

Não usei, mas o GeoServer fornece uma implementação do WPS , não usei isso, mas outros podem comentar sobre como isso pode ser útil para você?

Não posso comentar sobre o uso do GeoDjango, mas achei que era mais um CMS, como um front-end para visualização de dados.

— Alex Leith
fonte