GML, KML-KMZ, GeoJSON, GeoRSS, GeoAtom, … stop, n’en jetez plus ! Les formats géographiques vectoriels utilisés par les web services sont foisons. Leur point commun est d’être des formats textuels et non binaires. On perd en compacité ce que l’on gagne en interropérabilité puisque, plus « lisibles » ils sont plus facilement implémentables dans des applications web. Tous sont dérivés du XML.
Le premier, le GML, est le plus ancien. Il est l’oeuvre de l’OGC qui en diffuse les specifications (595 pages quand-même…), et est notamment utilisé dans le procole WebFeatureService qui permet la mise en oeuvre de services web en données vectorielles.

Le KML (Keyhole Markup Language, et sa version Z pour la gestion de la 3D version zippée) est utilisé par Google, notamment dans GoogleEarth (c’est KeyHole qui l’a créé, mais c’est Google qui l’a racheté).

Le GeoJSON est à destination des programmeurs. Il s’agit d’un moyen de transférer facilement des « objets » d’un language de script vers le javascript (d’où le nom : Javascript Simple Object Notation), tel quel, avec attributs et propriétés. On le croise moins souvent, c’est vrai, mais c’est parce qu’il se cache.

Les deux derniers sont presques des microformats, issus de la volonté de donner autant de souplesse à l’information géographique qu’à l’information tout court, au travers de la syndication de contenu.

Bon, mais on en fait quoi exactement ? Pour la plupart, ils ne sont que des formats d’échange, les MIF/MID du web en quelque sorte. Seul le KML se distingue par son utilisation native dans GoogleEarth. On peut presque en dire autant du GML, que QGis ou Jump sont capable d’afficher directement. Mais malgré ce, ces formats n’ont pas encore pris la place de « standard » que peut avoir le shapefile d’Esri par exemple. Donc on regarde des KML, on affiche des GML, mais quand-même, on travaille avec des formats classiques du SIG bureautique.

Pourtant ces formats ont d’autres atouts que les fichiers binaires habituels. Pour peu qu’une architecture web adaptée leur soit associée, ils peuvent permettre d’accéder à la donnée géographique d’une manière beaucoup plus souple. Prenons un exemple. Vous avez besoin des contours des départements de la Bretagne. Avec une approche SIG classique, vous ouvrez votre Geofla® avec votre logiciel SIG préféré, faites votre sélection, et réexportez le résultat dans une couche toute neuve (lisez quand-même les conditions d’utilisation du GeoFla® avant ;-)) Pour peu qu’il vous faille ainsi des extrations sur toutes les régions françaises, vous êtes bon pour prendre un stagiaire.

Un service web bien conçu peut faciliter les choses. Imaginez une architecture REST (Representational State transfert, ça fait un peu peur dit comme ça. Voir « Comment j’ai expliqué REST à ma femme » pour en savoir plus, ou l’excellent blog de David Larlet BioloGeek). Elle permet d’accéder à une liste des départements en appelant l’URL http://www.ign-online.fr/france/departements/. La page contient la liste des départements, ainsi que des liens permettant d’accéder à d’autres « représentations » de ceux-ci, en GML par exemple (la notion de ressource et de représentation est fondamentale dans une architecture REST. Ici les départements sont des ressources, proposées sous diverses représentations, textuelle ou géographique).

On a donc :

01 AIN Bourg-en-Bresse
02 AISNE Laon
.
.
.
voir les données en GML, KML, GeoAtom

en cliquant sur GML, on appelle en fait l’URL http://www.ign-online.fr/france/departements/GML/
Mais jusqu’ici rien de bien bouleversant. On récupère un fichier, on l’enregistre, on l’ouvre avec uDig, et on rappelle le stagiaire. Seulement l’application web susdite à d’autres tours dans son sac. A l’URL http://www.ign-online.fr/france/regions/53/departements correspond la liste des départements de la région dont le code INSEE est le 53, soit la Bretagne. Et http://www.ign-online.fr/france/regions/53/departements/GML renvoie directement un flux GML correspondant aux seuls départements bretons.
Ainsi à partir d’une seule couche de données (qui peut être au format shape, TAB, postgis, le tout étant que le langage dans lequel les services web sont écrits permette de les lire. En optant pour Python associé à GDAL on ouvre déjà d’intéressantes perspectives), on démultiplie les usages possibles par la construction de services web spécifiques. Ceux-ci sont faciles à construire, et peuvent même automatiquement exploiter les champs de chaque couche selon un principe clé/valeur (http://www.ign-online.fr/france/regions/53/departements/GML/?dept=finistere renvoyant le contour du seul Finistère). Pour peu que de bonnes métadonnées accompagnent la description de la couche, chacun peut alors bâtir sa propre requête en composant une URL.

Appelée depuis un logiciel SIG bureautique, cette URL devient une ressource géographique, au même titre qu’un fichier shape. Sans compter que des manipulations spatiales sont également implémentables en web services. Les zones inondables à Toulouse ? Facile : http://www.spatialservices.net/intersection/?url1=http://www.prim.net/cartorisque/AZI/&url2=http://www.ign-online.fr/france/communes/31555/ ! Que va faire ce web service ? d’abord récupérer chacune des URLs, puis les charger dans PostGIS par exemple, réaliser l’intersection, et renvoyer ce seul résultat. Qui sera accessible en GML, KML ou autre.

La multitude de formats n’est donc pas un frein au développement de webservices cartographiques réellement utiles. Ils ne sont que des moyens de représenter la même chose. La diffusion de la donnée doit se faire sans a priori sur l’utilisation qui en sera faite (alors que si je mets un shape à disposition, j’impose à l’utilisateur un logiciel particulier, ou la conversion du fichier avant exploitation).

La technologie existe. Manquent seulement des données de référence, un peu de temps, et beaucoup d’idées. C’est celui qui dit qui y est ? Bon, dans quelques temps, vous trouverez sur neogeo-online.net une première ébauche de ces quelques réflexions…

P.S. : le tendance actuelle est quand même au regroupement de ces formats. La participation de Google à l’OGC devrait faire du KML un nouveau standard de fait, laissant au GML les contenus très complèxes, non gérés par le KML. Dans le même temps, Atom semble s’imposer sur le RSS et ses multiples spécifications.

P.S.S. : Peu de liens dans cet article. En fait, je commence à me demander si ces articles où on trouve presque un lien par mot sont vraiment lisibles… Donc pour faire plus clair, voici juste quelques références :

http://zcologia.com/news/
http://blog.mapufacture.com/
http://cfis.savagexi.com
http://cholmes.wordpress.com/

la tour de Babel du geoweb
Étiqueté avec :                

2 pesnées sur “la tour de Babel du geoweb

  • 2 décembre 2008 à 20:20
    Permalien

    Bonjour,

    j’ai relevé une petit erreur dans votre article. Le format KMZ est une version compressée du format KML (Z comme Zippé).

    Il suffit de dézippé un fichier KMZ pour voir son équivalent KML.

    Cordialement.

    Répondre

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.