Outre les modifications discutées ici savez-vous si WMS 1.3 apportent des nouveautés fonctionnelles notables par rapport à 1.1.1 ?

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 !

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

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

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.

Merci !

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

Reste à OpenLayers de suivre le mouvement…