Wie verwende ich PostGIS für komplexe Geoverarbeitungs-Workflows?

Unsere Organisation erwägt, unseren Geoverarbeitungsworkflow auf PostGIS zu verlagern. Derzeit verwenden wir ArcGIS mit einer Vielzahl benutzerdefinierter Python-Tools, die in ModelBuilder verwendet werden. Wir verlagern die meisten unserer Daten nach PostGIS, um sie für eine Vielzahl von Apps zu nutzen, und fragen jetzt, ob es auch Sinn macht, die Datenverarbeitung dort durchzuführen.

Wir verarbeiten Daten, um mit unserer Software kompatibel zu sein. Ein Kunde kauft unsere Software, gibt uns seine Daten und wir verarbeiten sie, um sie für die Verwendung in unserer Software zu optimieren. Dazu müssen wir eine Vielzahl von Werkzeugen erstellen, um mit unterschiedlichen Qualitäten von Eingabedaten umzugehen. Wir können nicht erwarten, Daten in einem bestimmten Format oder Schema zu erhalten. Daher erstellen wir Tools, um Eingabefelder Ausgabefeldern zuzuordnen, einzelne Felder in mehrere Felder zu zerlegen, mehrere Datasets zusammenzuführen usw. Außerdem führen wir räumliche Verknüpfungen, Schnittpunkte und das Zuschneiden von Leerzeichen durch und verketten Felder und viele andere gängige Operationen. PostGIS scheint in der Lage zu sein, alle unsere Verarbeitungsanforderungen zu erfüllen.

Haben Sie für diejenigen unter Ihnen, die PostGIS für die Datenverarbeitung verwenden, Tipps zur Organisation, zu Tools usw.?

• Verwenden Sie es in Verbindung mit der QGIS-Python-Verarbeitung?
• Verwenden Benutzer einen Python-ORM für die Verarbeitung außerhalb des Webs? Ich neige dazu, GeoDjango zu verwenden, da es ein Python-ORM für PostGIS hat. Unser erster Test mit PostGIS zur Verarbeitung von Daten enthält viele große SQL-Textblöcke in Python-Code. Wir sind der Meinung, dass der GeoDjango-ORM bei der Erstellung von besser verwaltbarem und lesbarem Code hilfreich sein kann. Es gibt auch das GeoAlchemy ORM, das in ähnlicher Weise mit PostGIS interagiert und anscheinend nicht so webspezifisch ist wie Django.

Ich habe noch nicht so viel von Leuten gehört, die PostGIS für die Geoverarbeitung verwenden, wie ich sie mit QGIS oder ArcGIS sehe. Daher möchte ich wissen, ob es sich um eine vergleichbare Alternative handelt.

Ich benutze PostGIS sehr gerne für Geoverarbeitungszwecke.

Meine zwei Hauptgründe sind:

1) Es ist oft sehr viel schneller, komplexe Aufgaben in der Datenbank zu erledigen, da Sie die Hilfe des Abfrageplaners erhalten, um die Dinge in der richtigen Reihenfolge zu erledigen.

2) Speichern Sie einfach die SQL-Zeilen, die Sie in einer Textdatei verwendet haben, und Sie haben eine sehr gute Dokumentation dessen, was Sie getan haben.

Mein Workflow, wenn die Aufgaben viele "Schritte" beinhalten, sieht so aus:
1- Erstellen Sie Teile der Abfrage oder alles davon, je nach Art der Aufgabe.
2- Testen Sie die Abfrage an einem kleinen Teil des Datensatzes Sehen Sie, wie es funktioniert.
3-
Führen Sie bei Bedarf einige Optimierungen durch. 4- Führen Sie die Abfrage für den gesamten Datensatz aus.
5- Speichern Sie die Zeilen in einer Textdatei mit einigen Notizen.
All dies ist häufig ungefähr so ​​schnell wie das Starten von ArcGIS und das Warten auf eine Lizenz vom Lizenzserver.

Wir verwenden PostGIS und eine Art Python-Programmierumgebung für eine Reihe von Geoverarbeitungs-Webservices, die wir entwickelt haben. keine Beschwerden!

GeoDjango ist eine gute Wahl, wenn Sie hauptsächlich (oder ausschließlich) mit Funktionen für eine Webanwendung arbeiten. PostGIS Raster oder PostGIS 2.0-Rasterdatentyp werden nicht unterstützt. Es ist ab sofort in der neuesten Version von Django verfügbar. Sie können einen Mangel an Rasterunterstützung und allgemeiner Robustheit ausgleichen, indem Sie benutzerdefinierte, unformatierte SQL-Abfragen in Django verwenden.

Für robustere Geoverarbeitungsanwendungen und insbesondere, wenn Sie ein objektrelationales Modell verwenden möchten, versuchen Sie GeoAlchemy2. Die ursprüngliche GeoAlchemy-Bibliothek, die SQLAlchemy erweitert, bietet Unterstützung für Feature-Daten. GeoAlchemy2 erweitert es um die (eingeschränkte) Unterstützung des neuen Raster-Datentyps in PostGIS 2.0.

Und dann gibt es immer die Python-Bindungen für GDAL und OGR!

Obwohl dies möglich ist, ist es schwer vorstellbar, dass Sie viel Geoverarbeitung in einem Datenbankmodul oder einem Webframework durchführen möchten. Ich empfehle Ihnen, sich die zugrunde liegenden Codebibliotheken anzusehen - geos, proj.4 und gdal. Für alle drei gibt es Python-Bindungen oder -Bibliotheken. Eine weitere Option, die untersucht werden sollte, ist das Sextante-Geoverarbeitungs-Plugin für QGIS, das die Erstellung von Modellen und Workflows ermöglicht.

Einige andere Gedanken:

Schließen Sie die Verwendung von PostGIS nicht aus. Es bietet gute Speicher- und Serverfunktionen und stellt einige Geo- und Proj.4-Funktionen über SQL zur Verfügung. Es spielt sich auch gut mit den anderen erwähnten Werkzeugen: Django, QGIS und Python.

Neben der möglichen Verwendung des oben genannten Sextante-Plugins ist QGIS gut für die Visualisierung geeignet, verfügt über einige Tools für die Arbeit mit Postgres und enthält auch eine Python-Konsole.

Wenn Sie nach ORM suchen und ein Web-Frontend möchten, wird Django dies tun. Wenn Ihnen eine weniger als sexy Benutzeroberfläche nichts ausmacht, erhalten Sie auf den Administrationsseiten mit relativ geringem Aufwand eine CRUD-Benutzeroberfläche - sogar die Geometriebearbeitung, wenn Sie GeoDjango verwenden.

Werfen Sie einen Blick auf ETL , insbesondere FME für räumliche Operationen (oder Open Source GeoKettle ).

Ich mag die Verwendung von FME sehr, da sie einen visuellen Workflow erstellt und Sie die Logik für räumliche Operationen, Verknüpfungen, Zusammenführungen usw. aufteilen und mit Nicht-Datenbankformaten und verschiedenen Datenbanken arbeiten können mach viel und einfach und schnell. Wenn Sie Erfahrung mit Modellbau haben, werden Sie diese schnell erlernen, und es ist eine Menge Dokumentation online.

Der einzige Nachteil von FME ist, dass es Geld kostet. Aber ich denke es lohnt sich.

Eine Alternative zur Verwendung von FME ist wahrscheinlich GDAL und OGR zusammen mit vielleicht Python, um es zusammenzubinden. Oder, wie Sie sagen, alles in PostgreSQL. Ich denke, eine ETL spielt eine wichtige Rolle beim Verwirren von Geodaten und leistet eine Menge, die Sie nicht nur in Ihrer Datenbank tun können.

Ich habe es nicht verwendet, aber GeoServer bietet eine Implementierung von WPS . Ich habe es nicht verwendet, aber andere können kommentieren, wie dies für Sie nützlich sein könnte.

Ich kann die Verwendung von GeoDjango nicht kommentieren, aber ich dachte, es sei eher ein CMS, wie ein Front-End zum Anzeigen von Daten.