Il est tout à fait possible pour un service WFS d’informer ses applications clientes de l’existence de certaines contraintes sur les données qu’il publie. Cela passe par l’exploitation de l’opération DescribeFeatureType. Celle-ci décrit le modèle des données publiées. Par défaut, ce modèle est exprimé sous la forme d’un schéma XML. Si des listes de valeurs codées doivent être respectées, elles peuvent être définies dans le schéma. Voici un extrait d’un schéma décrivant les réseaux routiers d’INSPIRE :

 <simpleType name="FunctionalRoadClassValueType"> <annotation>[...]</annotation> <restriction base="string"> <enumeration value="mainRoad"> <annotation>[...]</annotation> </enumeration> <enumeration value="firstClass"> <annotation>[...]</annotation> </enumeration> [...] </restriction> </simpleType> 

Cet extrait indique essentiellement que le type FunctionalRoadClassValueType peut prendre l’une des valeurs suivantes : « mainRoad », « firstClass »… Bien sûr, d’autres types de restrictions peuvent être décrits dans les schémas XML (cf. ici).

Le schéma des données permet donc à l’application cliente de présenter un formulaire de saisie ou de recherche adapté à ce type de contrainte (une liste déroulante, une case à cocher ou des boutons radios). Encore faut-il que :

• le schéma publié par le service WFS reflète les contraintes définies au niveau de la base de données elle-même ;
• l’application cliente possède « l’intelligence » nécessaire à l’interprétation de ces contraintes.

En complément, on peut noter que :

• l’expression de contraintes sur les attributs peut également être exprimée à l’aide d’autres langages que les schémas XML. Les schémas JSON sont une alternative possible (cf. ici) ;
• les schémas n’ont pas été conçus pour transmettre aux applications clientes les traductions dans le langage naturel de l’utilisateur des valeurs codées utilisées par la base de données.

Notons, qu’une demande de modification (change request) a déjà été émise par Panagiotis A. Vretanos (éditeur de la standard WFS 2) en vue d’intégrer une interface REST à WFS. Cette demande est même très complète puisqu’elle comprend le projet de spécification. Par ailleurs, ESRI a déjà proposé que ses spécifications de GeoServices REST (que vous trouverez ici) soient promues au rang de standard de l’OGC.

Ce groupe de travail, avant même d’être officiellement formé, a déjà du pain sur la planche !

Pour ma part, je trouverais assez judicieux que Symbology Encoding s’inspire des capacités d’outils existants (Mapnik et GeoServer notamment). Cela tombe bien car OpenGeo (société ô combien impliquée dans le développement de GeoServer) a récemment fait une demande auprès de l’OGC pour que les adaptations à SLD présentes dans GeoServer soient intégrées à Symbology Encoding (cf. là). Les points les plus intéressants dans cette demande me semblent résider dans le paramétrage avancé du placement des textes (cf. ici) ainsi que dans les modificateurs des géométries (cf. là). Tout n’est pas bon à prendre dans GeoServer mais réduire les écarts entre les implémentations et les spécifications me parait être sage.

On peut d’ores et déjà noter que certaines des capacités de GeoServer sont en cours d’étude par le groupe de travail s’attelant à faire évoluer Symbology Encoding : remplissage de polygones par des hachures (cf. ici) et les « symboliseurs » dynamiques (cf. là) notamment.

Si vous cherchez une brique logicielle côté client pour communiquer avec un serveur CSW et si vous aimez Python, vous pouvez essayer OWSLib (cf. ici).

Exemple de GeoSMS (tiré d’une des pages citées précédemment) :
I’ll be at the pub geo:-37.801631,144.980294;u=10 until midnight, then heading to a gig geo:-37.864225,144.97294.
Ce standard prend en compte l’incertitude de géolocalisation (paramètre u) et peut utiliser d’autres systèmes de coordonnées que WGS84.

L’Open GeoSMS standard de l’OGC est actuellement soumis aux commentaires publics . Exemple d’Open GeoSMS :
http://maps.geosms.cc/showmap?geo=23.9572,120.6860&GeoSMS
I NEED TOWING SERVICE NOW
On notera que l’Open GeoSMS requiert la présence d’une URI (http ou https) en première ligne du message. On peut également noter que l’auteur de GeoSMS n’aime pas cela (cf. ici).

Évidemment, aucun de ces deux standards ne semble faire référence à l’autre. Je n’ai pas trouvé d’information permettant de savoir si une collaboration entre leurs auteurs a été recherchée. L’une des principales applications du Open GeoSMS standard, identifiée par ses auteurs, serait de permettre aux personnes ayant besoin d’aide d’envoyer leur position aux services de secours grâce à leur téléphone portable. Malheureusement, j’ai peur que la redondance des standards ne serve pas l’interopérabilité, ni le secours aux personnes.

Ces deux standards sont très courts. Personnellement, je préfère GeoSMS (pour sa concision et sa souplesse) à l’Open GeoSMS. Il faut toutefois noter que l’OGC a émis l’idée de proposer son Open GeoSMS à l’OASIS en vue de compléter le standard CAP (Common Alerting Protocol).

Dans ce document de plus de 200 pages, ESRI nous présente une variété intéressante de services web :

• Map Services : il s’agit à la fois d’un équivalent de WMS et TMS avec des capacités complémentaires pour exécuter des requêtes sur les objets composant les couches de données diffusées. Ce type de service peut à la fois produire une carte dont l’emprise et le contenu sont libres et des tuiles dont le découpage est pré-établi ;
• GeoProcessing Services : services dont l’interface est calquée sur les capacités des GeoProcessing d’ArcGIS. Ces traitements peuvent être exécutés de manière synchrone ou asynchrone ;
• Geometry Services : services destinés à réaliser des opérations sur des géométries. Ils peuvent être vus comme des GeoProcessing Services avec des capacités restreintes (les spécifications présentent ce type de service de cette manière) : une vingtaine d’opérations telles que la reprojection, la simplification, la généralisation, le calcul de l’enveloppe convexe sont disponibles ;
• Image Services : services publiant une image ou une mosaïque d’images avec des capacités calquées sur les fonctions de rendu et d’export des données raster d’ArcGIS Desktop. Par exemple : sélection des canaux, identification de la couleur de padding, choix de la méthode d’interpolation, méthode de rendu des canaux. Typiquement, ce type de service peut produire une image d’un MNT combinant ombrage et couleurs hypsométriques ;
• Feature Services : services se rapprochant de WFS-T ou du FeatureServer de Christopher Schmidt par leur aptitude à manipuler (sélection, création, modification et suppression) les objets d’une couche ;
• Geocode Services : services de géocodage et géocodage inverse.

Force est de constater que les démarches de l’OGC et de l’ISO ne sont pas les seules possibles pour élaborer des standards. Il est également intéressant de noter que des spécifications de services web peuvent être concises.

Ce document montre également que les principes de REST peuvent être appliqués à un grand nombre de services web géospatiaux (j’entends régulièrement que l’information géographique ne serait pas adaptée à REST et réciproquement).

Il est trop tôt pour savoir si ces spécifications seront implémentées par d’autres acteurs. Personnellement, je trouverais dommage que ce ne soit pas le cas, même si je ne me fais guère d’illusions. Elles devraient au moins alimenter les réflexions de l’OGC sur REST.

La première chose qui m’a frappée est le fait que cette nouvelle version soit publique sans qu’elle ne soit formellement approuvée par l’ISO. Elle est néanmoins le résultat du travail conjoint de l’OGC et de l’ISO (WFS s’appelle aussi ISO 19142). Inversement de nombreuses mentions sont faites à Filter Encoding 2.0 (ISO 19143). Celui-ci a été publié très récemment par l’ISO mais pas encore par l’OGC alors qu’il est également le fruit du travail conjoint des deux organismes. Une autre étrangeté réside dans la version de OWS Common sur laquelle repose WFS 2.0 : OWS Common 1.1 qui a été récemment remplacé par OWS Common 2.0.

WFS n’a pas subi de modifications de fond en comble. Le standard repose toujours sur les mêmes principes de base :

• L’interface d’un service WFS (Web Feature Service) permet à une application ou un autre service de récupérer des données vectorielles sous forme de documents GML. La sélection des données retournées au client est alors réalisée via un langage de requête décrit dans les spécifications de Filter Encoding. WFS permet également à un client de modifier le contenu du jeu de données diffusé via WFS. On parle alors de WFS-T (Transactional WFS) pour désigner les services autorisant ce genre d’opération.
• Par défaut, la description des entités géographiques manipulées au travers d’un service WFS est toujours GML. La version de GML utilisée par défaut passe de 3.1.1 à 3.2.1 (de futures versions de GML ainsi que d’autres formats peuvent néanmoins être utilisés).

Globalement WFS 2.0 dispose de capacités de requêtes plus complètes que son prédécesseur. En effet, elle offre un meilleur support de XPath, des capacités de requêtes spatiales et attributaires étendues avec Filter Encoding 2.0 (versionnement des entités géographiques, jointures attributaires, spatiales et temporelles notamment), la pagination des résultats (enfin !) et la gestion de requêtes stockées (l’une des principales nouveautés).

Du côté des transactions, on note l’arrivée d’une nouvelle action « Replace » qui s’ajoute aux opérations « Insert », Update » et « Delete ».

D’autres améliorations intéresseront ceux qui sont concernés par la mise en œuvre de services WFS pour INSPIRE :

• l’extensibilité des métadonnées associées à chaque FeatureType : un nouvel élément « ExtendedDescription » fait son apparition dans les capabilities du service. Cela permet d’insérer des métadonnées non proposées en standard par les spécifications sans changer le schéma XML ;
• le multi-linguisme : plusieurs Title et Abstract peuvent maintenant être associés aux FeatureTypes publiés par les services WFS.

On peut également noter la disparition de certaines notions :

• l’opération GetGmlObject qui permettait d’accéder à une propriété d’une entité géographique n’existe plus. Elle a été remplacée par l’opération GetPropertyValue ;
• les considérations liées à l’authentification et à la gestion des droits des utilisateurs ont été retirées du standard : le chapitre sur HTTPS a été supprimé et il est indiqué explicitement que ces considérations sont en-dehors du périmètre de ce standard. Cela n’est pas très étonnant. Le sujet de la sécurité des services web n’avance pas énormément du côté de l’OGC. En attendant que cela soit plus clair la porte est laissée ouverte aux différentes solutions qui peuvent être utiles dans ce domaine.

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.

Lors des dernières réunions du comité technique de l’OGC, les travaux sur les données 3D ont été l’occasion de voir une présentation sur la consultation des données OpenStreetMap en 3D. Vous trouverez les informations sur ce projet ici : OSM-3D Germany.

Il est intéressant de noter, au passage, à quel point la communauté germanique est impliquée dans ces travaux.