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.

 

Inter-opérabilité réelle contre inter-opérabilité supposée
Étiqueté avec :    

8 pesnées sur “Inter-opérabilité réelle contre inter-opérabilité supposée

  • 12 septembre 2015 à 9:48
    Permalien

    Bien vu! J’hésite entre rire et pleurer. Les évaluations de l’année montrent une faiblesse d’existence des services de consultation, alors si, en plus, ils ne sont pas fonctionnels, je dis [CENSURED].
    Je fait suivre.

    Répondre
  • 12 septembre 2015 à 10:06
    Permalien

    C’est pas tant ce service-ci en particulier, mais quand je vois la fréquente difficulté que je peux éprouver, malgré mon expérience, pour afficher un flux WMS c’est assez décourageant. Au-delà des aspects INSPIRE, je pense que des bonnes pratiques de mise en oeuvre (bon calcul des extents, affichage de qqchose à l’échelle initiale, bonne prise en charge des projections…) serait utile pour faciliter l’usage de ces services par des utilisateurs moins chevronnés.

    Répondre
    • 14 septembre 2015 à 9:44
      Permalien

      Bonjour Guillaume,

      Merci pour cet article. Personnellement, j’avais été tenté d’envoyer un email au service qui administre ce service pour améliorer le contenu de ses « capabilities ». Cela confirme bien que l’exploitation de ce service n’est pas des plus aisée.

      Concernant le premier écueil mentionné : oui effectivement pour bien faire l’URL des services web devrait être quelque chose de résolvable par les navigateurs internet. La faute est imputable à l’OGC qui n’a pas bien compris ce qu’est internet. Il faudrait vraiment qu’ils comprennent qu’un service doit être capable de se décrire de manière plus simple. Lorsque l’on utilise l’URL du service, il devrait renvoyer un document XML lorsque le client demande un truc avec un mime type text/xml ou application/xml et renvoyer vers une page web compréhensible par un humain lorsque qu’un mime type text/html est demandé. Devoir écrire une requête avec ?service=WMS&request=GetCapabilities (sans se tromper dans les majuscules qui plus est) c’est vraiment n’importe quoi. En somme, si on pouvait être plus proche de l’esprit de REST ce serait mieux.

      Mais ça c’est de la responsabilité des membres de l’OGC de se bouger. Il faut quand-même savoir que j’ai entendu un membre éminent de l’OGC asséner que interopérabilité entre deux systèmes est atteinte lorsque quelqu’un peut concevoir une transformations des informations produites par un système pour qu’elle soit intelligible par un autre. Grosso modo, si on a un développeur sous la main qui est capable de faire un bout de code qui assure la communication entre les deux systèmes c’est bon. C’est pour cela que les standards ont une tendance à devenir abstraits et à s’éloigner du concret, contrairement à ce que propose en général la communauté Open Source. Il y a des gens qui ne comprennent pas que ce qu’attendent les utilisateurs c’est que les systèmes communiquent bien entre eux directement ! Bref, c’est pas gagné.

      Pour rester dans le domaine de l’accessibilité des informations dans l’esprit de ce qu’est internet, j’ai noté que les metadataurl renseignées dans les capabilities du service ne sont pas top : le mime type déclaré est « text/plain » alors que le lien renvoie vers une page HTML. « text/html » aurait été plus opportun. Côté bonne pratique, plusieurs plates-formes régionales déclarent deux metadataurl par couche :
      – une avec le mime type « text/html » qui renvoie vers la fiche de métadonnées en HTML telle qu’elle devrait être consultée par un utilisateur humain normal ;
      – une autre avec le mime type « text/xml » qui renvoie vers le document ISO 19139 (en XML donc) qui devrait être utilisée par les systèmes informatiques
      Car il ne faut pas oublier que ces informations sont à destination de deux publics : les gens et leurs outils.

      Concernant la définition de vraies bonnes pratiques sur la mise en oeuvre de services WMS, WFS… Des groupes/commissions du CNIG sont chargés de cela en France. Ses travaux sont trop cantonnés au contexte INSPIRE à mon goût et les documents sont, je pense, pas suffisamment accessibles ou trop cryptiques. Mais là, la faute est plutôt du côté des éditeurs, des intégrateurs et des utilisateurs qui ne sont pas suffisamment présents ou qui ne se font pas suffisamment entendre lors des réunions du CNIG et des appels à commentaires sur les documents. Les documents qui sont produits sont naturellement à l’image de ceux qui y contribuent.

      Je m’arrête là, sinon mon commentaire va être plus long que ton article.

      Répondre
      • 14 septembre 2015 à 9:55
        Permalien

        Ah, tu lui trouves encore plus de défauts que moi ! mais les metadataurl, c’est déjà le niveau 3, que je n’ai même pas osé abordé.
        Concernant les bonnes pratiques, tu as raison, cela nécessiterait que certains se bougent un peu plus (dont moi…). Mais tout cela est bénévole, comme l’OGC, l’AFIGEO et autres, et coûte en temps et en frais de déplacements. Donc je comprends un peu la frilosité du privé à ne pas vouloir trop s’impliquer dans des groupes de travail de ce type.

        Répondre
        • 15 septembre 2015 à 21:16
          Permalien

          Oui, tu as raison. Mais c’est bien le privé qui râle lorsque l’interopérabilité réelle n’est pas au rendez-vous. Et c’est bien le privé qui possède les compétences les plus pointues grâce à ses travaux d’intégration. Du coup, il me paraît légitime que le privé contribue à l’établissement de bonnes pratiques, ne serait-ce qu’en réagissant aux appels à commentaires. Chacun fait selon ses moyens.

          Répondre
  • 22 septembre 2015 à 21:45
    Permalien

    On y a tous plus ou moins cru à un moment, mais INSPIRE est bel et bien un mirage qui a fait son temps (et son argent!)… Heure de la mort?

    Répondre
    • 25 septembre 2015 à 10:53
      Permalien

      De mon point de vue INSPIRE n’est pas une mauvaise idée. Sur le fond le fait de faciliter les échanges de données produites par des autorités publiques est une bonne chose. D’ailleurs l’article de Guillaume Sueur n’est pas une attaque en règle contre INSPIRE mais la mise en évidence que l’interopérabilité entre services web et applications clientes n’est pas facile à atteindre. Si INSPIRE peine à donner des résultats en France (je ne connais pas la situation au-delà de nos frontières), il faudrait plutôt chercher les raisons de ce relatif échec dans la manière dont nous travaillons.

      INSPIRE restera pour nous un mirage tant que nous continuerons à avoir X bases de données de limites communales dont aucune n’est fiable, tant que nous aurons 2 bases de données parcellaires différentes, tant que nous n’aurons pas de base de données géographique librement accessible sur les documents d’urbanisme… Tant que nous n’aurons pas les moyens de produire et maintenir une information fiable (ce qui suppose d’avoir mis en place une organisation adaptée et que les moyens soient à la hauteur des objectifs), INSPIRE ne sera qu’un mirage mais ce n’est pas forcément la faute d’INSPIRE.

      Répondre
  • 25 septembre 2015 à 12:23
    Permalien

    Pour compléter les propos de Benjamin et sa réponse à un précédent commentaire peu constructif, j’ajouterais que mon propos était surtout de distinguer inter-opérabilité et obligation INSPIRE. INSPIRE vise à construire une infrastructure de données européenne dont l’inter-opérabilité est une nécessité, mais pas une obligation formelle. La partie contraignante d’INSPIRE impose juste de publier données et métadonnées selon des standards même pas nommés, dont CSW/WMS/WFS sont une parfaite illustration, mais seulement une illustration. Ce sont ensuite les divers groupes techniques chargés de la mise en oeuvre pratique de la directive qui rajoutent des exigences, via les Technical Guidances, non contraignantes pour les diffuseurs, mais conditions nécessaires à une réelle inter-opérabilité. Et force est de constater que si l’effort a été fait sur le formalisme des métadonnées du point de vue réglementaire, les pratiques de mises en oeuvre souffrent encore de faiblesses et d’absence d’homogénéité, ce qui suffit souvent à mettre à la peine les utilisateurs.

    Répondre

Laisser un commentaire

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