Welche Datenformate eignen sich am besten für die Open Data-Verteilung?

Welche Vor- und Nachteile haben verschiedene Datenformate (Leistung, Dateigröße usw.), wenn die Verteilung offener Daten in Betracht gezogen wird?

Unsere Organisation möchte Daten als offene Daten veröffentlichen. Es ist jedoch nicht klar, welche Datenformate verwendet werden sollen. Natürlich ist die Verwendung eines Datenformats umso einfacher, je offener es ist.

Welche Datenformate sind am 'offensten' und daher am besten für die Verteilung von Open Data geeignet, wenn folgende Typen berücksichtigt werden:

• Rasterdaten (ich denke: GeoTIFF, Erdas Imagine IMG?)
• Vektordaten (ich denke: GML, CSV, ESRI Shapefile, DXF?)
• Tabellarische Daten (ich denke: CSV?)
• 3D-Daten (ich denke: CityGML?)
• 3D point coulds / LIDAR (ich denke: LAS?)
• vergesse ich hier etwas?

Auch wenn es Dokumentation über offene Datenformate gibt, bin ich sehr interessiert, wenn Sie teilen möchten.

Die Open-Data-Initiative der Stadt Wien ( http://data.wien.gv.at ) nutzt Geoserver, um über Geoserver WMS- und WFS- Dienste auf Raster- und Vektor-Geodaten zuzugreifen . Dies hat viele Vorteile: Benutzer können Daten in verschiedenen Formaten für die Offline-Verwendung herunterladen (z. B. Geojson, KML oder gezippte Shapefiles) oder die Dienste live nutzen, indem sie sie in Online-Karten oder GIS-Projekte einbetten.

Für tabellarische CSV. Excel ist bestenfalls zu kompliziert und im schlimmsten Fall völlig unzugänglich. Der Zugang ist nicht zugänglich und PDF ist ein Schlag ins Gesicht.

Für die Verwendung in Geodaten ist Geojson ein Text, der gut unterstützt wird und nicht die technischen Einschränkungen aufweist, die das einzige andere brauchbare Format (Shapefile) aufweist. Es sei denn, Sie haben einen sehr guten Grund, es sollte in WGS84 sein, wobei zu berücksichtigen ist, dass sich die meisten Benutzer in einem anderen Zustand befinden und keine Zustandsebene wünschen.

Ich mag NetCDF für kontinuierliche / Array-Daten (dh Raster). Vorteile für NetCDF sind:

• NetCDF ist selbstbeschreibend (dh Datendefinitionen sind über den Dateikopf verfügbar), sodass Sie keine sekundären Metadatendateien angeben müssen
• NetCDF4 ermöglicht das Speichern von n-dimensionalen Daten (unter Verwendung des HDF5-Datenformats auf der Festplatte, was ein Bonus ist, da dies Dateien ermöglicht, die so groß sind, wie Ihr Betriebssystem verarbeiten kann). Dies bietet eine angemessene Komprimierung und einen schnellen Zugriff auf die Daten. Beachten Sie, dass NetCDF3 keine n-dimensionalen Daten unterstützt und auf einem 32-Bit-System eine Dateigrößenbeschränkung von ca. 2 GB aufweist.
• NetCDF ist ein offenes Format, so dass der Zugriff auf die Daten in der Regel auch über gängige Bibliotheken kein Problem darstellt. Zum Beispiel ist es in Python von scipy aus einfach genug, einen Teil der Daten einzulesen:

from scipy.io import netcdf
f = netcdf.netcdf_file('source.nc')
print(nc.dimensions) #take a look at the dimensions of the data
print(nc.variables)  #A dictionary containing all the variables
nc.variables["some_data"].dimensions #The dimensions this variable is in, e.g. lat, lon
out_array = nc.variables["some_data"].data
f.close() #and we're done

Der einzige Nachteil von NetCDF4, den ich sehe, ist die nicht sehr gute Unterstützung in Standard-GIS-Paketen wie ArcGIS und QGIS.

BEARBEITEN Einige andere Pakete, die NetCDF unterstützen

Einige Standard-Programmiersprachen, die NetCDF unterstützen (obwohl fairerweise alles, was HDF lesen kann, NetCDF4 lesen kann):

• Java
• Perl
• C ++

Für Mathe- und Statistikbenutzer haben Sie:

• matlab
• IDL
• R

Speziell in GIS:

• GDAL konvertiert die Daten für Sie
• Ebenso FME
• ArcGIS unterstützt NetCDF (obwohl es meiner Erfahrung nach nicht die beste Unterstützung darstellt)
• Es befindet sich ein QGIS Plugin in der Entwicklung

Wenn Sie sich schnell eine NetCDF-Datei ansehen möchten, würde ich das plattformübergreifende Panoply der NASA verwenden. Und wenn Sie an mehr interessiert sind, hat UCAR Unidata eine Liste von Software .

Ich würde sagen:

• Shapefiles oder GML für Vektordaten
• .obj-Dateien für 3D-Modelle
• .xyz (einfaches CSV) für Punktwolken
• CSV für tabellarische Daten
• GeoTIFF für Rasterdaten

Diese Formate können von Open Source Software problemlos gelesen und in jedes andere für bestimmte Anwendungen erforderliche Format umgewandelt werden.

Auch +1 für das Öffnen von Daten!

Genau diese Frage stellte sich bei opendata.SE: In welchen Formaten lassen sich Geodaten am besten veröffentlichen?

Hoffentlich verstoße ich nicht gegen Richtlinien, wenn ich dort meine eigene Antwort zitiere:

Meine Erfahrung mit der Erstellung von Karten aus mehreren Regierungsdatensätzen:

Für Punktdaten ist CSV mit den Spalten "lat" und "lon" am besten geeignet. Es ist sehr einfach, mit einer Vielzahl von Werkzeugen zu arbeiten, einschließlich Texteditoren, Tabellenkalkulationen usw. Es gibt zwei Nachteile:

1. GDAL benötigt eine .vrtBegleitdatei.
2. Die Benennung der Spalten latund lonist nicht ganz Standard. Viele Tools sind ziemlich liberal in dem, was sie akzeptieren.

Für Linien und Polygone in absteigender Reihenfolge der Präferenz:

1. GeoJSON. Die einfache Arbeit und die Möglichkeit, in einem Texteditor oder mit geojson.io zu bearbeiten, ist ein echter Vorteil. Wenn Sie suchen / ersetzen müssen, entfernen Sie ein paar seltsame Objekte oder kopieren Sie sie und fügen Sie sie in eine andere Datei ein. Ein weiterer Vorteil ist, dass Nicht-GIS-Entwickler einen Sinn daraus ziehen können. Ich bin nur auf Probleme gestoßen, wenn jemand Daten wie MultiPoint anstelle von Point bereitstellt.
2. Shapefile. Sehr weit verbreitet, aber mit zwei ungünstigen Punkten. Erstens handelt es sich um eine Sammlung von Dateien, sodass Sie eine ZIP-Datei weitergeben und extrahieren müssen. Zweitens sind Feldnamen auf 10 Zeichen begrenzt. Sie sind für eine durchschnittliche Nicht-GIS-Person schwer zu bearbeiten.
3. KML / KMZ. Diese haben oft eine Menge irrelevanter Elemente (Stile, Symbole usw.), und Attribute werden manchmal als Mini-HTML-Tabellen codiert, mit denen man nur schwer arbeiten kann. Zumindest können Sie sie einfach mit Google-Tools bearbeiten.

Ehrlich gesagt ist die beste Antwort wahrscheinlich "alle von ihnen". Tun Sie allen einen Gefallen und geben Sie die Daten in CSV (wenn vorhanden), GeoJSON, Zip-Shapefile und KMZ frei.