Versionskontrollsystem für Geodaten implementieren? [geschlossen]

Nicht, dass ich hier sofort eine richtige Antwort benötige, aber ich habe in letzter Zeit einige Bemühungen gesehen, das Konzept der "(verteilten) Versionskontrollsysteme" für geografische Daten einzuführen. Einige (mir bekannte) Beispiele sind die drei Whitepapers von OpenGeo ( 1 , 2 & 3 ) und das Projekt " Geosynkronisering (Geosyncronization)" von norwegischen GIS-Softwareanbietern und der Norwegian Mapping Agency. Ich habe auch eine verteilte Versionierung von Geodaten gefunden. , in denen GeoGit (von OpenGeo) erwähnt wird und Versionskontrolle auf ArcGIS ModelBuilder-Modelle angewendet wird? Informationen zur Versionskontrolle in ArcGIS.

Als Entwickler weiß ich (zumindest genug, um sie nutzen zu können), wie Versionskontrollsysteme für Quellcode (wie SVN und Git) funktionieren, und mein Hintergrund in der Geomatik zeigt mir, dass es mit geografischen Daten einige einzigartige Herausforderungen gibt, die die Ansatz, der der Art und Weise, wie Quellcode (der im Grunde Text ist) behandelt wird, nicht ganz ähnlich ist.

Was sind die Herausforderungen beim Umgang mit (d) VCS für geografische Daten, wie würden Sie sie lösen, brauchen wir sie und gibt es andere Versuche, diese Probleme zu lösen, als die von mir erwähnten?

Ich weiß, dass die OpenGeo-Whitepapers einige meiner Fragen beantworten werden, aber ich bin wirklich auf der Suche nach einer "pädagogischeren" Antwort im Stil von "Sag mir, dass ich wie ein Zehnjähriger bin" Ich kann Menschen auf eine großartige Erklärung der Herausforderungen und Lösungen verweisen, die geografische Daten mit sich bringen.

Ich hoffe, dass jemand mit einigen Einsichten sich Zeit nimmt, um einige Gedanken zu diesem Thema zu machen, da ich sagte, ich suche derzeit nicht nach einer Lösung für ein bestimmtes Problem, aber dieses Thema interessiert mich.

Wir arbeiten derzeit an einem kompletten Redesign unserer Geodatastores. Ich muss sagen, dass ihre Entwicklung bis jetzt mehr als 20 Jahre gedauert hat. Wir haben die folgenden Schlüsselmerkmale im Geodatenmanagement identifiziert:

• gleichzeitige Bearbeitung
• Berechtigungen zum Lesen oder Schreiben von Teilen von Daten
• Hot-Update beim Ausführen von Diensten, die auf Daten basieren (Transaktions- und ACID-Paradigma)
• internes und externes Schema (das Ändern des internen Schemas sollte sich nicht auf Dienste auswirken)
• Möglichkeit, große Datenmengen (Terabyte Raster und Hunderte Gigabyte Vektordaten) zu speichern und darauf zuzugreifen
• Datenkonsistenz zwischen verschiedenen Ebenen (jedes Paket gehört zu einem Bezirk usw.)

Wir haben die folgenden Ansätze bewertet, hier ist was ich dazu sagen kann:

1. ESRI Enterprise Geodatabase(ArcGIS 10.1); So ziemlich dasselbe wie zuvor (SDE), jedoch mit umfassender Nutzung der Versionierungsfunktion zur Abwicklung von Transaktionen. Aber es ist einfach keine Enterprise-Geodatabase. Meiner Meinung nach arbeitet SDE nur in einer Arbeitsgruppe als Geodatenserver, auf dem von 8:00 bis 20:00 Uhr gearbeitet wird. Sie können es dann für Wartungsaufgaben offline schalten. Transaktions-Commit (Versionsabgleich und Versionsübertragung in ESRI-Sprache), Replikation usw. Wenn Sie auf diesen Daten Dienste aufbauen, müssen Sie eine Staging-Datenbank (in der die Arbeit erledigt ist) und eine replizierte Produktionsdatenbank verwalten. Dies ist so ziemlich dasselbe wie das Erstellen / Testen und Bereitstellen in der Programmierung. Das funktionsreiche Paket, das ESRI bietet, ist zwar recht gut, es mangelt jedoch an Flexibilität (Schemaänderungen oder Wartungsaufgaben während der Arbeit, z. B. Indexerstellung).

2. Flat Files und ein Versionskontrollsystemwir wählen Git (Wussten nicht, dass es bereits ein GeoGit gibt). Oh ja, einige meiner Freunde und ich kommen auch aus der Softwareentwicklung. Es könnte alles so einfach sein. Ich denke, das ist das Problem: Es ist wie ein Automechaniker, der ein Auto baut. Es wird für ihn einfach zu warten sein, aber es wird auch ärgerlich sein, mit Sicherheit zu fahren und verdammt hässlich anzusehen. Ich denke, es hat auch einige große Nachteile: Wie kann man ein 2 TeraByte (oder noch mehr, binäres) Rasterdataset versionieren? Und in welchem ​​Format? Vektordaten können leicht versionskontrolliert werden, wenn Sie textbasierte Formate (z. B. GML) verwenden, es ist jedoch auch schwierig, mit einem Datensatz mit Milliarden Zeilen zu arbeiten. Ich bin mir immer noch nicht sicher, ob wir eine effektive Verwaltung von Benutzerberechtigungen durchführen können, da nicht jeder alles bearbeiten oder sogar anzeigen darf. Und wie führt man einen Vektordatensatz zusammen, der von 4 Benutzern gleichzeitig intensiv bearbeitet wurde? Zumindest müssen Sie ein echter Informatiker / Programmierer sein, um all dies effektiv zu erledigen. Unsere GIS-Benutzer sind Planer, Vermesser, Geologen und so weiter. Es ist einfach ein Problem für sie, an Versionslinien zu denken, wie es Programmierer tun, oder Verzweigungen so zu verwenden, wie es angenommen wird. Dennoch ist es eine interessante Idee, Datenspeicher als Shared Repos zu betrachten.

3. Flat-Table-Datenbank als einfacher Container. Das gleiche wie SDE, aber ohne das SDE-Zeug. Es ist immer noch schwer zu warten, da Sie die Vorteile, die Ihnen ein RDBMS bietet, nicht nutzen. Ja, es ist sehr einfach, einfach alles in eine Datenbank zu laden, aber das ist überhaupt keine Datenverwaltung.

4. Bigdata und NoSQL . Gleiche Probleme wie bei Flat Files und Flat Tables. Meiner Meinung nach eine einfache Dateisystem-API für den Einsatz im Web. Ja, es funktioniert gut im Web und es ist einfach, Ihre Dokumente einfach in den Computer zu werfen, aber ich denke, wenn ich eine Geodatenanalyse auf Terabyte (möglicherweise Raster-) Daten durchführen möchte, möchte ich, dass sie nicht serialisiert und deserialisiert werden über die HTTP-Schnittstelle.

UPDATE 2018: Hier gibt es viele neue Dinge, die viel Schwung verleihen. Um ein paar zu nennen:

• Cloud-Blockspeicher und HDFS
• Python / Formschön / Dask Stack

• Apache Spark

  • GeoMesa / GeoWave für Vektordaten
  • GeoTrellis für Rasterdaten

• und vieles mehr

  5. Umfassende klassische Datenbankmodellierung(mit einem RDBMS). Das Hauptproblem ist, dass es schwierig ist, Daten einfach irgendwo abzulegen und zu hoffen, dass sie dann für jeden zukünftigen Bedarf geeignet sind. Wenn Sie jedoch Zeit investieren, um ein robustes Datenmodell (auch OSM hat dies tatsächlich getan) in einer Datenbank anzugeben, können Sie alle seine Vorteile nutzen. Wir können Daten in verteilten Transaktionen bearbeiten und aktualisieren, wir können auch ihr Kernschema ändern, während Services weiterhin auf externen Schemas derselben Daten beruhen, wir können sie verwalten, wir können ihre Konsistenz überprüfen, wir können Berechtigungen zulassen und verweigern, wir sind es In der Lage, sehr große Datenmengen zu speichern, während wir schnell darauf zugreifen können, sind wir in der Lage, historisierende Datenmodelle zu erstellen und diese transparent auszulösen und so weiter. Da wir SQL Server verwenden, fehlt uns immer noch ein nativer Rastertyp, aber andere Datenbankanbieter bieten dies bereits an.

Nun, ich denke, das relationale Datenbankmodell ist in den letzten Jahren nur mit räumlichen Datentypen in der räumlichen Welt aufgetaucht (davor waren es BLOB-Container) und ist immer noch die flexibelste und professionellste Form der Datenspeicherung. Das bedeutet nicht, dass es nicht durch VCS-Ansätze oder NoSQL ergänzt werden sollte, aber ich sehe diese Ansätze eher als eine Form der Datenverteilung in Benutzergruppen als als eine Form eines professionellen zentralisierten Geodatenmanagements. Auch OSM hat viele Aufgaben zentralisiert, die die Masse einfach nicht bereitstellen kann, wie das Importieren großer Datenmengen (die meisten OSM-Daten in Österreich wurden an einem Tag importiert, nicht per Crowdsourcing) und das Generieren von Kacheln. Der kollaborative Teil (Crowd-Sourcing) ist zwar sehr wichtig, macht aber nur die Hälfte des Geschäfts aus.

Ich denke, ich muss vieles umformulieren und mehr Fakten liefern. Eine solche Frage ist in ein paar Stunden nur schwer umfassend zu beantworten. Ich werde versuchen, die Qualität meiner Antwort in den nächsten Tagen zu verbessern