Comme ce fut le cas pour GeoNetwork, nous avons réalisé à la demande du BRGM un audit de MapServer face aux exigences de la directive INSPIRE pour ce qui est des ViewServices, autrement dit les services de visualisation.

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.

MapServer et Inspire
Étiqueté avec :    

5 pesnées sur “MapServer et Inspire

  • 21 avril 2011 à 23:25
    Permalien

    Bonjour,

    merci de partager ce document avec la communauté. Peut-être me permettrez-vous un bémol aux explications techniques que vous apportez. Le multilinguisme N’EST PAS une priorité pour nous en ce moment. D’une part nous sommes beaucoup pris par les aspects les plus triviaux (créer et publier les métadonnées, les services de consultation, bientôt les services de téléchargement…), d’autre part je suis très curieux de voir comment la Commission, gardienne des traités, va l’appliquer sur le portail INSPIRE dont elle a la responsabilité.
    Il est bien naturel que le BRGM, à qui le ministère chargé de l’environnement a confié des missions sur le sujet, reste une des têtes chercheuses et pense au coups suivants. Pour les autres, AMHA vous pouvez économiser des ressources en attendant l’exemple de la Commission européenne.

    Répondre
    • 22 avril 2011 à 0:11
      Permalien

      Bonsoir Marc,
      Ce n’est pas tant de penser au coup suivant qu’il s’agit mais bien de prendre en considération un thème qui a mérité une section spécifique dans le TG, et je me vois mal l’exécuter d’un « on verra bien un jour ». L’exercice demandé consistait à dresser un bilan des écarts, pas d’établir une feuille de route.

      Répondre
    • 28 avril 2011 à 9:41
      Permalien

      Oui en effet. C’est plutôt une bonne nouvelle.

      Répondre
  • Ping : Services de consultation INSPIRE et le WMS de l’OGC : Identiques et …différences

Laisser un commentaire

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