¿Cómo usar PostGIS para manejar flujos de trabajo de geoprocesamiento complejos?

12

Nuestra organización está considerando trasladar nuestro flujo de trabajo de geoprocesamiento a PostGIS. Actualmente estamos utilizando ArcGIS, con una gran cantidad de herramientas Python personalizadas utilizadas en ModelBuilder. Estamos trasladando la mayoría de nuestros datos a PostGIS para que sean consumidos por una variedad de aplicaciones, y ahora estamos preguntando si también tiene sentido realizar el procesamiento de datos allí.

Procesamos datos para que sean compatibles con nuestro software. Un cliente compra nuestro software, nos proporciona sus datos y los procesamos para que se optimicen para su uso en nuestro software. Esto requiere que construyamos una variedad de herramientas para manejar diferentes calidades de datos de entrada. No podemos esperar recibir datos en un formato o esquema particular, por lo que creamos herramientas para asignar campos de entrada a campos de salida, analizar campos individuales en múltiples campos, fusionar múltiples conjuntos de datos, etc. También realizamos uniones espaciales, intersecciones, recortar espacios en blanco y concatenar campos, y muchas otras operaciones comunes. PostGIS parece ser perfectamente capaz de realizar todas nuestras necesidades de procesamiento.

Para aquellos de ustedes que usan PostGIS para procesar sus datos, ¿tienen algún consejo sobre organización, herramientas para usar, etc.?

¿Lo usa junto con el procesamiento QGIS python?
¿Las personas utilizan un ORM de Python para el procesamiento no web? Me he inclinado hacia el uso de GeoDjango ya que tiene un ORM de Python para PostGIS. Nuestra prueba inicial de uso de PostGIS para procesar datos tiene muchos bloques de texto SQL grandes en código Python y estamos pensando que GeoDjango ORM puede ayudar a crear un código más manejable y legible. También está el GeoAlchemy ORM que interactúa de manera similar con PostGIS, y no parece ser tan específico de la web como lo es Django.

No he oído hablar de personas que usan PostGIS para hacer geoprocesamiento tanto como veo personas que usan QGIS o ArcGIS, por lo que quiero saber si es una alternativa comparable.

— Curtidor
fuente

1

¿Todo su proceso es "backend"? No soy un usuario de Django o GeoDjango, pero pienso en esos productos solo para el desarrollo de sitios web (y más problemas de lo que valen, en mi humilde opinión). ¿Por qué no solo un montón de scripts de shell o python se ejecutan en la línea de comando (Unix, por supuesto) o periódicamente a través de "cron"? (Menos clickey-clickey siempre es mejor en mi mente.) Probablemente quiera organizarlos sistemáticamente, al menos por flujo de datos entrantes. Además, Postgis probablemente puede cortar y cortar sus datos sin QGIS: ¿qué tipos específicos de operaciones tiene en mente?

— Forkandwait

1

Sí, nuestro procesamiento es backend. Sin embargo, eventualmente tendremos un mapa web de OpenLayers para que los clientes puedan ver y editar sus datos. Podríamos usar Django para las cuentas de usuario y administrador de la aplicación. Si es así, pensé que esa podría ser otra razón para buscar en GeoDjango para el procesamiento, a pesar de que Django fue creado principalmente para sitios web. Esta presentación de procesamiento a gran escala con Django sugiere que Django no es solo para sitios web: slideshare.net/dibau_naum_h/large-scale-processing-with-django

— Tanner

1

Para el trabajo de backend, usaría PostGIS, un poco de ogr2ogr, un lenguaje de script (Python, Ruby, Tcl, lo que sea) y una línea de comandos de Unix. Evitaría intentar mezclar Django en eso, excepto para mantener su base de datos lo más compatible posible con ella. Luego, más adelante, póngale un front end si lo necesita. Mi regla es: menos clickey = más productivo (aunque los analistas de SIG se sienten más cómodos con la basura clickey-clickey ... me refiero a "interfaces intuitivas").

— Forkandwait

Con respecto a la diapositiva compartida, que parece locamente complicada, y tal vez apropiada si está gravando su capacidad de procesamiento tratando de mantenerse al día, pero de lo contrario es una pesadilla para administrar.

— espere

1

Un par de genéricos ETL preguntas que le puede ser útil: " comparaciones espaciales ETL " y " ¿Hay alguna alternativa fme seguras? "

— RyanKDalton

8

Realmente me gusta usar PostGIS para fines de geoprocesamiento.

Mis dos resons principales son:

1) A menudo es mucho más rápido realizar tareas complejas en la base de datos porque obtiene la ayuda del planificador de consultas para hacer las cosas en el orden correcto.

2) Simplemente guarde las líneas sql que utilizó en un archivo de texto y tendrá una muy buena documentación de lo que ha hecho.

Mi flujo de trabajo, si las tareas involucran muchos "pasos", solía ser algo como:
1- Construir partes de la consulta o todas dependiendo de la naturaleza de la tarea
2- Probar la consulta en una pequeña parte del conjunto de datos para vea cómo funciona
3- Realice algunos ajustes si es necesario
4- Ejecute la consulta en todo el conjunto de datos
5- Guarde las líneas en un archivo de texto con algunas notas.
Todo esto suele ser tan rápido como iniciar ArcGIS y esperar una licencia del servidor de licencias.

— Nicklas Avén
fuente

5

Utilizamos PostGIS y algún tipo de entorno de programación Python para una serie de servicios web de geoprocesamiento de producción que hemos desarrollado; ¡sin quejas!

GeoDjango es una gran opción si está trabajando principalmente (o exclusivamente) con funciones para una aplicación web. No es compatible con el tipo de datos de trama PostGIS Raster o PostGIS 2.0. Viene de forma nativa con la última versión de Django, ahora. Puede compensar la falta de soporte de ráster y la solidez general mediante el uso de consultas SQL sin formato personalizadas en Django.

Para aplicaciones de geoprocesamiento más robustas, y particularmente si está buscando usar un modelo relacional de objetos, pruebe GeoAlchemy2. La biblioteca original de GeoAlchemy, que extiende SQLAlchemy, proporciona soporte para datos de características; GeoAlchemy2 lo extiende al proporcionar soporte (limitado) para el nuevo tipo de datos ráster en PostGIS 2.0.

Y luego, ¡siempre están los enlaces de Python para GDAL y OGR!

— Arturo
fuente

YMMV, pero encuentro que las bibliotecas relacionales de objetos realmente no agregan nada a SQL antiguo simple. Como dije en otro comentario, sería muy interesante escuchar detalles.

— forkandwait

44

Puedo describir un caso de estudio: un servicio web para generar entradas ráster para un modelo de erosión posterior al incendio. Básicamente, varios rásteres necesitan ser subconjuntos y agregarse entre sí. Seleccioné GeoAlchemy2 (GA2) para interactuar con PostGIS, donde se almacenan los datos. Con GA2, puedo crear consultas compactas y reutilizables de PostGIS. Una consulta crea un producto de "cobertura de tierra quemada" (una reclasificación de una cubierta de tierra, subconjunto). Este producto se necesita solo para algunos modelos, pero también se agrega a otro ráster, una capa de suelo, para producir un tercer producto de salida. GA2 me permite mezclar, combinar y serializar en Python.

— Arthur

3

Aunque es posible, es difícil imaginar que desearía hacer mucho geoprocesamiento dentro de un motor de base de datos o un marco web. Le recomiendo que mire las bibliotecas de código subyacentes: geos, proj.4 y gdal. Hay enlaces o bibliotecas de Python para los tres. Otra opción a considerar es el complemento de geoprocesamiento Sextante para QGIS, ya que permite la construcción de modelos / flujos de trabajo.

Algunos otros pensamientos:

No descarte el uso de PostGIS. Proporciona buenas capacidades de almacenamiento y servidor, y expone algunas funciones geos y proj.4 a través de SQL. También funciona bien con las otras herramientas mencionadas: Django, QGIS y Python.

Además del posible uso del plugin Sextante mencionado anteriormente, QGIS es bueno para la visualización, tiene algunas herramientas para trabajar con postgres y también incluye una consola Python.

Si está buscando ORM y quiere un front-end web, Django lo hará. Si no le importa una interfaz poco atractiva, las páginas de administración le proporcionarán una interfaz CRUD con relativamente poco esfuerzo, incluso la edición de geometría si usa GeoDjango.

— Scro
fuente

2

Si bien estoy de acuerdo en que uno no usaría un marco web para hacer geoprocesamiento, no estoy de acuerdo con la idea de que uno no usaría PostGIS (u otro motor de base de datos) para hacer geoprocesamiento. Necesitamos detalles para avanzar en la discusión, pero hago una gran cantidad de corte / corte de geometría y análisis de punto en poli usando PostGIS y SQL.

— espere el

2

@forkandwait Oh, estoy de acuerdo contigo en PostGIS. Sin embargo, tuve la impresión de que usan una serie de pequeños scripts que pueden encadenar de manera diferente para cada proyecto. Mi objetivo era lograr que investigaran las bibliotecas subyacentes para que pudieran elegir el entorno que funcionara mejor.

— Scro

3

Eche un vistazo a ETL , específicamente, FME para operaciones espaciales (o GeoKettle de código abierto ).

Realmente me gusta usar FME, ya que crea un flujo de trabajo visual, y puede separar la lógica para operaciones espaciales, uniones, fusiones ... todo, y puede trabajar con formatos que no son de base de datos y diferentes bases de datos ... Puede hacer mucho, fácil y rápido. Si tiene experiencia con el creador de modelos, lo recogerá rápidamente, además hay mucha documentación en línea.

La única desventaja de FME es que cuesta dinero. Pero creo que vale la pena.

Una alternativa al uso de FME es probablemente GDAL y OGR junto con quizás Python para unirlos. O, como dices, hacerlo todo en PostgreSQL. Creo que un ETL tiene un papel importante en la disputa de datos espaciales, y hace mucho que no puedes hacer solo en tu base de datos.

No lo he usado, pero GeoServer proporciona una implementación de WPS , no lo he usado, pero otros pueden comentar sobre cómo esto podría ser útil para usted.

No puedo comentar sobre el uso de GeoDjango, pero pensé que era más un CMS, como un front-end para ver datos.

— Alex Leith
fuente