Comme souvent la notion d’éclaircissement s’accompagne d’une dose d’obscurcissement, voici un petit résumé de ce que j’ai pu en comprendre…

1. Comment tester ?
   Sans doute pour répondre aux divers besoins exprimés, le document prévoit 2 scénarii de test : soit on teste le service depuis son point d’accès sur internet, soit on le teste depuis l’intérieur de l’infrastructure informatique. Dans ce dernier cas, il faut retrancher le temps de transport réseau pour mesurer la performance. Il s’agit en fait d’établir la différence de temps de transfert entre ce mode et le mode précédent, et de l’appliquer aux résultat obtenus ainsi. C’est une sorte d’extrapolation des résultats qu’on aurait obtenus en testant depuis l’extérieur faite à partir de résultats obtenus depuis l’intérieur de l’infrastructure. Bon, pour la suite, on partira du principe qu’on suit le scénario 1…
2. Mesure de la performance.
   Il faut pouvoir récupérer une image de 470 Ko (800×600 pixels en 8 bits) en moins de 5 secondes, en situation normale. Mais il ne suffit pas que ça marche une fois. Le protocole de mesure indique qu’il faut effectuer plusieurs tests par heure (au moins 10), en n’interrogeant qu’une couche à la fois, mais en faisant varier la bbox pour éviter les effets d’une mise en cache éventuelle. Au final, 90% des mesures doivent être inférieures à ces 5 secondes (c’est la notion de situation normale).  Le chronométrage doit correspondre au premier bit reçu par le client, et non à la réception de l’ensemble de la réponse.
3. Mesure de charge
   Le nombre minimum de requêtes servies doit être de 20 par seconde.  Cette mesure doit être effectuée pendant 1 minute, en envoyant 20 requêtes simultanées par seconde (ce qui associé à l’exigence précédente suppose une bande passante d’au moins 75 Mbps). Pour éviter les biais, il est préférable de réaliser ce test en ayant désactivé l’accès public au service. Concrètement, un test avant la mise en production semble idéal, puis régulièrement (mensuellement selon la recommandation). Dans les 20 requêtes minimum envoyées par seconde, il faut prévoir 10 % de GetCapabilities et 90 % de GetMap (faits selon les exigences de performance vues précédemment).
4. Disponibilité.
   Le service doit être disponible (mais sans forcément atteindre les exigences précédente) 99 % du temps, soit 3,63 jours d’indisponibilité par an au maximum.  Il faut faire au minimum 10 requêtes par heure, qui peuvent être les mêmes que celles utilisées pour mesurer la performance. Néanmoins, les périodes de maintenance ne rentrent pas en compte dans cette mesure, pour peu qu’elles aient été signalées aux utilisateurs (via les portails ou une notification par mail) une semaine à l’avance.

En résumé, si l’on met de côté la mesure de charge qui est particulière, il faut mettre en place un système qui envoie des GetMap sur un layer, en 800×600 avec bbox variable (mais valide, c’est-à-dire incluse dans la bbox du layer tel qu’exposée par le GetCapabilities) plus de 10 fois par heure. Au moins 99 % de ces requêtes doivent aboutir à un résultat (HTTP 200 et image non vide), et le premier bit de ce résultat doit être obtenu en moins de 5s dans au moins 90% des cas. Vous remarquerez néanmoins sans doute un paradoxe : les ViewServices peuvent utiliser du WMS ou du WMTS, mais les indicateurs de QoS ne prévoient pas de mesure particulière sur du GetTile, équivalent en WMTS du GetMap. Si votre service de visualisation WMS ne répond pas aux exigences de qualité de service, vous n’avez donc plus qu’à le basculer en WMTS !

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.

En effet, les modèles UML des spécifications sur les données INSPIRE utilisent le format GML pour encapsuler les géométries. Ces modèles sont égalements appelés schémas d’application GML. L’ensemble des propriétés et relations entre les objets y est décrit.

Dans le cas d’une adresse, le modèle est le suivant :

TOS permet de lire et d’extraire des portions de fichier XML avec le composant tFileInputXML. Avec un peu de configuration (cf. ci-dessous), il est possible de définir une correspondance entre tout ou partie du fichier XML et un flux de sortie.

Dans ce cas, la position (« ad:position ») n’est pas transformée en géométrie, elle est de type texte. En sélectionnant l’option « Get Nodes » pour cette colonne, le composant va extraire le bloc XML. Ce bloc doit alors être converti en géométrie. Il est possible d’ajouter une routine pour réaliser cette conversion. Le menu « créer une routine » est accessible depuis l’onglet Référentiel > Code > Routines :

public class GeometryUtility {
    private static final org.geotools.xml.Parser gmlParser = new org.geotools.xml.Parser(new org.geotools.gml3.GMLConfiguration());
    /**
     * GMLToGeometry: Convert a GML string into a Geometry
     *
     * {talendTypes} Geometry
     * {Category} GeometryUtility
     * {param} string("...") input: The GML to be parsed
     * {param} boolean(false) input: Validate the GML input document or not
     * {example} GMLToGeometry(row1.the_geom, false)
     */
    public static org.talend.sdi.geometry.Geometry GMLToGeometry(String gml, boolean validate) {
    	// Set GML parser properties.
    	gmlParser.setStrict(false);
    	gmlParser.setValidating(validate);

        // TODO : Take care of coordinate system

    	// Parse the geometry
	try {
		Object value = gmlParser.parse(new java.io.StringReader(gml));
		return new org.talend.sdi.geometry.Geometry((com.vividsolutions.jts.geom.Geometry) value);
	} catch (Exception e) {
		System.out.println("Error when parsing GML geometry: " + e.getMessage() + ".");
		e.printStackTrace();
	}
    	return null;
    }
}

Une fois la routine créée, il est alors possible de l’utiliser dans toute expression :

routines.GeometryUtility.GMLToGeometry(row2.Point, false)

Par exemple dans un composant tMap :

Ainsi, la conversion d’un fichier GML vers un fichier Shapefile peut se faire de la manière suivante :

Quand l’heure sera venue de traiter des données au format INSPIRE, il y aura probablement de nombreux cas particuliers à gérer mais c’est déjà un premier pas. Le cas de l’écriture de ces formats est également une problématique intéressante.

En effet, la directive INSPIRE se décline dans la pratique en 3 types de guides :

• Les règles d’implémentations,
• Les guides techniques,
• Les spécifications sur les données

Côté catalogue, les principaux guides à appliquer sont :

• Les règles d’implémentation sur les métadonnées,
• Le guide technique sur les services de découverte (version 2.12 non finalisée)
• Les spécifications sur les données dont un chapitre présente les compléments à apporter en plus des règles d’implémentation. En général, ces compléments portent sur les éléments de qualité.

Ce document (en anglais) présente pour chacun de ces guides l’état actuel dans GeoNetwork. Il donne quelques explications sur les mécanismes internes de GeoNetwork relatif à INSPIRE et au CSW. Le dernier chapitre présente comment configurer un nœud GeoNetwork afin d’activer l’ensemble des fonctions INSPIRE du catalogue (on notera que GéoSource est pré-configuré avec la majorité de ces options). De plus, nous en avons profité pour apporter à GeoNetwork quelques corrections et améliorations afin d’avoir des rapports de validation plus proches entre l’outil de validation du JRC et les résultats dans GeoNetwork.

Tout ceci est dès à présent disponible dans GéoSource 2.3.3-1, GeoNetwork 2.6.3 et le trunk de GeoNetwork.

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.

Quelques points qui ont éveillé mon intérêt :

• le Forum Français de l’OGC (avec l’aide de l’AFIGEO) a commencé un travail de rédaction de fiches en français sur les standards de l’OGC afin de démystifier la chose. La première fiche, consacrée à WMS, a été produite et est disponible ici ;
• des clefs USB du projet GIGAS étaient disponibles en libre-service. Elles contiennent l’ensemble des résultats de ce projet Européen visant à émettre des recommandations quant à l’emploi des standards de l’information géographique. Ces recommandations sont basées sur l’analyse des standards, exigences et retours d’expérience de différents projets (dont INSPIRE, GMES et GEOSS). Très intéressant même si la quantité d’information est importante (et en anglais) ;
• une vidéo réalisée par une dizaine d’éditeurs de services et clients WMS membres du Forum français de l’OGC montrant le niveau d’interopérabilité que l’on peut atteindre à l’aide de leurs outils favoris (des produits libres faisaient également partie de la démonstration). Chaque éditeur disposait de 5 minutes pour démontrer le niveau d’interopérabilité de sa solution (en exploitant à la fois les couches de données qu’il publiait et celles publiées par les autres éditeurs). Cette vidéo est intéressante : elle brosse un rapide paysage des solutions disponibles sur le marché français tout en introduisant de manière concrète les travaux de l’OGC. C’est le premier exercice de ce genre mené par le Forum français. Gageons que l’exercice se poursuivra l’année prochaine avec des ambitions encore plus élevées ;
• une présentation des Technical Guidances des View Services d’INSPIRE faite par Didier Richard de l’IGN : l’idée générale était de présenter les recommandations d’implémentation des services de visualisation d’INSPIRE (dans le cas d’une mise en œuvre sur la base de services WMS 1.3.0) et de souligner les différences entre les spécifications de l’OGC et les recommandations d’INSPIRE.