Alternatives aux fichiers de formes en tant que types d'ensembles de données open source et multiplateforme [fermé]

Je travaille sur un logiciel très orienté ESRI, mais une future version n'utilisera probablement pas de logiciel ESRI. Il utilise des fichiers de formes et des géodatabases. Je prévois de transmettre toutes mes données à Shapefiles en prévision des futures versions du logiciel qui seront probablement sur Android et d'autres appareils mobiles. Il semble que les Shapefiles soient le type de données le plus courant pour les fonctionnalités dans le monde SIG open source, mais quels sont les autres et quels avantages apportent-ils? Je connais GeoJSON et KML, mais je suis sûr qu'il y en a d'autres.

Je voudrais connaître toutes les options, mais je suis particulièrement intéressé par les types de jeux de données les mieux adaptés au stockage sur des appareils mobiles (les données doivent être accessibles sans connexion Internet).

Comme le dit @ user890, cela dépend beaucoup de la façon dont les données seront utilisées. Il existe principalement deux façons d'accéder aux données:

1. En chargeant le tout en mémoire en une seule fois, puis accédez / interrogez les données en mémoire.
2. En interrogeant des fonctionnalités spécifiques, des boîtes englobantes, etc.

Les formats tels que GeoJSON et KML sont les mieux adaptés aux cas où vous souhaitez tout charger en une seule fois. Les avantages sont que les données peuvent être structurées de manière plus adaptée à votre application. Les inconvénients: des fichiers plus volumineux (car ils sont basés sur du texte) et l'incapacité à effectuer des requêtes efficaces directement à partir du fichier.

SQLite / Spatialite est préférable pour l'interrogation (SQL), mais il est plus difficile de structurer les données - vous devez tout aplatir dans les tables de base de données, puis faire des JOIN (qui peuvent être coûteux) lors de l'interrogation.

Il n'y a pas vraiment un format de fichier parfait qui couvrira tout (mais là encore, les fichiers de formes sont loin, loin d'être parfaits). Une alternative à envisager est de rouler votre propre format spécifique à l'application, mais cela ne fonctionne que si vous n'avez pas besoin de partager les données avec le monde extérieur.

Je pense que la liste des formats vectoriels OGR (lien mis à jour) identifie à peu près tous les formats open source dont j'ai jamais entendu parler, et bien d'autres. Chacun de ces formats a ses propres avantages / inconvénients, il est donc difficile de dire lequel est le «meilleur». Pour les applications mobiles, j'imagine que la taille du fichier sera l'un des facteurs décisifs les plus importants.

Pour les applications mobiles, je pense que le format sqlite / spatialite serait le format logique pour commencer. Je sais que Android fournit un support natif pour sqlite. Donc, en supposant que vous puissiez charger les extensions de spatialite, vous aurez un gis très puissant à votre disposition.

Selon votre niveau d'aventure, il semblerait que la construction de gdal pour android ne soit pas impossible. Vous pourriez alors envisager de nombreux autres formats à votre disposition. Je suis sûr que de nombreux utilisateurs de ce site seraient intéressés si vous empruntiez cette voie.

Un nouveau format qui a vu le jour récemment est le Geopackage . Cette spécification est construite au-dessus de la base de données SQLite, donc elle a la même base de fichier unique, mais avec l'avantage supplémentaire d'être une norme OGC .
En ce qui concerne la taille du fichier, il est probable que le format de stockage soit plus compact que le format .shpet .dbfpour les données spatiales et d'attributs utilisées dans le Shapefile. Par conséquent, le GeoPackage est susceptible d'être de la même taille, ou plus petit, que la totalité des mêmes fonctionnalités dans un fichier de formes.
Cette photo montre une canalisation d'égout à San Diego enregistrée sous forme de fichier de formes et de GeoPackage. Comme vous pouvez le voir, ils sont essentiellement de la même taille.
Étant donné que ce format est basé sur SQLite, il doit être prêt à l'emploi pour les appareils mobiles. De nombreuses applications utilisent déjà ce format de base de données pour le stockage, il s'agit donc d'une technologie éprouvée. Il peut être utilisé multiplateforme sans aucune traduction requise.

D'accord avec Lennert, choisissez le bon format pour le travail.

Cependant, j'ai trouvé que Spatialite était un format assez polyvalent. Vous avez le fichier unique vous donnant la possibilité de stocker et de partager des données comme un fichier de formes, mais vous niez les problèmes que vous mentionnez avec les limites de caractères; tout en vous donnant l'opportunité d'exploiter les avantages d'une base de données spatiale.

Malheureusement, il n'est pas entièrement pris en charge dans ArcGIS (je n'ai pas essayé depuis un certain temps, donc je peux me tromper), mais fonctionne très bien dans QGIS.

Il existe de nombreux formats différents et le meilleur dépend de votre ensemble de données, des outils que vous utilisez et des choses que vous souhaitez en faire.

Certains de ceux que j'utilise:

• Géodatabase fichier & bases de données spatialite: Un fourre-tout que j'aime utiliser. Il peut contenir toutes sortes de données et avoir des relations, des indexations ... J'utilise gdb lorsque je travaille dans un environnement Esri, spatialite pour tout le reste.

• GeoJson: format facile à lire que j'utilise généralement pour les petits ensembles de données qui ne nécessitent pas beaucoup d'indexation

• Bases de données appropriées: j'ai tendance à l'utiliser pour des ensembles de données massifs et des algorithmes complexes.

Mais il y en a aussi des tonnes.

Je recommanderais d'utiliser la base de données SQLite / spatiallite. Il s'agit d'un fichier unique comme la géodatabase (une à plusieurs tables / couches à l'intérieur) et peut être utilisé dans ArcGIS Desktop et QGIS.

Les options dépendent vraiment de la langue que vous utiliserez et de la façon dont les données seront utilisées. Android sera probablement Java. Chaque option sera une sorte de comparaison coûts / avantages basée sur cette décision. Tous les formats de données sont optimisés pour certains cas d'utilisation.

La question suivante est de savoir comment les données seront utilisées. L'application mobile va-t-elle simplement lire les données spatiales? Ou va-t-il lire et écrire des données fréquemment? À quelle fréquence échangera-t-il des données avec d'autres appareils ou serveurs?