Shapefile doit mourir !
Je vous propose la traduction de http://switchfromshapefile.org/ car j'adhère totalement à l'idée, surtout que l'on pourrait en dire la même chose de pas mal de formats : .dwg, .xls et .doc, .mp3, .AI....Bref, tous ces formats plus ou moins propriétaires qui vous enferment dans une solution logicielle. Vive les formats "ouverts" et "libres". J'ai commenté avec [NdT].
Se passer de Shapefile
ESRI Shapefile est un format de fichier pour le stockage de données vectorielles géospatiales. Il existe depuis le début des années 1990 et demeure le format d'échange de données vectorielles le plus couramment utilisé. Bien que les Shapefiles aient permis de nombreuses activités réussies au fil des ans, ils ont également un certain nombre de limitations qui compliquent le développement logiciel et réduisent l'efficacité.
Nous, membres de l'industrie des Technologies de l'information géospatiale, croyons qu'il est temps de cesser d'utiliser Shapefiles comme principal format d'échange de données vectorielles et de les remplacer par un format qui tire parti des énormes progrès qui ont été réalisés depuis l'introduction de Shapefile.
Le bon côté
Shapefile fait beaucoup de choses bien. Voici quelques raisons pour lesquelles Shapefile est si fortement utilisé :
- Shapefile est de loin le format le plus largement supporté dans les logiciels existants.
- Bien que le format soit propriétaire, ses spécifications sont ouvertes.
- Pour de nombreux cas d'utilisation, c'est suffisant.
- Les fichiers d'index (par exemple *.shx) permettent une bonne performance de lecture.
- Il est relativement efficace en termes de taille de fichier. Le fichier résultant, même décompressé, est relativement petit par rapport à d'autres formats (principalement textuels).
Shapefile est un mauvais format
Pourquoi Shapefile est-il si mauvais ? Voici plusieurs raisons pour lesquelles le Shapefile est un mauvais format et vous devriez éviter son utilisation : [NdT : voir aussi http://desktop.arcgis.com/fr/arcmap/latest/manage-data/shapefiles/geoprocessing-considerations-for-shapefile-output.htm]
- Pas de définition du système de référence des coordonnées.
- C'est un format multi-fichier.
- Les noms d'attributs sont limités à 10 caractères.
- Seulement 255 attributs. Le fichier DBF ne vous permet pas de stocker plus de 255 champs d'attributs.
- Types de données limités. Les types de données sont limités à flottant, entier, date et texte avec un maximum de 254 caractères.
- Jeu de caractères inconnu. Il n'y a aucun moyen de spécifier le jeu de caractères utilisé dans la base de données.
- Il est limité à 2 Go de taille de fichier. Bien que certains outils soient capables de dépasser cette limite, ils ne peuvent jamais dépasser 4 Go de données.
- Pas de topologie dans les données. Il n'y a aucun moyen de décrire les relations topologiques dans le format.
- Type de géométrie unique par fichier. Il n'y a aucun moyen de sauvegarder les caractéristiques géométriques mixtes.
- Des structures de données plus complexes sont impossibles à sauvegarder. C'est un format "flat table".
- Il n'y a aucun moyen de stocker des données 3D avec des textures ou des apparences telles que des définitions de matériaux. Il n'y a également aucun moyen de stocker des solides ou des objets paramétriques.
- Définition des projections. Ils sont incompatibles ou manquants.
- Le type de géométrie des lignes et des polygones, en une ou plusieurs parties, ne peut pas être déterminé de façon fiable au niveau de la couche, il doit être déterminé au niveau des caractéristiques individuelles.
1.Pas de définition du système de référence des coordonnées
Par défaut, il n'y a pas de définition du système de coordonnées de référence utilisé. Vous pouvez le faire en utilisant par exemple un .prj, mais premièrement, ce n'est pas une partie standard de la spécification et deuxièmement, il y a encore quelques problèmes, voir les problèmes de projection et le format multi-fichier plus bas.
2. Format Multifile
Le format Shapefile utilise au moins 3 fichiers (*.shp, *.dbf, *.prj) (wikipédia anglais plus complet). Les utilisateurs ne peuvent pas partager un seul fichier, vous devez les envoyer tous. Les utilisateurs zippent généralement tous les fichiers dans une archive et les décompressent à l'autre bout de la chaîne de distribution, mais c'est encombrant et source d'erreurs.
De plus, d'autres progiciels géospatiaux ajoutent régulièrement leurs propres extensions pour tenter de surmonter les limites de Shapefile. Les ajouts personnalisés ne sont pas pris en charge par d'autres outils et limitent l'interopérabilité.(cf. liste wikipédia)
3. 10 caractères par noms d'attributs
Les noms d'attributs sont limités à 10 caractères maximum. Les noms plus longs sont généralement automatiquement raccourcis. Cela conduit à des noms d'attributs abrégés et/ou cryptiques qui ne sont pas intuitifs pour le destinataire des données.
4. 255 champs d'attributs
Il ne peut y avoir que 255 champs d'attributs dans le fichier de base de données. Pour certaines applications, cela est limitatif, en particulier en combinaison avec la structure de la table plate.
5. Faible prise en charge des types de données d'attributs
Les types de données flottant, entier, date et chaîne de caractères sont supportés. Les nombres à virgule flottante peuvent être stockés sous forme de texte, mais il n'y a pas de support pour les grands nombres entiers (donc le format n'est pas utilisable, vous avez des données avec de grands nombres entiers, comme les cartes cadastrales) et le texte est limité à 254 caractères seulement.
Il n'y a pas de support pour les champs de données plus avancés tels que les blobs, les images ou les tableaux. [NdT : il ne peuvent pas stocker les heures dans les formats date aussi]
6. Jeu de caractères inconnu
Il n'y a aucun moyen de spécifier le jeu de caractères utilisé dans la base de données. De nombreuses applications utilisent les anciens encodages de données Windows-* ou ISO-*, alors qu'aujourd'hui nous avons tendance à utiliser UTF-8 davantage. Il n'y a toujours pas moyen de le spécifier dans l'en-tête du fichier. Le support des caractères Unicode est également très limité.
7. 2 Go Limite de taille
La taille des fichiers de composants.shp et.dbf ne peut dépasser 2 Go. GDAL Shapefile dépasse cette limite, mais le pilote
Le format Shapefile utilise explicitement des décalages de 32 bits et ne peut donc pas dépasser 8 Go (il utilise en fait des décalages de 32 bits en mots de 16 bits), mais l'implémentation OGR shapefile est limitée à 4 Go.
Pour des raisons de compatibilité avec d'autres implémentations logicielles, il n'est pas recommandé d'utiliser une taille de fichier supérieure à 2 Go pour les fichiers .SHP et .DBF
Ainsi, 4 Go est tout ce que vous pouvez avoir dans un seul fichier Shapefile. Cela semble suffisant, mais pas dans tous les cas.
8. Format non topologique
Shapefile est un format à fonctions simples. Il n'y a aucun moyen de stocker des relations géométriques plus complexes.
9. Pas de géométrie mixte
Chaque fichier ne peut être qu'un des formats géométriques supportés (Point, Ligne, Polygone et autres). Les caractéristiques géométriques mixtes ne sont pas possibles.
10 .Structure de données plate
La structure des données est limitée aux tables "plates" sans hiérarchies, relations ou arborescence.
11. Support 3D très limité
Shapefile ne peut pas stocker les définitions de matériaux ni les textures (images avec coordonnées de texture). Les modèles 3D sont stockés sous la forme d'une soupe triangulaire ou polygonale, sans qu'aucun modèle étanche [NdT : il est possible que les modèles présentent des lacunes ou des trous. C'est pourquoi nous nous référons au terme "étanche à l'eau". Cela signifie essentiellement que vos modèles doivent être scellés ou fermés. Un bon moyen de visualiser ceci est de demander si cela flotterait ou coulerait.] ou géométrie paramétrique ne soit pris en charge.
12. Incohérences dans la définition des projections
Par défaut, Shapefile ne contient aucune information sur le système de référence des coordonnées. Mais certains logiciels acceptent les fichiers *.prj, qui peuvent contenir une description CRS.
Il utilise les définitions Esri WKT, qui sont souvent incompatibles avec les définitions standard de l'EPSG ou d'autres sources concernant des aspects tels que l'ordre des axes ou les définitions des unités. De plus, ils manquent souvent les paramètres nécessaires à la reprojection ("Missing Bursa Wolf Parameters", n'importe qui ?)
13. Les entités multiples doivent être définies par entités.
Le type de géométrie des lignes et des polygones, en une ou plusieurs parties, ne peut pas être déterminé de façon fiable au niveau de la couche, il doit être déterminé au niveau des caractéristiques individuelles.
Cela entraîne une incohérence pendant le traitement automatique des données, vous ne pouvez pas relayer le type de géométrie d'entrée et devez tester chaque entité, qu'il s'agisse d'une géométrie simple ou multiple.
Connaissez-vous d'autres limites ou voulez-vous étendre celles qui existent déjà ? Veuillez le faire via le github du site initial ou en commentaire.
Les alternatives
Quelles sont les alternatives au format Shapefile ? Pour être honnête, aucun autre format n'a encore renversé l'hégémonie de Shapefile. Certains formats ont failli prendre le relais (KML, GML, GeoJSON), mais leur utilisation s'est limitée à des cas d'utilisation restreints..
Bien qu'il existe plus de 80 formats de données vectorielles, seuls quelques-uns peuvent être considérés comme candidats au remplacement de Shapefile. Veuillez noter que nous ne prenons en compte que les formats ouverts (de préférence communautaires).
OGC GeoPackage
Il est l'un des formats les plus prometteurs, conçu pour les applications modernes d'aujourd'hui. GeoPackage est publié en standard par l'Open Geospatial Consortium.
Caractéristiques
- SQLite comme squelette,
- basé sur un fichier unique,
- Vecteurs, rasters,
- Extensions officielles
- Pris en charge dans de nombreux progiciels
Description
GéoPackage est un format ouvert, normalisé, indépendant de la plate-forme, portable, autodescriptif et compact pour le transfert d'information géospatiale.
Le GeoPackage Encoding Standard décrit un ensemble de conventions permettant de stocker les éléments suivants dans une base de données SQLite :
- caractéristiques vectorielles
- jeux de matrices de tuiles d'imagerie et de rasters à différentes échelles
- autres tables (données non spatiales)
Il existe plusieurs extensions publiées pour GeoPackage qui rendent ce format encore plus puissant. GeoPackage est maintenant (2017) supporté dans la plupart des progiciels SIG.
Un inconvénient de GeoPackage est que la base de données SQLite sous-jacente est un format binaire complexe qui ne convient pas au streaming. Il doit être soit enregistré dans le système de fichiers local, soit accessible par l'intermédiaire d'un service intermédiaire [NdT : type cloud par exemple]
GéoJSON
"GeoJSON n'est pas un remplacement de Shapefile." -- Sean Gillies
GeoJSON est un format communautaire basé sur le populaire format d'échange de données JSON.
Caractéristiques
- format JSON
- Basé sur un fichier
- Peut gérer des données complexes
- La taille du fichier augmente rapidement
- Norme IETF [NdT : standard internet]
Description
GeoJSON est très simple, lisible par l'homme, de format texte. Bien qu'il soit techniquement possible de l'utiliser avec plus de systèmes de référence de coordonnées, la spécification indique clairement que le WGS84 est le seul système qui devrait être utilisé. Il peut traiter des données vectorielles complexes et construire des modèles de données hiérarchiques complexes.
Puisque GeoJSON est un encodage JSON, il est très facile à analyser. Il prend également en charge le streaming (les fonctionnalités sont traitées au fur et à mesure qu'elles arrivent sans attendre le chargement complet du fichier).
Le problème avec GeoJSON est que toutes les géométries ne peuvent pas être représentées et que les systèmes de référence de coordonnées avancés ne sont pas bien supportés.
OGC GML
Une autre norme de l'OGC.
Caractéristiques
- Basé sur XML,
- Seulement les vecteurs,
- Hiérarchique,
- Grâce à INSPIRE, support au moins partiel dans de nombreux progiciels
Description
GML a été choisi comme principal format de données vectorielles de distribution pour l'initiative européenne INSPIRE. C'est un format très complexe, et son utilisation directe dans les logiciels SIG est limitée. Son utilisation principale est un format d'échange de données qui doit être ingéré dans le système de l'utilisateur (par exemple, dans une base de données) pour être pleinement utilisable.
Le GML est actuellement souvent utilisé pour des ensembles de données ouverts, car il est neutre sur le plan technologique et compatible avec la norme OGC.
Un inconvénient majeur de GML est qu'il s'agit d'une norme extrêmement complexe. Peu de progiciels prennent en charge l'ensemble de la norme et la prise en charge des différentes parties de la norme varie considérablement.
SpatiaLite
SpatiaLite est une base de données populaire, c'est un stockage de données par fichier.
Caractéristiques
- Basé sur un fichier
- base de données SQL
- Caractéristiques simples de l'OGC
Description
SpatiaLite est une bibliothèque open source destinée à étendre le noyau SQLite pour prendre en charge les fonctionnalités complètes de Spatial SQLite. SQLite est intrinsèquement simple et léger :
- une bibliothèque unique et légère implémentant le moteur SQL complet
- implémentation SQL standard : SQL-92 presque complet
- une base de données entière correspond simplement à un seul fichier monolithique (sans limite de taille)
- n'importe quel fichier DB peut être échangé en toute sécurité sur différentes plates-formes, car l'architecture interne est universellement portable.
Le support de SpatiaLite est relativement limité et la plupart des logiciels qui supportent SpatiaLite supportent également GeoPackage. Ils s'appuient sur la même technologie sous-jacente, SQLite.
Comme SpatiaLite n'offre pas d'avantages clairs par rapport à GeoPackage à l'heure actuelle, il ne devrait être considéré que comme un remplacement de Shapefile dans des scénarios de niche.
CSV
Certaines personnes ont tendance à utiliser des fichiers séparés par des virgules pour stocker les données géospatiales.
Caractéristiques
- Simple
Description
Chez les personnes non géomaticienne, le CSV est très populaire, mais pour la plupart des applications géospatiales, ce n'est pas un format idéal.
OGC KML
OGC KML était un format de données vectorielles populaire populaire en raison de la popularité de Google Earth.
Caractéristiques
- basé sur des fichiers
- XML
- Combine la géométrie avec la cartographie
- Supporte uniquement le système de coordonnées WGS-84
Description
KML a été conçu à l'origine comme le format d'échange pour un progiciel appelé Keyhole. Lorsque Google a acheté Keyhole et l'a publié sous le nom de Google Earth, KML a gagné en popularité. Cependant, comme la communauté géospatiale a atteint les limites de Google Earth et de KML, la popularité de KML a diminué. Comme il est basé sur XML, il n'est pas efficace pour stocker de plus grands ensembles de données. Il combine la cartographie et la géométrie des données dans un seul fichier, ce qui est problématique lorsque les données peuvent être utilisées de multiples façons. Puisqu'il ne supporte officiellement que le système de référence de coordonnées WGS-84, il ne convient pas à un certain nombre d'applications.
GéoDataBase d'ESRI
Au niveau le plus élémentaire, une géodatabase ArcGIS est une collection d'ensembles de données géographiques de divers types conservés dans un dossier de système de fichiers commun, une base de données Microsoft Access ou un SGBD relationnel multi-utilisateurs (comme Oracle, Microsoft SQL Server, PostgreSQL, Informix ou IBM DB2).
Caractéristiques
- structure de données native pour ArcGIS,
- basé sur un fichier (ou une base de données),
- modèles de données complexes,
- propriétaire, format fermé.
Description
La géobase de données est très souvent utilisée dans l'environnement ArcGIS comme principal format d'échange de données. Ses caractéristiques sont très complexes et avancées.
Dernière modification : 2017-10-08 - Initialement créé par : Jachym Cepicky, OpenGeoLabs s.r.o.
Ce travail est sous licence Creative Commons Paternité-Partage des Conditions Initiales à l'Identique 4.0 International License
Contribuer sur le site original : Sur GitHub
Consulté en 25 mai 2019 et traduit avec l'aide de www.DeepL.com/Translator