Aujourd’hui, le format par défaut de WFS est le GML. Le standard laisse néanmoins la porte ouverte à d’autres formats. Voici un exemple de requête GetFeature tiré de la version 2.0 des spécifications de WFS et qui demande une réponse en KML :

http://www.someserver.com/wfs.cgi?
SERVICE=WFS&
VERSION=2.0.0&
REQUEST=GetFeature&
TYPENAMES=PLACES&
BBOX=18.54,-72.3544,18.62,-72.2564&
OUTPUTFORMAT=KML

J’ai effectué une petite recherche pour essayer de déterminer si le format GeoJSON est une alternative répandue au format GML du côté des serveurs. Voici quelques exemples de listes de formats issues de services qui indiquent le support de JSON :

text/xml;subtype=gml/3.1.1
application/csv
application/javascript
application/shape
application/serialized.feature

text/xml; subtype=gml/3.1.1
text/xml; subtype=gml/2.1.2
application/json

text/xml; subtype=gml/3.1.1
GML2
GML2-GZIP
SHAPE-ZIP
csv
gml3
json
text/xml; subtype=gml/2.1.2

Plusieurs constats :

• le support de JSON et GeoJSON par les services WFS n’est pas rare mais est loin d’être supporté par toutes les implémentations ;
• certains de ces services supportent JSON mais pas GeoJSON ;
• la distinction entre les deux formats est impossible à faire en lisant les « capabilities » du service ;
• l’utilisation des types MIME n’est pas homogène d’une implémentation à une autre. Pour information, une discussion est en cours à l’OGC pour essayer de l’homogénéiser l’usage des types MIME ;
• les implémentations supportent souvent d’autres formats que GML pour l’opération GetFeature mais pas pour les autres opérations (DescribeFeatureType et Transaction notamment).

En conclusion, oui vous pouvez utiliser du GeoJSON en sortie d’un service WFS. Il y a un « mais » : la déclaration de ce format dans les capabilities des services WFS reste imparfaite ce qui peut entrainer des problèmes d’interopérabilité entre clients et services. Par ailleurs, son usage semble se limiter à l’opération GetFeature. On peut également noter que des initiatives au sein de l’OGC visent à définir des interfaces de services web respectant les principes de REST. Les travaux (propositions faites par ESRI et CubeWerx) allant dans ce sens font figurer JSON et GeoJSON en bonne place.

Note pour ceux qui utilisent MapServer : le support de JSON peut être ajouté en sortie d’un service WFS à l’aide de templates (cf. ici).

Nous vous proposons donc ce document, en anglais : Télécharger

En quelques mots voici ce qu’on y trouve :

L’essentiel des exigences Inspire pour les services de visualisation s’appuie sur WMS 1.3.0 / ISO-19128, déjà pris en charge par MapServer. Les manques ne sont donc pas trop importants mais néanmoins suffisants pour imposer quelques interventions.

Pour ce qui est du GetCapabilities du service, le guide technique Inspire décrit deux scénarios (scenarii pour les esthètes, je sais qu’il y en a parmi les lecteurs de ce blog) :

• Le premier dans lequel il suffit d’inclure le support de la langue (ok, ce n’est pas rien), et un lien externe vers un document de métadonnées de service (potentiellement présent dans un catalogue tel que GeoNetwork / GéoSource donc)
• Le deuxième, plus confus, dans lequel on injecte également les éléments principaux des métadonnées de service directement dans le GetCapabilities, tout en pointant quand-même vers un catalogue pour garantir la compatibilité avec les services de découverte… Usine à gaz en vue, surtout quand il s’agira de maintenir ces informations en cohérence.

Le choix d’un scénario ou d’un autre revient à l’Etat membre, et il semblerait pour l’instant que ce soit le scénario 1 qui soit privilégié en nos contrées.

Concernant les autres blocs du GetCapabilities, et la description des Layers notamment, on peut noter quelques éléments optionnels en WMS qui deviennent obligatoires avec Inspire (Fees, Keyword…) et dont le contenu peut être amené à suivre un certain formalisme. Quelques autres sont vraiment spécifiques à Inspire (MetadataDate…) ou peuvent se retrouver en plusieurs fois au lieu d’une seule en WMS (ContactInformation). Tous ces ajouts doivent donc être intégrés dans un bloc spécifique ExtendedCapabilities dédié à Inspire.

Au final, la principale difficulté réside bien dans la prise en charge du multi-linguisme, qui oblige le service à interpréter un paramètre d’appel complémentaire (language) et surtout le traiter. Cela suppose d’exposer les langues acceptés (supported languages) dans le GetCapabilities, et d’être capable de renvoyer des « titles » et des « abstracts » dans la langue choisie par l’utilisateur, pour peu qu’elle fasse partie des « supported languages ».

Pour qui connait la structure d’un mapfile, la crainte de voir se multiplier les éléments de METADATA tels que « wms_title_fr », « wms_title_en »… peut sembler justifiée. Surtout lorsqu’on voit que les styles doivent également être soumis à ce mécanisme et voir leur titre traduit, le nom restant la clé unique. Déjà que les styles nommés c’était un peu du sport, si en plus il faut en traduire les titres (pour lequel il n’y a aucun tag dans le Mapfile, MapServer se contentant de reprendre le nom du style dans le tag style:title). Pour parer au plus pressé, et il y en a quelques uns pour qui ça devient urgent, on peut certes envisager la multiplication des entrées dans les METADATA. Mais pour envisager l’avenir sereinement (quand on aura 5 styles nommés à traduire dans 8 langues, pour chacun des 50 layers du mapfile…), je pense qu’il est nécessaire de mettre en place un mécanisme externe au mapfile, utilisant gettext par exemple. Dans cette optique, le contenu du mapfile serait considéré comme correspondant au langage par défaut. Un script externe permettrait de générer les fichiers de langue pour chacun des « supported languages » décrits dans le fichier map, prenant en clé/valeur les valeurs récupérées dans le fichier map et laissant donc à l’utilisateur le soin de les remplacer par les traductions correspondantes. Cette approche permettrait de plus de déléguer les tâches de traduction à des spécialistes (parce qu’un géomaticien qui se met au maltais, ça peut faire mal) sans avoir à leur transmettre un mapfile (parce qu’un traducteur devant un fichier map, ça peut faire mal aussi). A chacun son boulot.

Merci à Assefa Yewondwossen de DMSolutions et à Daniel Morissette de MapGears pour leurs éclairages et leur relecture, ainsi bien sûr qu’au BRGM pour sa démarche générale en faveur de l’OpenSource et la publication de ce document en particulier.

Vous serez alors sans doute ravis d’apprendre, comme je peux l’être, l’intégration au sein de MapServer des projets TinyOWS, fièrement soutenu par nos collègues d’Oslandia, et de mod_geocache, un projet récent mais diablement performant de Thomas Bonfort (à qui l’on devait déjà le support AGG dans MapServer) qui est un module Apache dédié au tuilage mais qui peut aussi fusionner des tuiles à la volée pour construire la réponse à une requête WMS non tuilée.

Que peut signifier « intégration » dans ce contexte ? C’est déjà le partage d’un fichier de configuration identique, le fameux MapFile, dans lequel devront donc être déclarés les éléments permettant la mise en route de ces nouveaux services. C’est aussi l’incorporation des sources de ces deux projets à celles de MapServer, de sorte que l’on compilera tout cela à la fois de manière à produire une sorte de bundle multi-tâches. C’est également le bénéfice pour MapServer d’approches techniques innovantes. Il paraît que MapServer en module Apache c’est pour bientôt aussi et que les résultats des tests sont très prometteurs. C’est enfin l’intégration de chacune des communautés de ces deux projets à celle de MapServer et de ce fait l’implication de la communauté MapServer dans l’amélioration de ces one-man-projects qu’ils étaient jusqu’alors.

Ne vous précipitez pas tout de suite vers la dernière archive des sources de MapServer, nous en sommes seulement à une phase d’intentions avancées disons. Mais il est heureux de voir une telle initiative voir le jour, d’autant qu’elle promeut la qualité du travail de deux petits Français.

Le problème se situe au niveau du calcul de la BBOX de la couche en coordonnées géographiques (WGS84), dont le résultat est exposé dans la balise EX_GeographicBoundingBox du GetCapabilities. Le calcul de cette BBOX se fait sans vérifier que le méridien d’origine de la projection source de la donnée est bien Greenwich, qui est celui utilisé par le WGS84. Dès lors, si vos données sont dans un système de référence utilisant le méridien de Paris comme origine (les Lambert français de la NTF par exemple, à la différence du Lambert 93 (RGF93) qui utilise Greenwich plus un décalage), la BBOX en WGS84 sera erronée car décalée de plus de 2 degrés vers l’ouest.

Bon, mais qu’est-ce que ça change en pratique ? Je suis sûr que nombre d’entre vous ont déjà utilisé MapServer en WMS 1.3.0 sur ce type de projection sans rencontrer de problème… Il se trouve que certains logiciels clients WMS (l’excellent QGis notamment), plus malins que d’autres, se servent de cette information pour déterminer l’emprise de la couche (quelle que soit la projection utilisée pour l’affichage d’ailleurs), et n’envoient donc pas de requête au serveur WMS quand la vue se situe à l’extérieur de cette emprise, afin de ne pas solliciter inutilement le serveur. Finaud donc. Si vous publiez des données France entière, il y aura recouvrement, et donc pas de problème (à moins peut-être de zoomer sur Strasbourg par exemple. A tester sur vos services WMS 1.3.0 préférés avec QGIS. J’en ai déjà trouvé un…). Mais si l’emprise de vos données est suffisamment étroite (une agglomération par exemple), vous ne verrez tout simplement rien là où vous comptiez les voir apparaître, car d’après le GetCapabilities les données ne se trouvent pas là du tout. Vous ne verrez non seulement rien, et certainement pas d’erreur, et vous risquez de passer quelque temps (je parle d’expérience) à vous creuser la tête pour comprendre ce qui ne va pas dans votre configuration. Sauf que la configuration va bien. Là où ça devient énervant, c’est que les clients WMS qui envoient comme des bourrins des requêtes au serveur où qu’on se situe, ignorant par là la présence et le rôle de la balise EX_GeographicBoundingBox, ces barbares donc, vont eux recevoir une réponse correcte, puisque la reprojection de la donnée elle-même fonctionne normalement. Funeste sort que celui des clients WMS les plus exigeants, les plus respectueux de l’esprit de l’inter-opérabilité, induits ainsi en erreur par un calcul approximatif.

Mais heureux dénouement qui voit les lecteurs assidus de ce blog non seulement informés mais dépannés par un patch tout frais déposé sur le bug-tracker de MapServer ! Pour l’utiliser, il suffit de l’appliquer (commande patch mapows.c wms_1.3.0.patch) au fichier source puis de recompiler et remplacer son mapserv par le nouveau. Il devrait également être rapidement disponible dans la version officielle.

Ce document volumineux (plus de 300 pages) est riche en informations pour ceux qui s’intéressent au déploiement de services WMS dans le cadre d’INSPIRE. Ses annexes décrivent comment paramétrer des services motorisés par ArcGIS et MapServer et comment les consommer depuis une variété intéressante de clients (Gaia, WorldWind, Google Earth et le portail OneGeology notamment).

La confrontation de ce document au guide technique des services de visualisation d’INSPIRE est également instructive. Le premier point qui saute aux yeux : le livre de recettes écossaises propose d’utiliser WMS 1.1.1 (avec MapServer) et WMS 1.3 (à l’aide d’ArcGIS) alors que le guide technique d’INSPIRE recommande WMS 1.3. La volonté de continuer à supporter WMS 1.1.1 est logique tant la quantité de services ne supportant pas WMS 1.3 est importante. Il est également possible que ces recettes datent de l’époque où MapServer ne supportait pas encore WMS 1.3.

Le deuxième point qui a attiré mon attention réside dans la manière de gérer le multilinguisme. Le document n’est pas très bavard sur ce sujet. Il fait l’impasse sur la présence du paramètre LANGUAGE dans les URL des requêtes adressées aux services WMS. Par contre, il recommande de déployer autant de services que de langues à supporter. Ainsi, chaque service n’a qu’une langue à gérer. Les spécificités de chaque langue peuvent donc être gérées au niveau de chaque service déployé. Cette solution est suggérée par moment (mais pas de manière homogène) dans la version 2.12 du guide technique d’INSPIRE. Elle a l’avantage d’être facilement mise en œuvre avec les logiciels actuellement disponibles sur le marché. Cette approche du multilinguisme ne me satisfait guère et je ne serais pas étonné qu’elle disparaisse totalement du guide technique d’INSPIRE dans ses prochaines versions au bénéfice d’une solution basée sur l’emploi du paramètre LANGUAGE utilisé de manière homogène pour toutes les opérations de WMS.

Un dernier point qui vaut la peine d’être mentionné : pour ce qui est de la sécurité et de l’authentification des utilisateurs (dans le cas où l’accès à certaines opérations ou données ne doit pas être libre), le document fait un rappel de quelques standards et outils qui pourraient être employés. Aucune recommandation claire ou tranchée n’est faite sur ce sujet. Ce n’est pas très étonnant tant les solutions n’ont pas l’air d’être mûres sur le sujet (pour s’en convaincre il suffit de voir à quel point ce sujet n’avance guère du côté de l’OGC). On peut toutefois noter l’implication d’EDINA (l’un des contributeurs au livre de recettes) dans l’organisation d’un prochain test d’interopérabilité (Interoperability Experiment) de l’OGC sur l’emploi conjoint de Shibboleth et de services web géospatiaux (cf. ici).

Une lecture intéressante qui laisse tout de même une légère impression d’inachevé. Celle-ci n’est pas uniquement imputable aux auteurs. En effet, reconnaissons que certains sujets ne sont pas tout à fait mûrs à la fois du côté de la Commission Européenne et du côté des solutions logicielles (pour ne pas citer l’OGC, les éditeurs et les projets libres). Les auteurs en sont conscients puisqu’ils insistent sur le fait que ce document est destiné à évoluer. Ils annoncent également qu’un livre de recettes pour WFS devrait voir le jour en 2010 ou 2011.

<GDAL_WMS>
  <Service name="WMS"> --> Description du type de service (WMS, TMS...)
    <Version>1.1.1</Version> --> Version du service
    <ServerUrl>http://labs.metacarta.com/wms-c/Basic.py?</ServerUrl>
                    --> Url d'accès au service
      <Layers>basic</Layers> --> Couches à récupérer
  </Service>
  <DataWindow> --> Configuration plus générale de la données distante
    <UpperLeftX>-180.0</UpperLeftX> --> Sur ces quatres lignes, la bbox
    <UpperLeftY>90.0</UpperLeftY>
    <LowerRightX>180.0</LowerRightX>
    <LowerRightY>-90.0</LowerRightY>
    <TileLevel>19</TileLevel> --> Le nombre de niveaux dans le cache
    <TileCountX>2</TileCountX> --> Le nombre de tuiles en X à la plus
                                   faible résolution (niveau 0)
    <TileCountY>1</TileCountY> --> Le nombre de tuiles en Y à la plus
                                   faible résolution (niveau 0)
  </DataWindow>
  <Projection>EPSG:4326</Projection> --> Projection de la source de données
  <BlockSizeX>256</BlockSizeX> --> Largeur des tuiles
  <BlockSizeY>256</BlockSizeY> --> Hauteur des tuiles
  <BandsCount>3</BandsCount> --> Canaux de couleur dans l'image
                                 (ici, 3 pour RGB)
</GDAL_WMS>

Avec ces informations, GDAL se retrouve capable de traiter la ressource distante comme une donnée locale. Mais ce n’est pas tout. MapServer pouvant utiliser un tel fichier de configuration XML comme source de données d’un LAYER, on peut connecter le service distant à un contexte MapServer particulier, et créer un service WMS non tuilé exploitant des données distantes tuilées. Pratique pour les outils SIG bureautiques par exemple, qui restent incapables d’exploiter le WMS-C !

La configuration d’un tel LAYER dans MapServer est assez basique :

LAYER
 NAME test_wms_c
 DATA "wms_c.xml"
 METADATA
   "ows_title"    "Couche WMS-C réassemblée"
 END
 TYPE raster
 PROCESSING "OVERSAMPLE_RATIO=1" --> Ne pas récupérer
                                     plus de tuiles que
                                     nécessaire (directive pour GDAL)
 PROCESSING "RESAMPLE=BILINEAR" --> rééchantillonner l'image
 STATUS ON
 PROJECTION
 "init=epsg:4326"
 END
END

On peut alors reprojeter la ressource initiale, ainsi que l’exploiter sur des échelles intermédiaires non prévues dans le tuilage. Attention quand-même à ne pas trop en faire, car les tuiles reprojetées et rééchantillonnées ne seront pas forcément très belles à voir. L’idéal reste quand-même de conserver au moins la projection initiale.

En résumé nous avons donc :

  ressource distante tuilée, définie sur certaines échelles
                             et une projection spécifique
     |
     |
  GDAL : calcule les requêtes à effectuer,
         récupère les tuiles, les assemble,
         reprojette si demandé,
         découpe si nécessaire
     |
     |
  MapServer : publie la nouvelle ressource pseudo-locale
              en toute liberté (projection, échelles...) mais
              avec une qualité du rendu potentiellement
              dégradée (en fonction des transformations effectuées).

Pour les obsessionnels, oui, on peut aussi mettre en cache la ressource MapServer locale. Mais pas besoin de TileCache pour cela. Les « minidrivers » intègrent un mécanisme de cache qui permet à GDAL de stocker localement les tuiles récupèrées et ainsi de pouvoir les réutiliser plus tard. Pour ce faire, il suffit de rajouter un bloc « cache » dans le fichier XML (voir la doc pour cela).

Mais je sens déjà la question venir chez tous les habitués des caches… Comment GDAL fait-il pour déterminer les résolutions et la grille à utiliser ? Ah, bonne question. Pour les résolutions, autant le dire tout de suite, il suppose unilatéralement que chaque niveau vaut la moitié du précédent, ou que chaque tuile se subdivise en quatre si vous préférez. C’est l’approche standard, mais si on vous demande du 25k, 20k,15k,10k,5k, ça ne va pas être possible.

Pour les limites de la grille, l’exemple plus haut se base sur une grille standard WGS sur le monde entier, et le TileCount permet de calculer l’emprise des tuiles du premier niveau, puis des niveaux suivants. Pour des emprises plus spécifiques, on peut aussi utiliser TileX et TileY, qui représentent des valeurs à ajouter pour gérer un décalage de la grille sans toucher à l’extent globale.

Les domaines d’application sont nombreux. On peut citer d’emblée :

• L’intégration de données tuilées dans des clients non prévus pour cela
• La reprojection de données tuilées
• L’utilisation de données tuilées à des zooms spécifiques non disponibles
• L’alignement des grilles de deux ressources tuilées configurées différemment
• L’exploitation en pur WMS de données lourdes à générer (Open Street Map par exemple)
• Et sans doute bien d’autres problèmes d’exploitation que l’on rencontre.

Ainsi, ce petit exemple illustre bien, une fois de plus, les étonnantes possiblités offertes par MapServer et GDAL quand ils sont utilisés de concert. Plus que le strict respect des normes, c’est la liberté qu’ils donnent aux utilisateurs pour résoudre leurs problèmes qui est précieuse.

Carte avec rotation

Inutile d’attraper un torticoli, tout est normal. Ce n’est que l’expression de l’utilisation du nouveau paramètre ANGLE dans MapServer et également disponible dans GeoServer, que chacun des logiciels implémente dans son interface WMS.  L’intérêt principal réside dans le fait que si la carte est bien pivotée, les labels restent lisibles à l’horizontale, ce qui n’était pas le cas avec des rotations appliquées a posteriori, sur l’image finale.

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 !