Comme tout un chacun féru de nouveautés, l’intégration d’une nouvelle version d’un standard international (le WMS de l’OGC) dans un quasi-standard des serveurs cartographiques (MapServer 5.4) me donne envie de l’essayer. Tout le problème fut de trouver un client compatible WMS 1.3. C’est le côté contraignant de l’inter-opérabilité, il faut trouver des agents capables d’utiliser la même norme, et ce n’est pas toujours le cas.
Autodesk proposant un téléchargement gratuit d’Autocad Map 2010 en version 30 jours, je me suis lancé (ou plutôt assis avec un café car le fichier à télécharger fait 2.1 Go !). Je n’avais pas vu Autocad Map depuis la version 2002, j’ai dû avoir la même sensation que le pilote de Caravelle qui se retrouve aux commandes d’un A 380… Rien que le nombre de barres d’outils vous donne l’envie de signer fissa pour une formation accélérée. C’est peut-être pour ça que c’est en téléchargement d’ailleurs.
Après quelques recherches je trouve la fonction d’ajout de couche WMS (il faut cliquer sur DATA dans les pratiques outils de gestion des cartes au dessus de la liste des couches…), avec dans la configuration du serveur un choix de version intégrant le 1.3.0. On touche au but donc. Je saisis ce qu’il faut, choisis une couche en projection Lambert (je ne dirais pas laquelle, pour ne pas raviver de querelle entre les anciens et les modernes, ce n’est pas mon propos). Résultat impeccable, bravo. Je refais un autre test avec une couche non projetée cette fois. Echec, rapport d’erreur un peu obscur… Après de longues recherches, je tombe sur le loup. La norme WMS 1.3.0 impose aux coordonnées de la bounding box d’être en lat,lon pour les systèmes de référence non projetés, et non plus en lon,lat comme pour la version 1.1.1 et comme c’est encore le cas pour les systèmes projetés en WMS 1.3.0. Donc mon AutoCad, qui n’a sans doute pas pris cette subtilité en considération, ou mal, a soumis à MapServer une requête incohérente quant à la BBOX utilisée dans le contexte EPSG:4326. Et l’inter-opérabilité pris fin.
Autre nouveauté du WMS 1.3.0 l’utilisation du paramètres CRS= plutôt que SRS= dans la désignation du système de coordonnées, bien que MapServer accepte encore les deux, avec priorité au SRS. Celui-ci peut d’ailleurs s’affranchir du registre EPSG, le WGS 84 pouvant être désigné par CRS:84 plutôt que EPSG:4326. Ces diverses subtilités n’ont pas manqué de provoquer quelques saines réactions sur la liste MapServer-users dès 2006 !
Solution beaucoup plus simple pour moi : Tilecache + Google Earth
Ah j’avais pas vu que c’était uniquement pour WMS 1.3…
Mauvaise nouvelle pour l’interopérabilité et INSPIRE puisque les utilisateurs ne vont pas s’y retrouver dans les systèmes de projection.
Reste à OpenLayers de suivre le mouvement…
L’interopérabilité a toujours souffert d’implémentations divergentes entre client et serveur. On reste sur la règle du plus petit dénominateur commun. Tant que les serveurs 1.3.0 restent compatibles 1.1 ça ne devrait pas trop poser de problèmes, et les petits soucis techniques d’un Autocad seront vite réparés. De même pour OpenLayers, c’est un client WMS 1.1.1. Il faudra qu’il intègre les spécificités 1.3.0 et sache manipuler les BBOX en fonction des CRS.
Remarque, on a le même genre de problème avec la pseudo-projection Spherical Mercator qui est encore référencée en EPSG:900913 dans bien des applications alors que l’EPSG l’a finalement référencée sous le code 3785. L’interopérabilité ne joue à plein que quand toute la chaîne logicielle adopte complètement les mêmes standards et suit rapidement leurs évolutions.
Bonjour,
Désolé pour la longueur de ce commentaire. Je donne mon point de vue (en tant que membre de l’OGC et accessoirement de l’OSGeo) sur ce sujet qui n’est pas simple à comprendre, mais qui mérite des éclaircissements à la fois pour bien interpréter le travail de l’OGC et son impact sur les implémentations qui utilisent WMS.
Je ne peux pas nier qu’il existe une certaine forme d’incompatibilité entre WMS 1.1.1 et WMS 1.3.0 du point de vue de l’ordre des coordonnées. D’un point de vue théorique, il existe un problème interopérabilité entre WMS 1.1.1 (et ses versions précédentes) et le registre géodésique de l’EPSG : les exemples de requêtes GetMap donnés par la spécification WMS 1.1.1 avec le système de coordonnées EPSG:4326 ne respectent pas l’ordre des axes de coordonnées spécifié par l’EPSG. Certains systèmes de coordonnées ont comme premier axe celui des latitudes (c’est le cas de EPSG:4326) alors que pour d’autres c’est inverse. WMS 1.3.0 corrige cela en demandant le respect de l’ordre des axes du registre de l’EPSG.
Du point de vue pratique, cela pose des problèmes à ceux qui doivent implémenter des systèmes compatibles avec les deux versions de WMS, mais ce n’est pas non plus insurmontable ! C’est d’autant moins complexe que ce changement n’a, semble-t-il, d’impact que sur le système de coordonnées EPSG:4326 (car ce sont les exemples de requêtes GetMap utilisant ce système de coordonnées qui seraient à l’origine de ce problème).
J’en profite pour rectifier un point relevé par Guillaume : « La norme WMS 1.3.0 impose aux coordonnées de la bounding box d’être en lat,lon pour les systèmes de référence non projetés, et non plus en lon,lat comme pour la version 1.1.1 ». Ce n’est pas exact. Chaque système de coordonnées doit respecter l’ordre des axes qui le définit, qu’il s’agisse d’un système projeté ou non. La meilleure preuve est que l’ordre des axes entre EPSG:4326 et CRS:84 est inversé.
Il me semble que CRS:84 a été introduit pour assurer une certaine compatibilité avec WMS 1.1.1. En effet, les exemples de requêtes GetMap de la spécification WMS 1.1.1 sont valides du point de vue de WMS 1.3.0 si l’on remplace « SRS=EPSG:4326 » par « CRS=CRS:84 ».
A noter également que le changement de SRS en CRS a été motivé par la recherche d’une meilleure homogénéité entre les différentes spécifications de l’OGC.
Concernant l’inquiétude de Pierre relative à l’interopérabilité et INSPIRE, je note simplement qu’INSPIRE privilégie les systèmes de coordonnées européens et pas tellement WGS84.
Il est vrai que la majorité des implémentations n’a pas franchi le pas de WMS 1.3.0 et que certains des points identifiés ici sont probablement des facteurs qui freinent les développeurs dans cette démarche. Cela dit, le fait que l’OSGeo et l’OGC aient signé un accord devrait ou aurait dû faciliter cette transition.
Cordialement,
Benjamin Chartier
Ah, voici le meilleur commentaire jamais posté sur ce blog, merci Benjamin !
Des aspects restent cependant compliqués. Tu notes qu’une meilleure homogénéité a été recherchée. Est-ce pour celà que pour un SRS=EPSG:4326 il faille utiliser CRS=CRS:84 en 1.3.0 ? Franchement, c’est assez déroutant. Connaîtrais-tu un bon document de référence, genre « the definitive guide for WMS 1.3.0″ avec section spéciale CRS et aussi SLD dont je n’ai pas parlé mais qui perturbent aussi les habitudes !
Merci !
Etant aussi un fervent de l’OGC (le BRGM est un membre historique !) et de l’OSGEO, mes propos n’étaient pas une critique de l’OGC.
Mais, plutôt la nécessité de fournir, y compris pour l’OGC, les éléments d’évolutions pour les développeurs ne les loupent pas.
En effet, 90 % des utilisateurs des WMS – et donc des inspiriens qui s’appuient sur 1.3 – voient que ca fonctionne avec des systèmes 1.1 et se disent que cela devrait être pareil avec la version 1.3…. et … presque oui, mais un peu non. Les arguments de Benjamin, très bon résumé des discussion OGC sur ce sujet, sont tout à fait acceptables mais il faut les faire accepter à nos utilisateurs. N’oublions pas qu’on a mis 7/8 ans pour faire fonctionner l’interopérabilité WMS, essayons de ne pas tout gacher avec la version 1.3.
Cela passe évidemment par des implémentations correctes du coté des outils Opensource et payants !
Pierre.
Pour répondre à Guillaume :
Cette incompatibilité est bien le fruit d’une recherche d’une meilleure homogénéité. Cela dit, il faut bien avoir en tête que l’interopérabilité ne se pose pas qu’entre deux versions successives d’un même standard. L’OGC a cherché à améliorer l’interopérabilité entre WMS et le registre de l’EPSG ainsi qu’avec les autres standards de l’OGC via OWS Common. Certains changements sont un peu douloureux mais parfois ils sont indispensables, surtout si l’on veut atteindre une interopérabilité entre WMS et les autres W*S.
Je ne connais pas de bon guides pour la mise en œuvre des standards de l’OGC (mis à part celui-ci qui date un peu mais qui est hors sujet ici : http://www.geowebguru.com/book-reviews/69-book-review-gml-geography-mark-up-language). La seule chose que j’ai trouvée et qui se veut être une recommandation sur l’emploi des systèmes de coordonnées est ceci :
http://www.ogcnetwork.net/node/491
Cela reste trop abstrait, je pense.
Pour SLD, depuis peu, ce standard a été divisé en deux : le profil SLD de WMS et les règles d’encodage des styles SE (Symbology Encoding). L’OGC n’a rien publié de particulier sur ce sujet, mises à part les spécifications.
Pour répondre à Pierre :
Je reste convaincu que ces changements sont une bonne chose du point de vue de l’interopérabilité. Cela dit, pour éviter cette confusion, l’OGC aurait dû faire preuve d’anticipation et mieux communiquer. On ne peut pas nier que la transition est problématique : beaucoup de gens sont au courant du problème, sans forcément le comprendre et chacun peut constater que trop de solutions n’implémentent pas WMS 1.3.0 plus de trois ans après sa publication ! Et il en va de même de SLD. On revient au constat de Guillaume : où sont les guides ?
Tout cela donne une assez mauvaise image de ces standards et de l’OGC en général. C’est dommage.
Benjamin Chartier
Pour compléter les explications de Benjamin (excellentes par ailleurs) et en tant que membre de l’OGC ayant assisté à quelques réunions du « CRS working group », j’aimerais insister (comme Benjamin l’a déjà fait) sur l’idée que la norme WMS 1.3 ne dit pas que l’ordre des axes d’un CRS géographique doit être (latitude, longitude), mais qu’il doit être tel que le spécifie l’autorité qui définit les codes. Dans le cas particulier de l’autorité EPSG, l’ordre des axes d’un système géographique est le plus souvent (latitude, longitude), mais pas toujours. De même dans le cas d’un système projeté, l’ordre des axes est souvent (Easting, Northing) – ou (x,y) si vous préférez – mais pas toujours non-plus. Par exemple EPSG:3035 utilisé pour l’ensemble de l’Europe est une projection « Lambert Azimuthal Equal Area » avec des axes dans l’ordre opposé (Northing, Easting). En Afrique du Sud, c’est la direction des axes (Westing, Southing) qui est inversée : à charge des applications de vérifier non-seulement l’ordre des axes, mais aussi leurs directions (Nord/Sud, Est/Ouest).
Cette question de l’ordre des axes a suscité d’intenses discussions à l’OGC, avec les partisans des deux camps qui se sont affrontés dans des débats parfois houleux. Il y avait d’un côté des professionnels de la géodésie qui faisaient valoir que d’exprimer les coordonnées géographiques dans l’ordre (latitude, longitude) est une pratique établie depuis des siècles, alors que la tendance des informaticiens à tout ramener dans l’ordre (x,y) est beaucoup plus récente. Il y avait de l’autre côté des informaticiens qui faisaient valoir qu’un ordre standard pour tous les CRS réduirait le risques de bugs – les commentaires précédents sur ce blog traduisent bien cette inquiétude en faisant valoir le risque de confusion que la norme WMS 1.3 risque d’entraîner.
Un des arguments des tenants de l’ordre « tel que spécifié par l’autorité » est que bien que les informaticiens soient habitués à l’ordre (x,y), les géographes et les pilotes sont eux habitués à l’ordre officiellement en usage dans leur pays, et que c’est justement cet ordre que l’autorité EPSG essaie de respecter. Si pour une raison quelconque un pilote est amené à lire directement les informations d’un service web et que l’ordre des coordonnées n’est pas celui auquel il est habitué, s’il n’y fait pas attention ça pourrait être un risque pour sa sécurité et celle des passagers.
Un autre argument est que de toute façon on ne peut pas vraiment standardiser un ordre (x,y) partout sur la planète. Au pôle sud, toutes les directions vont vers le Nord. Les axes deviennent alors « Nord le long du méridien xxx° », et il faut se référer à l’autorité de toute façon pour savoir de quels méridiens il s’agit.
En sommes, ce qui c’est passé (je crois), c’est que la norme WMS 1.0 a été écrite par des gens qui ont interprété la problématique des CRS avec des yeux d’informaticiens, sans que cette interprétation n’ait été portée à la connaissance des gens travaillant en géodésie (je précise en passant que je ne fait pas de géodésie moi-même; je ne fait que rapporter ma compréhension des débats). Quand certains géodésiens s’en sont aperçu, ils ont soulevé le problème à l’OGC alors que des WMS 1.0 étaient déjà en production, d’où les débats qui ont suivit.
Martin Desruisseaux
Bonjour,
Je suis bien d’accord avec l’approche géographique des « puristes ». Reste que les logiciels SIG sont faits par des informaticiens et que l’inter-opérabilité suppose une même qualité d’implémentation des mêmes standards dans tous les agents de la chaîne. J’ai cité Autocad, mais on peut aussi voir que MapServer a choisi de déterminer « en dur » quels étaient les CRS à « inverser » (http://mapserver.org/ogc/wms_server.html#wms-1-3-0-support). On est loin de la détection automatique de l’ordre des axes pour chaque CRS, ce dont proj semble pour l’instant incapable (« This change is sure to confuse simple clients that used to treat all SRS the same way. MapServer and PROJ will need to be extended to carry information about the axis order of all EPSG SRS codes and treat them using the correct axis order » in http://mapserver.org/development/rfc/ms-rfc-30.html). L’inconvénient majeur à mon sens est d’obliger chacun des agents WMS (serveur, client, proxy…) à être capable de déterminer l’ordre des axes, et donc de les surcharger de fichiers d’information (registre EPSG ou autre) dont ils se passaient jusqu’à présent (au moins pour les clients). Ca devient lourd, surtout pour des clients tels OpenLayers censés être « légers » et qui le sont déjà de moins en moins !
Merci pour ce billet et la discussion intéressante qui s’en suit.
Outre les modifications discutées ici savez-vous si WMS 1.3 apportent des nouveautés fonctionnelles notables par rapport à 1.1.1 ?
Non, côté fonctionnalités on en reste à ce qui avait été défini précedemment : getMap, getFeatureInfo… Rien de plus.