Quels formats de données conviennent le mieux à la distribution d'Open Data?

Quels sont les avantages et les inconvénients des différents formats de données (performances, taille de fichier, etc.) lorsque l'on envisage une distribution de données ouverte?

Notre organisation souhaite publier des données en tant que données ouvertes. Cependant, il n'y a pas d'idée claire sur les formats de données à utiliser. Bien entendu, plus un format de données est «ouvert», plus il est facile à utiliser.

Quels formats de données sont les plus `` ouverts '' et donc les plus utilisables pour la distribution des données ouvertes en tenant compte des types suivants?:

• données raster (je pense: GeoTIFF, Erdas Imagine IMG?)
• données vectorielles (je pense: GML, CSV, ESRI Shapefile, DXF?)
• données tabulaires (je pense: CSV?)
• Données 3D (je pense: CityGML?)
• Pots de points 3D / LIDAR (je pense: LAS?)
• est-ce que j'oublie quelque chose ici?

De plus, s'il existe de la documentation sur les formats de données ouverts, je suis très intéressé si vous souhaitez partager.

L'initiative de données ouvertes de la ville de Vienne ( http://data.wien.gv.at ) utilise Geoserver pour fournir un accès aux données géographiques tramées et vectorielles via les services Geoserver WMS et WFS . Cela présente de nombreux avantages: les utilisateurs peuvent télécharger des données dans différents formats pour une utilisation hors ligne (par exemple, geojson, KML ou Shapefiles zippés) ou utiliser les services en direct en les incorporant dans des cartes en ligne ou des projets SIG.

Pour les CSV tabulaires. Excel est au mieux trop compliqué et au pire totalement inaccessible. L'accès n'est pas accessible et le PDF est une claque au visage.

Pour une utilisation géospatiale, geojson, c'est du texte, il est bien pris en charge et n'a pas les restrictions techniques que le seul autre format viable (shapefile) a. Aussi, sauf si vous avez une très bonne raison, il devrait être dans WGS84, sachant que la plupart des utilisateurs seront dans un autre état et ne voudront pas de plan d'état.

J'aime assez NetCDF pour les données continues / matricielles (c'est-à-dire les rasters). Les avantages de NetCDF sont:

• NetCDF est auto-descriptif (c'est-à-dire que les définitions de données sont disponibles via l'en-tête du fichier), vous n'avez donc pas besoin de fournir de fichiers de métadonnées secondaires
• NetCDF4 permet le stockage de données à n dimensions (en utilisant le format de données HDF5 sur disque, ce qui est un bonus car cela permet des fichiers aussi gros que votre système d'exploitation peut les gérer). Cela vient avec une compression raisonnable et un accès rapide aux données. Notez que NetCDF3 ne prend pas en charge les données à n dimensions et a une limite de taille de fichier d'environ 2 Go sur un système 32 bits.
• NetCDF est un format ouvert, donc l'accès aux données n'est généralement pas un problème également via les bibliothèques communes. Par exemple, en python, il est assez simple de scipy pour lire dans une tranche de données:

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

Le seul inconvénient de NetCDF4 que je peux voir est la faible prise en charge des packages SIG standard comme ArcGIS et QGIS (bien que j'aimerais beaucoup être corrigé à ce sujet!).

EDIT Quelques autres packages qui prennent en charge NetCDF

Certains langages de programmation standard qui prennent en charge NetCDF (mais pour être honnête, tout ce qui peut lire HDF peut lire NetCDF4):

• Java
• Perl
• C ++

Pour les utilisateurs de mathématiques et de statistiques, vous avez:

• matlab
• IDL
• R

Plus précisément dans le SIG:

• GDAL convertira les données pour vous
• De même FME
• ArcGIS prend en charge NetCDF (bien que ce ne soit pas le meilleur niveau de support selon mon expérience)
• Il y a un plugin QGIS en développement

Si vous souhaitez consulter rapidement un fichier NetCDF, j'utiliserais le Panoply multiplateforme de la NASA. Et si vous êtes intéressé par plus, UCAR Unidata a une liste de logiciels .

Je dirais:

• Shapefiles ou GML pour les données vectorielles
• Fichiers .obj pour les modèles 3D
• .xyz (CSV simple) pour les nuages ​​de points
• CSV pour les données tabulaires
• GeoTIFF pour les données raster

Ces formats sont facilement lisibles par les logiciels Open Source et sont facilement transformables en tout autre format nécessaire pour des applications spécifiques.

Aussi +1 pour ouvrir les données!

Pratiquement cette même question s'est posée à opendata.SE: Quels sont les formats les plus utiles pour publier des données géospatiales?

Donc, j'espère que je ne viole aucune politique en citant ma propre réponse:

Mon expérience, la création de cartes à partir de plusieurs jeux de données gouvernementaux:

Pour les données ponctuelles, CSV est le meilleur, avec des colonnes "lat" et "lon". Très facile à utiliser dans une large gamme d'outils, y compris les éditeurs de texte, les feuilles de calcul, etc. Il y a deux inconvénients:

1. GDAL nécessite un .vrtfichier compagnon.
2. La dénomination des colonnes latet lonn'est pas totalement standard. De nombreux outils sont assez libéraux dans ce qu'ils acceptent.

Pour les lignes et les polygones, par ordre décroissant de préférence:

1. GeoJSON. Facile à travailler et la possibilité de modifier dans un éditeur de texte ou avec geojson.io est un vrai bonus, si vous devez faire une recherche / remplacement, supprimer quelques objets étranges ou copier et coller d'un fichier à un autre. Un autre avantage est que les développeurs non SIG peuvent comprendre cela. Le seul problème que j'ai rencontré est lorsque quelqu'un fournit des données comme MultiPoint au lieu de Point.
2. Shapefile. Très largement supporté, mais avec deux points gênants. Tout d'abord, c'est une collection de fichiers, vous devez donc passer un .zip et l'extraire. Deuxièmement, les noms de champ sont limités à 10 caractères. Ils sont difficiles à modifier pour votre personne non SIG moyenne.
3. KML / KMZ. Celles-ci ont souvent beaucoup de dépouilles non pertinentes (style, icônes, etc.), et les attributs sont parfois codés sous forme de mini-tableaux HTML, qui sont vraiment difficiles à travailler. Au moins, vous pouvez les modifier facilement avec les outils Google.

Honnêtement, cependant, la meilleure réponse est probablement «tous». Faites plaisir à tout le monde et publiez les données en CSV (si point), GeoJSON, Shapefile zippé et KMZ.