Alternativen zu Shapefiles als plattformübergreifende Open-Source-Dataset-Typen [geschlossen]


20

Ich arbeite an Software, die sehr ESRI-orientiert ist, aber eine zukünftige Version wird wahrscheinlich keine ESRI-Software verwenden. Es werden Shapefiles und Geodatabases verwendet. Ich plane, alle meine Daten in Erwartung zukünftiger Versionen der Software, die voraussichtlich auf Android und anderen Mobilgeräten verfügbar sein werden, an Shapefiles weiterzuleiten. Es scheint, dass Shapefiles der häufigste Datentyp für Features in der Open-Source-GIS-Welt sind, aber was sind die anderen und welche Vorteile bringen sie? Ich bin mit GeoJSON und KML vertraut, aber ich bin mir sicher, dass es noch andere gibt.

Ich möchte alle Optionen kennen, interessiere mich aber insbesondere für Dataset-Typen, die sich am besten für die Speicherung auf mobilen Geräten eignen (die Daten müssen ohne Internetverbindung zugänglich sein).



1
Diese Frage aus dem Jahr 2011 wurde gestellt, bevor es GeoPackage gab, und Antworten schließen diese Alternative natürlich nicht ein.
user30184

2
Esri File Geodatabase hat eine maximale Länge von Zeichenfeldern, die mit dem Textinhalt der meisten kleinen Bibliotheken mithalten kann. Esri Personal Geodatabase unterstützt auch sehr lange Textfelder. Auf beide kann über QGIS und natürlich über Esri ArcGIS zugegriffen werden. Die Unterstützung für diese Datentypen ist jedoch außerhalb dieser Pakete eingeschränkt. Hüten Sie sich vor Version aber ich versuchen würde , 9.3 konform , da die meisten Esri Software Erstellen Sie wahrscheinlich Begegnung sind wird 10+ und die Geodatabase APIs für QGIS sollten diese Version unterstützen. GeoJSON und KML können auch große Textfelder unterstützen, sind jedoch nicht so allgemein lesbar.
Michael Stimson

1
Umm, 9.3 ist kein guter Plan für die File-Geodatabase-Kompatibilität - Die FGDB-API unterstützt keine .gdb im 9.x-Stil.
Vince

1
@ElioDiaz-Shapefiles existieren trotz ihrer Einschränkungen immer noch, da sie die universellsten Medien für die Übertragung von Features sind - fast jedes GIS-Paket kann Esri-Shapefiles öffnen oder importieren. Das Format ist ein offener Standard, so dass jeder auf seine eigene Weise lesen und implementieren kann. Es gibt zweifellos überlegen GIS Feature - Formate , aber sie werden nicht als allgemein angenommen ... dieses Thema diskutiert wurde viele Male auf GIS.SE. So sehr wir es uns auch wünschen, ansonsten sind Shapefiles wahrscheinlich für einige Zeit der kleinste gemeinsame Nenner für Features. Deshalb müssen wir nur grinsen und es ertragen.
Michael Stimson

Antworten:


18

Wie @ user890 sagt, hängt dies stark davon ab, wie die Daten verwendet werden. Es gibt hauptsächlich zwei Möglichkeiten, auf die Daten zuzugreifen:

  1. Indem Sie alles auf einmal in den Speicher laden und dann auf die Daten im Speicher zugreifen / diese abfragen.
  2. Durch Abfrage nach bestimmten Merkmalen, Begrenzungsrahmen usw.

Formate wie GeoJSON und KML eignen sich am besten für Fälle, in denen Sie alles auf einmal laden möchten. Der Vorteil besteht darin, dass die Daten so strukturiert werden können, dass sie besser für Ihre Anwendung geeignet sind. Die Nachteile: größere Dateien (da sie textbasiert sind) und die Unfähigkeit, effizient direkt aus der Datei abzufragen.

SQLite / Spatialite ist besser zum Abfragen (SQL), aber es ist schwieriger, die Daten zu strukturieren - Sie müssen alles in Datenbanktabellen reduzieren und dann JOINs (die teuer sein können) beim Abfragen ausführen.

Es gibt nicht wirklich ein perfektes Dateiformat, das alles abdeckt (aber auch Shapefiles sind alles andere als perfekt). Eine Alternative besteht darin, Ihr eigenes anwendungsspezifisches Format zu rollen. Dies funktioniert jedoch nur, wenn Sie die Daten nicht mit der Außenwelt teilen müssen.


14

Ich denke, die OGR Vector Format-Liste (Link aktualisiert) identifiziert nahezu jedes Open Source-Format, von dem ich je gehört habe, und viele, viele mehr. Jedes dieser Formate hat seine eigenen Vor- und Nachteile, so dass es schwer zu sagen ist, welches das beste ist. Für mobile Apps ist die Dateigröße meines Erachtens einer der wichtigsten Entscheidungsfaktoren.

Für mobile Anwendungen würde ich denken, dass das SQLite / Spatialite-Format das logische Format ist, mit dem ich anfangen möchte. Ich weiß, dass Android native Unterstützung für SQLite bietet. Vorausgesetzt, Sie können die Spatialite-Erweiterungen laden, steht Ihnen ein sehr leistungsfähiges GIS zur Verfügung.

Abhängig davon, wie abenteuerlustig Sie sind, scheint es nicht unmöglich , ein GDAL für Android zu erstellen . Dann stehen Ihnen möglicherweise viele weitere Formate zur Verfügung. Ich bin sicher, dass viele Benutzer auf dieser Website interessiert wären, wenn Sie diesen Weg gegangen wären.


13

Ein neues Format, das in letzter Zeit entstanden ist, ist das Geopaket . Diese Spezifikation baut auf der SQLite-Datenbank auf, hat also dieselbe Einzeldateibasis, aber den zusätzlichen Vorteil, ein OGC- Standard zu sein.
In Bezug auf die Dateigröße ist das Speicherformat wahrscheinlich kompakter als das Format .shpund .dbffür räumliche Daten und Attributdaten, die im Shapefile verwendet werden. Daher hat das GeoPackage wahrscheinlich dieselbe Größe oder ist kleiner als die Gesamtheit der gleichen Features in einem Shapefile.
Dieses Foto zeigt ein Kanalnetz in San Diego, das sowohl als Shapefile als auch als GeoPackage gespeichert wurde. Wie Sie sehen können, haben sie im Wesentlichen die gleiche Größe. Shapefile vs Geopackage Size
Da dieses Format auf SQLite basiert, sollte es für mobile Geräte vorbereitet sein. Viele Apps verwenden dieses Datenbankformat bereits zum Speichern, sodass es sich um eine bewährte Technologie handelt. Es kann plattformübergreifend verwendet werden, ohne dass eine Übersetzung erforderlich ist.


4

Stimmen Sie mit Lennert überein, und wählen Sie das richtige Format für den Auftrag.

Allerdings habe ich festgestellt, dass Spatialite ein ziemlich vielseitiges Format ist. Sie verfügen über eine einzelne Datei, die Ihnen die Flexibilität bietet, Daten wie ein Shapefile zu speichern und weiterzugeben, aber Sie negieren die von Ihnen erwähnten Probleme mit Zeichenbeschränkungen. Sie haben die Möglichkeit, die Vorteile einer räumlichen Datenbank zu nutzen.

Leider wird es in ArcGIS nicht vollständig unterstützt (ich habe es eine Weile nicht versucht, daher könnte ich mich irren), aber es funktioniert hervorragend in QGIS.


4

Es gibt viele verschiedene Formate und das Beste hängt von Ihrem Datenbestand, den verwendeten Tools und den Dingen ab, die Sie damit machen möchten.

Einige von denen, die ich benutze:

  • File Geodatabase & Spatialite-Datenbanken: Ein Schlagwort, das ich gerne benutze. Es kann alle Arten von Daten enthalten und Beziehungen haben, Indizierung ... Ich verwende GDB, wenn ich in einer Esri-Umgebung arbeite, Spatialite für alles andere.

  • GeoJson: Leicht lesbares Format, das ich normalerweise für kleine Datensätze verwende, für deren Indizierung nicht viel erforderlich ist

  • Richtige Datenbanken: Ich verwende diese für massive Datensätze und komplexe Algorithmen.

Aber es gibt auch Unmengen anderer.


3

Ich würde empfehlen, SQLite / Spatiallite-Datenbank zu verwenden. Es ist eine einzelne Datei wie eine Geodatabase (eine bis mehrere Tabellen / Layer) und kann in ArcGIS Desktop und QGIS verwendet werden.


Ich habe Polygondaten in SQLite gespeichert und diese mit QGIS geladen. Es wurde die Meldung "CRS war undefiniert: Standardmäßig CRS EPSG: 4326 - WGS84" angezeigt. Verliert es nicht Informationen über die Projektion?
Ichiro

Mit welcher Software haben Sie die Polygon-Ebene in SQLite gespeichert?
artwork21

1

Die Optionen hängen wirklich davon ab, welche Sprache Sie verwenden und wie die Daten verwendet werden. Android wird höchstwahrscheinlich Java sein. Jede Option ist eine Art Kosten-Nutzen-Vergleich, der auf dieser Entscheidung basiert. Alle Datenformate sind für bestimmte Anwendungsfälle optimiert.

Die nächste Frage ist, wie die Daten verwendet werden. Liest die mobile App nur Geodaten? Oder werden häufig Daten gelesen und geschrieben? Wie oft werden Daten mit anderen Geräten oder Servern ausgetauscht?

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.