Récemment, j'ai passé beaucoup de temps à convertir des noms de champs parfaitement bons, tels que "Pourcentage de citoyens âgés de 25 ans et plus titulaires d'un baccalauréat ou supérieur", en éléments comme "edbchogtr" afin de respecter la limite de 10 noms de champs du DBF.
Dans un autre fil ( "Curiosités" dans la spécification technique de Shapefile ), geospatialpython a déclaré: "Malgré les défauts, les bizarreries et les limitations du format de fichier de formes, il persiste obstinément dans et autour du domaine des SIG. Toute tentative de remplacement a été trop compliquée stockage vectoriel simple ou trop propriétaire. "
Cette activité, associée au commentaire de M. Lawhead, m'interroge:
- Des tentatives explicites ont-elles déjà été faites pour remplacer le fichier de formes en tant que format de stockage et d'échange de données omniprésent dans les SIG?
- Y a-t-il des prétendants?
- S'il y a eu des formats concurrents, pourquoi ont-ils échoué?
- Esri a-t-il refusé de les soutenir ou s'agit-il simplement d'une histoire d'inertie technologique?
- S'il n'y a pas eu de tentatives ... pourquoi pas?
Il semble que nous pourrions faire un peu mieux pour nous-mêmes, en tant que développeurs et utilisateurs de SIG.
Réponses:
C'est un sujet qui revient toujours. Je n'ai peut-être pas la bonne réponse, mais je peux vous donner mon opinion personnelle .
La raison pour laquelle ils sont pris en charge peut être attribuée à plusieurs caractéristiques les concernant, alors laissez-moi en mentionner quelques-uns.
Premièrement, il y a une spécification . Je veux dire, je suis au début de la trentaine et cette chose existait depuis mon adolescence. Donc, il est prudent de dire que cette spécification a été autour depuis un certain temps. Bien sûr, plusieurs autres formats sont également publiés, mais la différence avec celui-ci est que ...
C'est relativement simple! Il s’appuie sur le format DBF , qui existait déjà et qui était largement pris en charge par plusieurs plates-formes / systèmes d’exploitation. Il y avait déjà des analyseurs capables de lire la moitié de ce format (la partie DBF), ce qui facilitait la prise en charge de l'ajout supplémentaire. Vous avez une géométrie? Bien sûr, il suffit de le sérialiser et de l'écrire. Vous avez terminé. Comparez cela avec une couverture ! Essayez d'expliquer à quelqu'un, en termes simples, ce que fait un nettoyage de topologie . Il n’est pas anodin d’écrire une couverture topologiquement propre.
Plus important encore, je pense que la raison n ° 1 pour que les fichiers de formes soient toujours populaires est qu'ils sont pris en charge dans les systèmes Open Source et propriétaires . Que savez-vous des SIG qui ne prennent pas en charge les fichiers de formes?!? Du jamais vu.
En remplacement, nous entendons parler de File GeoDatabases and Spatialite . Les deux formats sont nettement supérieurs en termes de fonctionnalité, de flexibilité, de rapidité, etc. par rapport aux Shapefiles. À leur manière, ils ont certaines choses qui les rendent meilleurs les uns des autres dans différents domaines, mais une comparaison de spatialite et FileGDB est certainement hors du champ de cette question.
Est-ce que je pense que l'un ou l'autre de ces formats remplacera Shapefiles? Pas dans leurs incarnations actuelles .
Pourquoi?
Pas à cause d'un argument technologique (j'ai dit qu'ils étaient supérieurs à cet égard après tout), mais à cause d'autre chose: les licences.
Alors quels sont leurs problèmes?
FileGDB :
FileGDB offre une interopérabilité via la nouvelle API FileGDB. Néanmoins, cette API est fournie au format binairepar ESRI. Ce n'est pas une spécification. Ayant travaillé dans l’équipe GéoDatabase dans le passé, je peux vous affirmer que, contrairement à tous les théoriciens du complot qui portent le chapeau en étain, ce n’est pas du tout malicieux. C'est parce que les éléments internes de la GeoDatabase changent à chaque version. Publier une spécification complète impliquerait essentiellement de donner tous les détails sur la manière dont tout est censé être maintenu, puis de documenter soigneusement les modifications apportées au format avec chaque publication annuelle. Cela n'a pas de sens. Ainsi, l’API FileGDB, même s’il ne s’agit pas d’une spécification, résume toutes ces petites modifications. Et maintenant, il peut être utilisé sur plusieurs plates-formes! Attention, c'est un énorme pas en avant! Compte tenu de la nature conservatrice d'ESRI, il s'agit clairement d'une réaction dans la bonne direction.
Et pourtant, le support uniquement binaire ne rend vraiment heureux personne dans le monde de l'Open Source. Comment tirer parti du portage de code pour indiquer une autre version de Linux si ESRI ne le prend pas en charge. Tu ne peux pas. C'est ce qui rend Open Source puissant, et maintenant, vous ne pouvez pas en tirer parti. Si ESRI décide de ne plus supporter Debian, c'est tout. Vous avez terminé. Et vous ne pouvez rien faire pour le changer.
Spatialite :
Spatialite est génial car il tire toute la fonctionnalité gratuite de SQLite . SQLite est utilisé partout. Il se trouve sur votre Android Phone, sur votre iPhone / iPad, sur Firefox, sur Google Chrome, sur plusieurs appareils embarqués commerciaux - peut durer éternellement. Pour en faire vraiment un Geoformat (et pas seulement des opérations d'encadrement muettes), il doit exploiter la même bibliothèque de géométries que celle utilisée par PostGIS: GEOS . Malheureusement, GEOS est basé sur une autre bibliothèque de géométrie encore plus impressionnante appelée JTS . Tous les algorithmes dans JTS sont extrêmement puissants, alors quel est le problème?
Eh bien, JTS est sous licence Open Source LGPL , et LGPL est une licence virale . JTS est LGPL, signifie GEOS est LGPL, signifie spatialite liée statiquement à GEOS est LGPL. Ça craint. Pourquoi? Sans trop expliquer les licences open source , je peux vous affirmer que, par exemple, je ne peux pas utiliser spatialite sur une application iPhone, par exemple, car l'application entière serait automatiquement ouverte (iOS n'autorisant que les liens statiques). N'importe quel type de licence GPL effraie (raisonnablement) la merde d'ESRI, et ils ne la toucheront donc pas avec une perche de 10 pieds. Ainsi, ArcGIS, le système SIG le plus populaire au monde, ne supporte pas (et ne pourra probablement jamais) prendre en charge de manière native les spatialites. Cela le tue automatiquement en tant que format viable.
Et ainsi nous retournons aux fichiers de formes de merde qui sont supportés partout.
Mise à jour :
Apparemment, ma réponse était suffisamment controversée pour que quelqu'un décide qu'il était correct de modifier et de modifier librement le sens de ma réponse afin d'exprimer son point de vue. S'il vous plaît ne faites pas ça. Si vous n'êtes pas d'accord avec moi, c'est très bien, postez simplement votre opinion dans une réponse différente et laissez la communauté décider. J'ai annulé les modifications apportées à ma réponse pour montrer le sens original. J'ajoute cette mise à jour au cas où vous lisiez la réponse modifiée qui affirmait que SQLite était un format viable.
la source
La partie SHP + SHX n’est pas si mauvaise en soi. Le vrai problème réside dans la partie DBF. Cela pourrait se faire avec un nouveau format, qui prend en charge l’unicode et toutes sortes de types de champs modernes. Le problème, c’est que tous les logiciels sont bien supportés.
la source
GeoPackage est un successeur prometteur. Il ressemble à Spatialite, mais vient de OGC et a été adopté par de nombreux logiciels, y compris ArcGIS et OGR.
Voir la page d'accueil officielle http://www.geopackage.org/ et par exemple cette présentation: http://www.slideshare.net/JeffYutzler/geopackage-swg-overview
la source
Au moins spatialite a l'intention, voir par exemple cette présentation http://www.sourcepole.ch/assets/2010/9/10/foss4g2010_spatialite.pdf
D'autre part, je crois que la raison principale de son échec est que shp est bien pris en charge par de nombreuses applications et ne présente que des lacunes mineures.
D'autres partagent également cette opinion:
http://www.spatiallyadjusted.com/2010/09/16/spatialite-is-not-the-shapefile-of-the-future/
Plus de réflexions sur la géodatabase fichier, la spatialite et le fichier autodesk sdf, ici: http://www.spatialdbadvisor.com/blog/121/the-shapefile-manifesto
la source
Esri fait la promotion des géodatabases Fichier depuis plusieurs années en remplacement des fichiers de formes.
Plus récemment, ils ont fourni une API qui cache toutes les bizarreries.
la source
Un dialecte XML, tel que GML, n'est certainement pas optimisé pour exploiter d'énormes ensembles de données, mais peut être utilisé comme format d'échange entre logiciels ou entre plates-formes.
Je ne crois pas que les licences posent problème (voir l'article de Ragi Yaser Burhum sur les caractéristiques virales de Spatialite) et qu'il est assez facile d'adapter les analyseurs syntaxiques existants si nécessaire.
la source
Pour aborder la question sous un angle différent, je ne suis pas sûr que l’utilisation de «Pourcentage de citoyens âgés de 25 ans et plus titulaires d’un baccalauréat ou supérieur» constitue un nom de domaine tout à fait valable. Bien que le mélange d'espaces et d'apostrophes puisse être géré, si vous écrivez du code ou des requêtes, il est plus susceptible d'introduire des bogues.
À mon avis, l’avenir de la distribution de données spatiales devrait se concentrer sur le Web et les services Web, et la spécification WFS (qui utilise le langage GML) est ouverte et établie. GeoJSON est plus petit et peut être plus facile à utiliser en JavaScript. Cependant, avec la compression, les tailles sont comparables.
J'aimerais également voter pour les géodatabases personnelles ESRI . Il s’agit peut-être d’un format Microsoft souvent critiqué, mais il prend en charge les requêtes ODBC, SQL, les vues et permet aux non-développeurs de créer des formulaires de saisie de données simples et d’inclure au moins un certain niveau de contrôle de l’intégrité des données (types de données, longueurs, valeurs uniques). .
la source