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.

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.

Car c’est bien en termes d’interropérabilité que les formats se distinguent. Là où les premiers ont été faits pour permettre à des systèmes géographiques d’interropérer (afficher dans MapInfo une carte issue d’un serveur WMS, crééer un application web à partir de multiples serveurs WMS-WFS différents), le deuxième groupe est fait pour permettre à des applications web d’interropérer, nonobstant leur capacité à analyser ou traiter la donnée géographique. Ce point est central pour la compréhension des avantages et inconvénients de chacuns. Là où un flux AtomPub intégrant des balises de géolocalisation en GeoRSS pourra être interprété par n’importe quel client Atom, qu’il exploite les données géographiques ou pas, le flux GML d’un serveur WFS ne sera correctement affiché sous forme de carte que par des clients dédiés à l’affichage cartographique. Cependant, pour des raisons d’homogénéité et de standardisation, l’AtomPub, tout comme le KML, ne diffuse qu’un contenu attributaire restreint (nom – description de l’objet, même si celle-ci peut-être complexe, de la forme d’un bloc HTML complet), tandis que le GML transporte toute la richesse attributaire nécessaire à une réelle exploitation des données. Les usages sont donc forcément différents. Là où le GeoRSS répond au besoin de « Affiche mes posts dans GoogleMaps », le GML est porteur d’une réelle richesse attributaire et d’une plus value qualitative évidente, qui se paye par une plus grande complexité.

Via import cartography.

Le KML (Keyhole Markup Language, et sa version Z pour la gestion de la 3D version zippée) est utilisé par Google, notamment dans GoogleEarth (c’est KeyHole qui l’a créé, mais c’est Google qui l’a racheté).

Le GeoJSON est à destination des programmeurs. Il s’agit d’un moyen de transférer facilement des « objets » d’un language de script vers le javascript (d’où le nom : Javascript Simple Object Notation), tel quel, avec attributs et propriétés. On le croise moins souvent, c’est vrai, mais c’est parce qu’il se cache.

Les deux derniers sont presques des microformats, issus de la volonté de donner autant de souplesse à l’information géographique qu’à l’information tout court, au travers de la syndication de contenu.

Bon, mais on en fait quoi exactement ? Pour la plupart, ils ne sont que des formats d’échange, les MIF/MID du web en quelque sorte. Seul le KML se distingue par son utilisation native dans GoogleEarth. On peut presque en dire autant du GML, que QGis ou Jump sont capable d’afficher directement. Mais malgré ce, ces formats n’ont pas encore pris la place de « standard » que peut avoir le shapefile d’Esri par exemple. Donc on regarde des KML, on affiche des GML, mais quand-même, on travaille avec des formats classiques du SIG bureautique.

Pourtant ces formats ont d’autres atouts que les fichiers binaires habituels. Pour peu qu’une architecture web adaptée leur soit associée, ils peuvent permettre d’accéder à la donnée géographique d’une manière beaucoup plus souple. Prenons un exemple. Vous avez besoin des contours des départements de la Bretagne. Avec une approche SIG classique, vous ouvrez votre Geofla® avec votre logiciel SIG préféré, faites votre sélection, et réexportez le résultat dans une couche toute neuve (lisez quand-même les conditions d’utilisation du GeoFla® avant ) Pour peu qu’il vous faille ainsi des extrations sur toutes les régions françaises, vous êtes bon pour prendre un stagiaire.

Un service web bien conçu peut faciliter les choses. Imaginez une architecture REST (Representational State transfert, ça fait un peu peur dit comme ça. Voir « Comment j’ai expliqué REST à ma femme » pour en savoir plus, ou l’excellent blog de David Larlet BioloGeek). Elle permet d’accéder à une liste des départements en appelant l’URL http://www.ign-online.fr/france/departements/. La page contient la liste des départements, ainsi que des liens permettant d’accéder à d’autres « représentations » de ceux-ci, en GML par exemple (la notion de ressource et de représentation est fondamentale dans une architecture REST. Ici les départements sont des ressources, proposées sous diverses représentations, textuelle ou géographique).

On a donc :

01 AIN Bourg-en-Bresse
02 AISNE Laon
.
.
.
voir les données en GML, KML, GeoAtom

en cliquant sur GML, on appelle en fait l’URL http://www.ign-online.fr/france/departements/GML/
Mais jusqu’ici rien de bien bouleversant. On récupère un fichier, on l’enregistre, on l’ouvre avec uDig, et on rappelle le stagiaire. Seulement l’application web susdite à d’autres tours dans son sac. A l’URL http://www.ign-online.fr/france/regions/53/departements correspond la liste des départements de la région dont le code INSEE est le 53, soit la Bretagne. Et http://www.ign-online.fr/france/regions/53/departements/GML renvoie directement un flux GML correspondant aux seuls départements bretons.
Ainsi à partir d’une seule couche de données (qui peut être au format shape, TAB, postgis, le tout étant que le langage dans lequel les services web sont écrits permette de les lire. En optant pour Python associé à GDAL on ouvre déjà d’intéressantes perspectives), on démultiplie les usages possibles par la construction de services web spécifiques. Ceux-ci sont faciles à construire, et peuvent même automatiquement exploiter les champs de chaque couche selon un principe clé/valeur (http://www.ign-online.fr/france/regions/53/departements/GML/?dept=finistere renvoyant le contour du seul Finistère). Pour peu que de bonnes métadonnées accompagnent la description de la couche, chacun peut alors bâtir sa propre requête en composant une URL.

Appelée depuis un logiciel SIG bureautique, cette URL devient une ressource géographique, au même titre qu’un fichier shape. Sans compter que des manipulations spatiales sont également implémentables en web services. Les zones inondables à Toulouse ? Facile : http://www.spatialservices.net/intersection/?url1=http://www.prim.net/cartorisque/AZI/&url2=http://www.ign-online.fr/france/communes/31555/ ! Que va faire ce web service ? d’abord récupérer chacune des URLs, puis les charger dans PostGIS par exemple, réaliser l’intersection, et renvoyer ce seul résultat. Qui sera accessible en GML, KML ou autre.

La multitude de formats n’est donc pas un frein au développement de webservices cartographiques réellement utiles. Ils ne sont que des moyens de représenter la même chose. La diffusion de la donnée doit se faire sans a priori sur l’utilisation qui en sera faite (alors que si je mets un shape à disposition, j’impose à l’utilisateur un logiciel particulier, ou la conversion du fichier avant exploitation).

La technologie existe. Manquent seulement des données de référence, un peu de temps, et beaucoup d’idées. C’est celui qui dit qui y est ? Bon, dans quelques temps, vous trouverez sur neogeo-online.net une première ébauche de ces quelques réflexions…

P.S. : le tendance actuelle est quand même au regroupement de ces formats. La participation de Google à l’OGC devrait faire du KML un nouveau standard de fait, laissant au GML les contenus très complèxes, non gérés par le KML. Dans le même temps, Atom semble s’imposer sur le RSS et ses multiples spécifications.

P.S.S. : Peu de liens dans cet article. En fait, je commence à me demander si ces articles où on trouve presque un lien par mot sont vraiment lisibles… Donc pour faire plus clair, voici juste quelques références :

http://zcologia.com/news/

http://blog.mapufacture.com/

http://cfis.savagexi.com

http://cholmes.wordpress.com/