Comment utiliser PostGIS pour gérer des workflows de géotraitement complexes?

12

Notre organisation envisage de déplacer notre workflow de géotraitement vers PostGIS. Nous utilisons actuellement ArcGIS, avec une pléthore d'outils Python personnalisés utilisés dans ModelBuilder. Nous déplaçons la plupart de nos données dans PostGIS pour qu'elles soient utilisées par une variété d'applications, et nous demandons maintenant s'il est également judicieux d'y effectuer également le traitement des données.

Nous traitons les données pour qu'elles soient compatibles avec notre logiciel. Un client achète notre logiciel, nous donne ses données et nous les traitons pour les optimiser afin de les utiliser dans notre logiciel. Cela nous oblige à créer une variété d'outils pour gérer différentes qualités de données d'entrée. Nous ne pouvons pas nous attendre à recevoir des données dans un format ou un schéma particulier, nous créons donc des outils pour mapper les champs d'entrée aux champs de sortie, analyser des champs uniques en plusieurs champs, fusionner plusieurs jeux de données, etc. Nous effectuons également des jointures spatiales, des intersections, des espaces blancs. et concaténer des champs et de nombreuses autres opérations courantes. PostGIS semble parfaitement capable de répondre à tous nos besoins de traitement.

Pour ceux d'entre vous qui utilisent PostGIS pour faire votre traitement de données, avez-vous des conseils d'organisation, d'outils à utiliser, etc.?

l'utilisez-vous en conjonction avec le traitement python QGIS?
les gens utilisent-ils un ORM Python pour un traitement non Web? Je penche pour l'utilisation de GeoDjango car il dispose d'un Python ORM pour PostGIS. Notre test initial d'utilisation de PostGIS pour traiter des données contient de nombreux blocs de texte SQL volumineux en code Python et nous pensons que l'ORM GeoDjango peut aider à créer un code plus facile à gérer et lisible. Il y a aussi l' ORM GeoAlchemy qui interagit de manière similaire avec PostGIS, et ne semble pas être aussi spécifique au Web que Django.

Je n'ai pas entendu parler de personnes utilisant PostGIS pour faire du géotraitement autant que je vois des personnes utilisant QGIS ou ArcGIS, donc je veux savoir si c'est une alternative comparable.

— Tanneur
source

1

Est-ce que tout votre processus est "backend"? Je ne suis pas un utilisateur Django ou GeoDjango, mais je pense à ces produits uniquement pour le développement de sites Web (et plus de problèmes qu'ils n'en valent, à mon humble avis). Pourquoi pas juste un tas de scripts shell ou python exécutés sur la ligne de commande (Unix bien sûr) ou périodiquement via "cron"? (Moins clickey-clickey est toujours mieux dans mon esprit.) Vous voudrez probablement les organiser systématiquement, au moins par flux de données entrant. De plus, Postgis peut probablement découper et découper vos données sans QGIS - quels types d'opérations spécifiques avez-vous en tête?

— forkandwait

1

Oui, notre traitement est backend. Cependant, nous aurons éventuellement une carte Web OpenLayers pour que les clients puissent visualiser et modifier leurs données. Nous pouvons utiliser Django pour les comptes utilisateur et administrateur de l'application. Si c'est le cas, j'ai pensé que cela pourrait être une autre raison de se pencher sur GeoDjango pour le traitement, même si Django a été conçu principalement pour les sites Web. Cette présentation de traitement à grande échelle avec Django suggère que Django n'est pas seulement pour les sites Web: slideshare.net/dibau_naum_h/large-scale-processing-with-django

— Tanner

1

Pour le travail backend, j'utiliserais PostGIS, un petit ogr2ogr, un langage de script (Python, Ruby, Tcl, peu importe), et une ligne de commande unix. J'éviterais d'essayer de mélanger Django dans cela, sauf pour garder votre base de données aussi compatible que possible avec elle. Ensuite, mettez-y un frontal si vous en avez besoin. Ma règle est: moins clickey = plus productif (bien que les analystes SIG se sentent plus à l'aise avec la merde clickey-clickey ... je veux dire "interfaces intuitives").

— forkandwait

En ce qui concerne le partage de diapositives - cela semble incroyablement compliqué, et peut-être approprié si vous taxez votre puissance de traitement en essayant de suivre, mais sinon cauchemardesque à gérer.

— forkandwait

1

Quelques questions génériques etl qui peuvent vous être utiles: " Comparaisons spatiales ETL " et " Y a-t-il des alternatives fme sûres? "

— RyanKDalton

8

J'aime vraiment utiliser PostGIS à des fins de géotraitement.

Mes deux résons principaux sont:

1) Il est souvent beaucoup plus rapide d'effectuer des tâches complexes dans la base de données car vous obtenez l'aide du planificateur de requêtes pour faire les choses dans le bon ordre.

2) Enregistrez simplement les lignes sql que vous avez utilisées dans un fichier texte et vous avez une très bonne documentation de ce que vous avez fait.

Mon flux de travail, si les tâches impliquent un grand nombre d '"étapes" pour être quelque chose comme:
1- Construire des parties de la requête ou tout cela en fonction de la nature de la tâche
2- Tester la requête sur une petite partie de l'ensemble de données pour voir comment cela fonctionne
3- Faites quelques ajustements si nécessaire
4- Exécutez la requête sur l'ensemble de données
5- Enregistrez les lignes dans un fichier texte avec quelques notes.
Tout cela est souvent aussi rapide que de démarrer ArcGIS et d'attendre une licence du serveur de licences.

— Nicklas Avén
source

5

Nous utilisons PostGIS et une sorte d'environnement de programmation Python pour un certain nombre de services Web de géotraitement de production que nous avons développés; aucune plainte!

GeoDjango est un excellent choix si vous travaillez principalement (ou exclusivement) avec des fonctionnalités pour une application Web. Il ne prend pas en charge PostGIS Raster ou le type de données raster de PostGIS 2.0. Il vient nativement avec la dernière version de Django, maintenant. Vous pouvez compenser un manque de prise en charge raster et de robustesse globale en utilisant des requêtes SQL brutes personnalisées dans Django.

Pour des applications de géotraitement plus robustes, et en particulier si vous cherchez à utiliser un modèle relationnel objet, essayez GeoAlchemy2. La bibliothèque GeoAlchemy d'origine, qui étend SQLAlchemy, prend en charge les données d'entités; GeoAlchemy2 l'étend en fournissant un support (limité) pour le nouveau type de données raster dans PostGIS 2.0.

Et puis, il y a toujours les liaisons Python pour GDAL et OGR!

— Arthur
source

YMMV, mais je trouve que les bibliothèques relationnelles aux objets n'ajoutent vraiment rien à l'ancien SQL. Comme je l'ai dit dans un autre commentaire, il serait très intéressant d'entendre des détails.

— forkandwait

4

Je peux décrire une étude de cas: un service Web pour générer des entrées raster pour un modèle d'érosion post-incendie. Fondamentalement, un certain nombre de rasters doivent être sous-ensemble et ajoutés les uns aux autres. J'ai sélectionné GeoAlchemy2 (GA2) pour interfacer avec PostGIS, où les données sont stockées. À l'aide de GA2, je peux créer des requêtes PostGIS compactes et réutilisables. Une requête crée un produit «couverture terrestre brûlée» (reclassement d'une couverture terrestre, sous-ensemble). Ce produit est nécessaire seul pour certaines modélisations, mais il est également ajouté à un autre raster, une couche de sols, pour produire un troisième produit de sortie. GA2 me permet de mélanger, assortir et sérialiser en Python.

— Arthur

3

Bien que cela soit possible, il est difficile d'imaginer que vous voudriez faire beaucoup de géotraitement à l'intérieur d'un moteur de base de données ou d'une infrastructure Web. Je vous recommande de regarder les bibliothèques de code sous-jacentes - geos, proj.4 et gdal. Il existe des liaisons ou des bibliothèques Python pour les trois. Une autre option à examiner est le plugin de géotraitement Sextante pour QGIS, car il permet la construction de modèles / workflows.

Quelques autres réflexions:

N'excluez pas l'utilisation de PostGIS. Il offre de bonnes capacités de stockage et de serveur, et expose certaines fonctionnalités geos et proj.4 via SQL. Il fonctionne également bien avec les autres outils mentionnés: Django, QGIS et Python.

Outre l'utilisation possible du plugin Sextante susmentionné, QGIS est bon pour la visualisation, dispose de certains outils pour travailler avec postgres et comprend également une console Python.

Si vous recherchez ORM et que vous souhaitez un frontal web, Django le fera. Si cela ne vous dérange pas une interface moins que sexy, les pages d'administration vous donneront une interface CRUD avec relativement peu d'effort - même la modification de la géométrie si vous utilisez GeoDjango.

— Scro
source

2

Bien que je convienne que l'on n'utiliserait pas de cadre Web pour faire du géotraitement, je suis fortement en désaccord que l'on n'utiliserait pas PostGIS (ou un autre moteur de base de données) pour faire du géotraitement. Nous avons besoin de détails pour avancer dans la discussion, mais je fais une énorme quantité de découpage / découpage de géométrie et d'analyse ponctuelle en utilisant PostGIS et SQL.

— forkandwait

2

@forkandwait Oh, je suis d'accord avec vous sur PostGIS. Cependant, j'ai eu l'impression qu'ils utilisent un certain nombre de petits scripts qu'ils peuvent enchaîner différemment pour chaque projet. Mon objectif était de les amener à enquêter sur les bibliothèques sous-jacentes afin de pouvoir choisir l'environnement qui fonctionnait le mieux.

— Scro

3

Jetez un œil à ETL , en particulier à FME pour les opérations spatiales (ou à la GeoKettle open source ).

J'aime vraiment utiliser FME, car il crée un flux de travail visuel, et vous pouvez séparer la logique des opérations spatiales, des jointures, des fusions ... tout, et vous pouvez travailler avec des formats autres que des bases de données et différentes bases de données ... Vous pouvez faire beaucoup et facile et rapide. Si vous avez de l'expérience avec le constructeur de modèles, vous le récupérerez rapidement, et il y a beaucoup de documentation en ligne.

Le seul inconvénient de FME est qu'il coûte de l'argent. Mais je pense que ça vaut le coup.

Une alternative à l'utilisation de FME est probablement GDAL et OGR avec peut-être Python pour les lier ensemble. Ou, comme vous le dites, tout faire dans PostgreSQL. Je pense qu'un ETL a un rôle important dans la gestion des données spatiales, et il fait beaucoup de choses que vous ne pouvez pas faire uniquement dans votre base de données.

Je ne l'ai pas utilisé, mais GeoServer fournit une implémentation de WPS , je ne l'ai pas utilisée, mais d'autres peuvent commenter comment cela pourrait vous être utile?

Je ne peux pas commenter l'utilisation de GeoDjango, mais je pensais que c'était plus un CMS, comme un frontal pour visualiser les données.

— Alex Leith
source