Inter-opérabilité réelle contre inter-opérabilité supposée

11 septembre 2015
OGC & ISO

L’inter-opérabilité est un des enjeux majeurs de la publication de jeux de données géographiques sur le web. C’est la condition nécessaire (mais pas forcément suffisante) au partage des flux cartographiques et à leur bonne exploitation. Elle suppose donc la conformité de clients et serveurs aux mêmes standards, par exemple le WMS de l’OGC. Afin de parfaire cette oeuvre déjà ambitieuse, la directive INSPIRE impose certaines règles de publicité, description et mise à disposition des jeux de données, et des guides techniques se chargent de proposer des implémentations visant à garantir le maximum d’inter-opérabilité.

A l’occasion de la publication des données françaises de la base européenne Corine Land Cover (voir http://www.statistiques.developpement-durable.gouv.fr/donnees-ligne/li/2496.html) on se dit qu’on a là la quintessence de l’Inspiritude achevée dans la mesure où il s’agit d’un jeu de données européen (mais construit nationalement), mis en oeuvre par le Ministère de l’Environnement et du Développement Durable et intéressant potentiellement des profils d’utilisateurs extrêmement variés, de l’aménageur au naturaliste et de la FNSEA au ZADiste. Il s’avère donc parfaitement adapté à une petite mise à l’épreuve de son inter-opérabilité réelle face à son inter-opérabilité supposée qui, avec un tel pedigree, ne peut qu’être maximale, genre tu regardes l’URL et tu vois la carte en réalité augmentée.

Partons donc à la recherche de l’URL du service, seul vrai sésame de la cartographie interconnectée. En deux clics, nous rebondissons vers cette page à l’URL pas très friendly quand même (mais ce n’est pas grave puisque ce n’est pas le service lui-même) :

http://www.statistiques.developpement-durable.gouv.fr/donnees-ligne/t/services-web.html?tx_ttnews[tt_news]=24272&cHash=f13387facfa861b064b0771ca50e3bfa

Dans la page, nous trouvons une série de liens vers les différents avatars de la publication cartographique en ligne, plutôt bien décrits, même s’il faudrait en 2015 se rappeler que le WMS-C a fait son temps et que c’est le WMTS qui a pris la relève et qui est recommandé par INSPIRE. Mais déjà, on constate la complexité paradoxale qu’il y a à diffuser une URL de service WMS. Car une URL, par habitude, utilité, esprit grégaire ou automatisme, est généralement associée à un lien HTML dans une page web. Une balise « <a></a> » pour ceux qui s’en souviennent encore. Alors ici aussi, « WMS » est paré de ces attributs magiques le rendant cliquable. Sauf qu’un navigateur n’est pas un client WMS et ne sait rien en faire. Le serveur distant répond donc avec une belle erreur en XML, format particulièrement compréhensible par tout un chacun, qui ne dit d’ailleurs pas « Ouvre donc cette URL avec un client WMS », ce qui pourrait être constructif, mais tout simplement « Could not determine geoserver request from http request » ce qui peut s’apparenter à GFY en langage OGC.

On a donc déjà fait le tri entre les béotiens qui vont ramasser leur râteau en se disant que ça ne marche pas, et ceux qui savent que ah ah, il ne faut pas bêtement cliquer sur le lien, mais cliquer-droit et faire « copier le lien » pour aller s’en servir ailleurs. Le public concerné s’étant alors mécaniquement réduit aux 0,001 % de la population capable de comprendre WMS et de cliquer-droit, car ce n’est pas expliqué dans tous les masters de géomatique, certains prenant ça comme une condition d’admission, d’autres n’abordant tout simplement pas le WMS, le public ainsi sélectionné donc, on va pouvoir passer aux choses sérieuses…

Car maintenant qu’on a savamment copié le précieux lien dans le presse-papier, il va falloir aller le coller quelque part, et ce quelque part doit être un client WMS, sous la forme d’une application bureautique type QGIS ou sous la forme d’une visionneuse cartographique en ligne type Geobretagne. Le geste est technique, car il faut coller l’URL dans la bonne rubrique (pas WFS par exemple), mais, après quelques ratés, il va normalement déboucher sur l’affichage de la liste des couches proposées par le service ! Car le client WMS est un malin lui. Contrairement au navigateur web il a su trouver les mots pour s’adresser au serveur distant. Il a su lui chuchoter à l’oreille « GetCapabilities » avec ce mélange d’abandon et de soumission lascive qui seul peut faire céder un GeoServer tournant sous Tomcat 6 avec 1 Go de RAM. L’obtention de la liste des couches, c’est un peu le boss du niveau 1 de l’inter-opérabilité. C’est ensuite que ça se corse.

Il va en effet falloir faire son choix dans la liste. Car si on est arrivé là par envie plus ou moins masochiste de consulter CorineLandCover 2012, on se rend alors compte qu’il y a un CLC vecteur et un CLC raster ainsi qu’un CLC métropole et un CLC DOM. Le produit cartésien de ses diverses options s’élevant à 4, cela permet de réfléchir un peu à ce qu’on est en train de faire, puis de choisir les paramètres complémentaires de visualisation, à savoir la projection et le format d’image. Notez qu’on a alors perdu les 0,0005 % de la population qui était arrivé jusque là un peu par erreur mais qu’une bonne maîtrise technique avait néanmoins encouragé à persévérer. Nous ne sommes donc plus qu’environ une centaine de passionnés bien décidés à cliquer sur « Ajouter la couche » dont l’affichage final au bon endroit sur la carte constituera la victoire sur le boss de ce niveau 2. Et là, alors qu’on croyait bien maîtriser son sujet et qu’on avait jusqu’alors surmonté en souplesse les différents obstacles, on clique et.. RIEN ! Nib, que dalle, nada. Aucun affichage. Dans aucun des clients. En premier chef, on culpabilise. C’est toujours le cas en informatique. On a dû faire une erreur quelque part, choisir un Lambert 93 pour afficher la Guyane ou avoir déplacé la carte au pôle Nord. Mais après quelques nouvelles tentatives, changements de paramètres, chargement de données complémentaires aidant à la bonne localisation, déplacements divers et changements d’échelle, toujours rien. Rien de rien. On comprend alors avec soulagement mais aussi angoisse que l’erreur vient plus probablement du serveur, on passe au niveau caché, celui du diagnostic du flux WMS récalcitrant. C’est plus facile à faire dans un environnement web, car la console permet de voir les requêtes qui sont envoyées au serveur et les réponses d’icelui. On reprend donc GeoBretagne, on regarde les requêtes, on repère le GetMap et la réponse associée :

<ServiceExceptionReport xmlns="http://www.opengis.net/ogc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.3.0"xsi:schemaLocation="http://www.opengis.net/ogc http://clc.developpement-durable.gouv.fr:80/geoserver/schemas/wms/1.3.0/exceptions_1_3_0.xsd">
<ServiceException code="LayerNotDefined" locator="layers">Could not find layer CLC m??tropole (Vecteur)</ServiceException>
</ServiceExceptionReport>

Le service indique, méprisant, que la couche qu’on demande n’est pas définie. Qu’elle n’existe pas dans le service alors même qu’on l’a choisie dans la liste qu’il avait lui-même proposée. En regardant un peu mieux on voit les ?? à la place du « é » de métropole. Et on comprend tout. Tu fais un service inter-opérable à l’échelle européenne et tu mets des accents dans les noms des couches ? Non mais allô quoi ! De la sorte, la dizaine d’utilisateurs encore décidés à faire afficher cette couche n’ont plus qu’à essayer de trouver un client WMS capable de bien encoder les accents dans l’URL. Et bon courage le jour où vous voudrez trouver la même chose sur la Pologne et que le type aura mis « różnorodność » dans son nom de couche.

En conclusion, voici un jeu de données européen, standardisé, parfaitement conforme à ses spécifications, doté d’une fiche de métadonnées INSPIRE à faire péter les scores NSi2 lors des rapportages annuels, décidément plus quantitatifs que qualitatifs, qu’il se révèle impossible de consulter selon les modalités d’utilisation de services prévus par notre directive chérie. Mieux… On remarque dans le Geocatalogue qu’on peut y visualiser la donnée en direct et ça échoue autant que les essais qu’on avait pu faire, ce qui est bien normal, mais que dans le même temps, une application dédiée de visualisation se révèle parfaitement opérationnelle. Après examen, on découvre qu’elle utilise le flux WMS-C, non standard car tuilé mais sans grille de référence (voir par exemple ce que répond le serveur à cette requête) et ne proposant pas la projection Mercator Sphérique pour les clients web. Donc voici ce jeu de données qui devrait être un parangon de vertu inspirée exploité dans son application de visualisation via des flux non INSPIRE et non référencés dans sa propre fiche de métadonnées. Est-ce l’illustration assumée des limites pratiques de l’inter-opérabilité telles que de nombreux acteurs de la géomatique essaient péniblement de la mettre en oeuvre ? Reste que cette incapacité à accéder aux flux ne semble pas gêner grand-monde non plus, comme si une bonne application de visualisation maison et une interface de téléchargement suffisaient à répondre aux besoins. A quels besoins INSPIRE s’adresse-t-elle déjà ?

ADDENDUM POST SCRIPTUM : Après analyse plus poussée du contenu du service j’ai mieux compris le problème. CLC Métropole est un groupe dans lequel on trouve différentes versions du CLC (2006, 2012…) parfaitement utilisables car avec des titres sans accents. Néanmoins deux remarques : pas plus que pour une couche un nom de groupe ne doit contenir de caractères spéciaux, et le contenu d’un groupe a vocation à être co-visualisé (c’est pour cela que le client WMS permet de le sélectionner, pour en afficher toutes les couches d’un coup) alors que le contenu de ce groupe n’est clairement pas co-visualisable puisqu’il s’agit plutôt d’une série temporelle de données.