Note: Andrew Turner est très actif au sein la communauté d'experts qui s'affairent à construire le GeoWeb, lequel repose essentiellement sur le développement et la normalisation des formats de données géographiques. Il est par ailleurs le chef de la direction technologique (CTO) de l'entreprise FortiusOne et co-fondateur de Mapufacture. Il nous fait profiter ici de sa vaste expérience du domaine en brossant un portrait global de l'état des standards du GeoWeb, dans le cadre d'une série d'article que nous vous présenterons ici en version traduite, avec la permission de l'auteur. Les articles originaux sont parus en anglais sur le blogue d'Andrew, High Earth Orbit.
La première partie de l'article peut être consultée au lien suivant:
Les standards du GeoWeb - 1e partie
Le KML
Le KML, ou Keyhole Markup Language, est devenu une norme de facto avec la popularisation de Google Earth, autrefois Keyhole Earth, et la création et le partage tous azimuts de données géographiques pour utilisation dans ce génial géo-navigateur 3D.
Le KML offre un balisage riche qui supporte la localisation, les attributs et les styles des objets, les modèles 3D, les adresses et même les liens Atom. De plus, le KML est maintenant un standard de l’OGC., et Google a annoncé récemment qu’il y avait plus de 500 000 fichiers KML et deux milliards de repères, ou objets, soit en moyenne 4 repères par fichier KML.
Toutefois, le KML est très clairement une représentation d’objet directement liée à l’application Google Earth. Les noms des attributs suivent une convention CamelCase grossière basée sur des classes parent et enfant, mais cette règle simple est parfois brisée d’étranges façons, ce qui complique la tâche des développeurs d’outils qui cherchent à créer des outils compatibles. En outre, les options de stylisation sont limitées, puisqu’il n’y a qu’un très faible support des cascades et aucune possibilité de modifier le style des attributs ou des classes.
Google continue de promouvoir le cahier de charges du KML via des extensions GX qui lui sont propres. Le reste de la communauté géospatiale n’a pas encore tenté d’influencer ce cahier de charges d’une façon quelconque, malgré ces problèmes apparents.
Le GeoJSON
Un standard communautaire beaucoup plus récent, GeoJSON, ne fait qu’ajouter un balisage géographique au format JSON. GeoJSON vise en particulier la communication de client à serveur et tire avantage de sa taille compacte et son évaluation des données JSON.
GeoJSON a suivi, nominalement, les définitions du GeoRSS, ce qui le rend simple à comprendre et facilite l’utilisation des connaissances et outils actuels. Toutefois, le format JSON lui-même ne permet aucun véritable cahier des charges de format ou définition de schéma, laissant aux clients le soin de déterminer la disposition du JSON à partir de la documentation généralement acceptée plutôt que de vrais standards. Cela devient particulièrement problématique à mesure que des services exposent GeoJSON à des développeurs tiers via des API. En fait, il s’agit d’à peine plus qu’un XML arbitraire et spécifique, sans la syntaxe élaborée.
Le GML
En réponse à cet historique de XML arbitraire et unique, le Geography Markup Language, ou GML, a été développé. Le GML suit un mécanisme à la fois très strict et très riche en fonctionnalités pour permettre la création de schémas géographiques ainsi qu’une sémantique propre au domaine. On l’utilise pour des échanges de données très précises, le plus souvent au moyen de services OGC comme le WFS. Le GML est conçu pour combler l’écart entre des géométries 1D à 4D, pour des domaines multiples, et pour des profils ou des versions entièrement personnalisables en fonction des besoins des utilisateurs ou des développeurs.
Le pouvoir du GML s’accompagne d’une grande complexité. Les développeurs sont généralement obligés de créer et d’inclure leurs propres définitions de schémas particulières lorsqu’ils utilisent du GML. Le fait d’écrire un client GML générique est une tâche d’une ampleur comparable à celle d’écrire un interprète script Ruby, soit un défi de taille pour les développeurs Web ordinaires, qui ne veulent souvent qu’inclure de simples capacités géométriques à leurs services généraux. Cette complexité nuit à l’adoption du GML.
Autre formats
Il existe toute une variété d’autres formats qui commencent à émerger sur le Web en général, et ce sur plusieurs fronts à la fois.
Spatialite est un jeu d’extensions spatiales pour le format ouvert et transférable SQLite. SQLite est une base de données de fichiers qui offre de pleines capacités relationnelles dans un seul fichier. Spatialite ajoute donc des colonnes géographiques et un support rudimentaire de requêtes géospatiales.
SQLite est déjà utilisé par une variété d’outils comme Google Gears pour le support hors ligne et dans Google Maps sur le iPhone pour stocker les tuiles. Nous avons choisi Spatialite pour notre Geocoder, en raison de sa nature compacte et la facilité avec laquelle il peut être déployé. Spatialite représente une option très intéressante lorsque vous avez besoin d’avoir accès à une base de données géographique en entier et d’effectuer des opérations sur la donnée.
Un travail est fait pour que le GeoPDF devienne un format ouvert. L’incorporation du géo-enregistrement (Note: Voir à ce sujet GeoPDF and Georegistration ) est en instance d’adoption par l’OGC, et Adobe fait la promotion du cahier de charges ISO 32000 qui détaille comment incorporer les vecteurs et les dessins géographiques. L’interopérabilité et l’écosystème d’outils disponibles restent toutefois très fragmentaires, ce qui menace le format en tant que mécanisme de dissémination des données géographiques.
Le Common Alerting Protocol, ou CAP, est un format axé sur le temps réel pour le partage d’alertes, comme par exemple les communications de situation d’urgence, les alertes de tremblements de terre et les autres systèmes d’alertes au niveau municipal. Le CAP reste un format XML dépourvu de mécanismes pour s’assurer de la réception ou du respect des délais, et les avantages qu’il pourrait avoir sur d’autres formats plus largement utilisés et complets comme Atom restent nébuleux.
Il existe bien d’autres formats sur le GeoWeb, du CSV au GPX, au RDF et même à l’OpenStreetMap (OSM). Toutefois, ils sont encore trop génériques (CSV) ou trop récents (OSM) pour qu’on puisse vraiment les considérer comme des normes du GeoWeb, et il ne vaut donc pas la peine d’en discuter ici. Nous en parlerons cependant plus tard, au moment de discuter du futur des formats de géodonnées.
Aussi, des données sémantiques comme Linked Data, RDF ou OWL continuent de se développer en sourdine. J’examinerai plus en profondeur le potentiel des standards de données sémantiques géospatiaux.
Services
Au-delà des formats de données, il existe un certain nombre de normes pour les services, ou interfaces, du GeoWeb. L’Open Geospatial Consortium (OGC) domine ce créneau et fournit de nombreux cahiers de charges pour les requêtes, telles le Web Feature Service (WFS) et le Web Map Service (WMS), en plus d’autres interfaces de catalogage ou services basés sur la localisation.
Les WFS et les WMS sont riches en fonctionnalités, mais présentent aussi des paradigmes et interfaces un peu vieillis. Heureusement, ni l’un ni l’autre ne sont basés sur SOAP, et misent plutôt sur des paramètres de requête simples pour spécifier les boîtes, les couches, les formats et les projections. La plus grande difficulté est sans doute liée au fait que la description du service est au même point de terminaison que le service lui-même et, souvent, les serveurs utilisent les mauvais MIME -types pour les documents et les erreurs.
Plus récemment, les organisations de standards pour le Web en général, comme le World Wide Web Consortium (W3C) ont adopté des additions géospatiales aux navigateurs pour la localisation DOM, les informations de localisation HTTP et la confidentialité. ISO et OASIS regardent actuellement du côté de l’OpenSearch-Geo pour une possible intégration à leurs normes de récolte et de catalogage de données.
OpenSearch-Geo suit les mêmes concepts que GeoJSON et GeoRSS, en fournissant une simple extension à une interface dont l’usage est généralisé, en y ajoutant des composants géospatiaux. En outre, étant uniquement un cahier de charges pour les gabarits, elle peut facilement servir à décrire des API générales comme Flickr, les Liens réseau KML, ou même les WFS lorsqu’on applique le modèle de balisage approprié.
Toutefois, si OpenSearch-Geo a suscité beaucoup d’intérêt, il est difficile de voir quel en est l’usage principal. Il y a peu de services qui offrent une description explicite et conforme de leurs interfaces de recherche géospatiale.
Un paysage mixte
En somme, l’état actuel des standards de données du GeoWeb est plutôt mixte. Il ne fait aucun doute qu’ils sont en passe de devenir grand public. On peut observer l’émergence, voire la divergence de formats de données populaires dans Mapufacture et GeoCommons, à la fois pour les téléversements et pour les téléchargements ou les liens. Google a fait connaitre les chiffres pour le KML indexé sur le Web. En revanche, GeoCommons et Mapufacture comptent sur les utilisateurs pour vérifier et enregistrer les sources de données, ce qui offre un point de vue différent sur l’utilité des formats de données géospatiales sur le Web.
 |
Les figures ci-dessus montrent la composition des téléversements, des liens, et le portrait combiné des géodonnées téléversées sur GeoCommons et Mapufacture. Comparaison intéressante, les téléchargements sont nettement orientés vers des standards de poids plus légers : les téléchargements de KML comptent pour 67,8% de l’ensemble, le CSV pour 25,7% et les Shapefiles pour un faible 6,3%. On notera que c’est là une perspective étroite en regard du Web en général, qui ne tient pas compte des normes de l’OGC, des données raster et des services. Toutefois, cela nous éclaire néanmoins sur la façon dont les gens participent au GeoWeb de façon active.
Les différents formats ont tous été utilisés abondamment, mais il reste ardu de savoir quel format est le plus approprié pour chaque situation. Cela nous mène fréquemment à l’inclusion de multiples formats dans une application donnée, ce qui peut parfois être une solution simple et convenable, mais qui peut aussi créer de la confusion et engendrer de la redondance. Dans le prochain article, nous nous pencherons sur des problèmes plus généraux.
À suivre...
