SpatiaLite est-il le seul format d'échange à fichier unique / base de données activé spatialement?


13

J'essaie de déterminer s'il existe d'autres formats d'échange viables pour les données activées spatialement. Jusqu'à présent, il semble que SpatiaLite soit le seul sur le marché, mais il n'a pas encore été adopté par l'industrie.


Vous recherchez un format d'échange ou un format de stockage portable? Il serait utile de décrire le problème que vous essayez de résoudre. GML est un excellent format d'échange, mais vous ne l'utiliseriez pas comme magasin de données pour une application Web.
Sean

Réponses:


10

En termes de spécifications OGC Simple Feature SQL, Spatialite est la seule implémentation open source sur un seul fichier de base. Pour cette raison (et d'autres!), Il présente des avantages majeurs par rapport à d'autres formats vectoriels plats comme le shapefile, etc.

Étant entièrement pris en charge par GDAL en tant que pilote OGR «officiel» [0], il s'agit d'une garantie pour la prise en charge future des principaux logiciels GIS Desktop (ils utilisent tous le GDAL universel).

Actuellement, seul QGIS est capable de le lire (et de l'écrire), donc si vous voulez un format d'échange directement lisible / inscriptible à partir de votre logiciel sans exportation vers d'autres formats, ce n'est peut-être pas votre meilleure option, si vous n'utilisez pas QGIS.

Si vous avez besoin d'un forma d'échange, comme déjà suggéré, vous pouvez utiliser n'importe quel format pris en charge à partir de GDAL / OGR [0], puis réimporter vers une base de données spatiale.

Notez que si Spatialite implémentera la topologie, comme je l'ai entendu, cela aura un avantage majeur par rapport aux autres formats de plan (comme les fichiers de formes par exemple).

[0] http://www.gdal.org/ogr/drv_sqlite.html

[1] http://www.gdal.org/ogr/ogr_formats.html


J'ai entendu des rumeurs selon lesquelles la spatialite est toujours une cible mouvante et le développement est lent et c'est pourquoi je me demande s'il existe d'autres options.
GuidoS

1
Quant à la vitesse de développement, je la qualifierais de frénétique, pas de lente. Je dirais que SpatiaLite est en quelque sorte une cible mouvante car il est encore relativement jeune. Le SQL est assez conforme aux normes, donc le code de requête ne changera pas grand-chose. La version 2.4 est presque finale, mais n'est pas, comme vous le suggérez, compatible avec les bibliothèques clientes 2.3.
DavidF

Alors, comment le passage de 2.3 à 2.4 affecte-t-il l'utilisateur final? Si ma façon actuelle d'y accéder est par l'ogr, pensez-vous que je saurai même la différence?
GuidoS

5

Cela dépend vraiment de vos besoins. Je pense également que geojson , gml , citygml et google kml pourraient également être considérés comme des formats d'échange spatial.


Je cherche quelque chose qui peut être utilisé pour remplacer des fichiers de forme et qui est sql querable. Je pense que sqlite est une excellente plate-forme, mais j'ai entendu des rumeurs sur la communauté des spatialites et je me demande s'il existe d'autres solutions actuellement.
GuidoS

Le problème est que pour que quelque chose puisse être interrogé nativement SQL, il doit être spécifique à une base de données particulière. Et avec OGR, tout est interrogeable SQL sous une forme ou une autre.
Matthew Snape

1
En tant que format de substitution de fichiers de formes, en effet, j'ai lu que la spatialite est un bon candidat . Je n'ai jamais entendu parler d'autres formats pour ça.
simo

Je pense que c'est génial que ce format d'échange soit construit sur un format sql très utilisé. sqlite est super ... mais la spatialite est-elle la seule à l'utiliser?
GuidoS

Il semble que vous recherchiez SpatiaLite, mais seulement si ce n'est pas SpatiaLite. Je suis curieux de savoir quel est votre parti pris. (Peut-être que vous y avez déjà répondu dans votre commentaire ci-dessous.)
DavidF

2

Bien qu'elle manque de prise en charge en dehors d'ESRI, la géodatabase personnelle serait un bon choix et a été adoptée par l'industrie. En termes d'adoption, les formats AutoCAD pourraient également être envisagés.


2

Je pense que le hic, c'est quand vous dites «adopté par l'industrie». Les grandes sociétés de logiciels SIG propriétaires ont intérêt à contrôler le format des données.

SpatiaLite fonctionne très bien avec QGIS. Vous pouvez créer des couches de carte basées sur des requêtes SQL.

Si vous souhaitez combiner des caractéristiques spatiales et des tables associées dans un seul fichier pour l'échange, SpatiaLite est parfait. Si vous souhaitez simplement échanger des fonctionnalités avec des attributs, un fichier de formes zippé est toujours votre meilleur choix.


Je veux m'éloigner des fichiers de formes pour de nombreuses raisons, y compris: il nécessite plusieurs fichiers, il a des limitations de nom de champ, il ne permet qu'une seule couche / classe d'
entités

Je ne pense pas que beaucoup d'entre nous s'opposeraient à s'éloigner des fichiers de formes. RE SQL Queries, est-ce le format de fichier qui ne permet pas les requêtes SQL directes ou est-ce le logiciel que vous utilisez qui ne permet pas les requêtes SQL directes?
DavidF

1
Il s'agit davantage d'avoir un standard robost qui vous permettrait d'utiliser d'autres outils pour accéder à vos données via des requêtes SQL, d'où le sqlite.
GuidoS

2

Pour ce que ça vaut, mon vote va à Spatialite en tant que solution à fichier unique, échangeable avec tout le monde. Les géodatabases personnelles Esri (.mdb) sont excellentes mais ne fonctionnent pas avec beaucoup de piles de systèmes SIG, principalement celles qui sont basées sur Linux, car le format de fichier nécessite des pilotes de base de données Microsoft propriétaires qui ne sont pas disponibles pour beaucoup. Les autres remèdes à fichier unique offrent des béquilles uniques pour obtenir vos données à partir de divers endroits - services en ligne, appareils GPS, etc. (KML, GPX) ... ou d'autres utilisateurs SIG qui ont collecté des données à partager avec vous au format shapefile. dxf et dwg et d'autres formats de CAO n'offrent pas les fonctionnalités attendues par les utilisateurs SIG. Bien sûr, si vous placez vos données sur un serveur pour en fournir à plusieurs, vous n'avez pas besoin d'un seul format de fichier. PostGIS serait la solution de base de données sans fichier (serveur).


1

Maintenant, OGC GeoPackage est la base de données spatiale pour les entités vectorielles et les tuiles raster standard. Cependant, vous ne pouvez pas faire d'opérations / fonctions / requêtes spatiales sur gpkg. Vous pouvez créer un virtualgpkg dans spatialite et utiliser spatialite pour ces opérations spatiales.


0

SQLite lui-même est quelque peu spatial. OGR prend en charge l'écriture. Outre SpatiaLite (qui est mal pris en charge), il existe le format SDF d'Autodesk. Les dernières versions sont en fait des fichiers SQLite.

http://en.wikipedia.org/wiki/Spatial_data_file


1
Avec GDAL v> 1.7.0, Spatialite est assez bien supporté. gdal.org/ogr/drv_sqlite.html Vous pouvez lire / écrire. Les index spatiaux ne sont pas pris en charge, mais si la question concerne uniquement l'échange de données, cela ne devrait pas être une grosse affaire.
DavidF

Oui, c'est mon boeuf. Pour un véritable format de fichier d'échange / d'échange, il doit être lu en natif par les applications de bureau et de serveur les plus populaires. Bien que je n'aie aucun problème à déployer OGR moi-même, mes clients ne sauraient même pas le faire.
James Fee

Je voudrais souligner que cette question est directement liée à une session que James a eue à WhereCamp PDX. Sa théorie était que nous n'avons pas besoin d'un format d'échange et que la seule façon d'avoir un nouveau format d'échange serait de faire adopter ce format par les principaux fournisseurs.
GuidoS

@James - Alors la géodatabase fichier c'est! ; / Industrie SIG = ESRI, non? Ils ont publié l'API. Ajoutez quelques `` paquets de couches '' pour la cerise sur le gâteau ...
DavidF

1
Le FGDB a tous les mêmes problèmes que le format SpatiaLite, mais pour la raison opposée. La bibliothèque ne fonctionne que sur Windows et sur quelques systèmes Linux "propriétaires" (RHEL, SuSE).
James Fee du
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.