> Mettre à disposition ses fichiers de données

GéoSource et GeoNetwork ont toujours permis de téléverser des fichiers de données dans le but de les rendre téléchargeables à partir des fiches de métadonnées. Pour cela, il faut :

• aller dans la section distribution,
• ajouter un élément ressource en ligne et
• sélectionner le protocole fichier à télécharger.

Le catalogue propose alors à l’éditeur un outil d’upload de fichier. Le fichier peut être un rapport, une étude, des images, ou des données géographiques. Les données sont alors accessibles dans la fiche :

> Publier des données via un service de visualisation et téléchargement (WMS, WFS)

Le catalogue est en mesure de « pousser » la donnée dans un serveur cartographique. En l’occurrence, GeoNetwork est capable de déployer une donnée dans GeoServer. L’idée est de simplifier le processus de publication des données sans avoir recours à une interface d’administration ou un fichier de configuration parfois complexe.

Les formats actuellement supportés sont :

• GeoTiff
• ESRI Shapefile
• Table PostGIS

Une fois les fichiers (ou les références aux tables) associés à une fiche, la publication dans le service cartographique est faite via l’interface suivante en quelques clics :

L’assistant ajoute les liens au service WMS et à la couche automatiquement à la fiche de métadonnée.

Si l’extension SLD Editor de GeoServer est installée, il vous sera également possible de définir le style des couches à partir du catalogue.

Pour activer l’outil de publication, il suffit de décommenter la ligne suivante dans le fichier WEB-INF/config-gui.xml :

<editor-geopublisher/>


Par défaut, la configuration utilise le composant GeoServer installé avec le catalogue, mais il est possible d’ajouter d’autres instances (eg. en test, en intranet, en internet) via le fichier de configuration WEB-INF/config-geoserverpublisher.xml.

> Gérer les privilèges d’accès et informer sur les contraintes d’accès

Dans la gestion des privilèges, il est alors possible d’autoriser ou pas le téléchargement ou la visualisation de ces données à un ou plusieurs groupes, voire au public.

Pour les fichiers, ils sont sous le contrôle du catalogue qui en gère les accès avec le privilège « télécharger ». Le privilège « carte interactive » indique au catalogue s’il doit présenter les informations concernant les liens WMS aux utilisateurs (ie. liens vers le WMS, boutons « ajouter à la carte »), il s’occupe de supprimer ces informations en fonction du profil de l’utilisateur. Quoiqu’il en soit, un utilisateur récupérant l’adresse du WMS par un autre moyen aura accès à l’information, celle-ci étant sous le contrôle du serveur WMS (il faudrait ici des processus de synchronisation des droits d’accès gérés par le catalogue et ceux du WMS).

Pour le téléchargement des données, le catalogue propose un assistant qui permet :

1. la sélection de tout ou partie des données uploadées
2. la présentation des contraintes légales et restrictions à l’utilisateur renseignées dans les métadonnées
3. le remplissage d’un formulaire d’identification
   
4. et enfin l’accès au téléchargement d’une archive contenant les métadonnées, les données demandées ainsi qu’un exemple de licence (rappelant la liste des fichiers, le titre de la donnée, les contraintes et l’utilisateur)

L’aspect génération de licence sera sans doute un point à améliorer mais permet d’ores et déjà d’utiliser le contenu des métadonnées pour générer un document de suivi de la donnée.

> Consulter le tout

L’intégration entre les métadonnées, les données et les services de visualisation est réalisée par l’interaction entre les résultats d’une recherche dans le catalogue et la visualisation cartographique des données.

Pour cela, GeoNetwork propose un module de cartographie interactive permettant d’afficher les couches référencées dans les métadonnées de données et d’ajouter des couches depuis un service référencé dans le catalogue. Ce module est désactivé dans la nouvelle interface utilisée par GéoSource.

Il présente les fonctionnalités standards d’une visionneuse cartographique :

• Navigation
• Gestion (ordre, transparence, …) et interrogation des couches
• Légende
• Impression PDF

Pour activer ce module dans GéoSource, dans le répertoire web/geosource/apps/search, modifiez les fichiers index.html et index_debug.html en supprimant :

<link rel="stylesheet" type="text/css" href="../css/hidemap.css"/>


Dans le fichier js/Settings.js et js/App-mini.js (version compressée) remplacez

GeoNetwork.MapModule = false;
par
GeoNetwork.MapModule = true;


Le module de cartographie interactive est maintenant disponible, il est alors possible de basculer de la perspective découverte à celle de visualisation. Notez également que la carte par défaut utilise les données OSM et donc que la projection est Mercator. Les services WMS utilisés doivent donc supporter cette projection.

> Interagir avec les sites existants

Concernant l’intégration avec des sites institutionnels ou un CMS, il est fréquent d’utiliser les modules RSS ou iFrame pour associer les informations du catalogue avec les pages du CMS. Le flux RSS disponible sur la page d’accueil du catalogue retourne les derniers ajouts. Il est également intéressant de savoir qu’il est possible de faire des recherches via RSS, ainsi il possible d’associer à un article sur un thème ou un territoire les résultats du catalogue correspondant. Par exemple, « http://localhost:8080/geosource/srv/fr/rss.search?any=savoie » retournera les informations sur la Savoie.

Voici donc un aperçu des fonctionnalités avancées disponibles dans GeoNetwork pouvant aider à mieux intégrer le catalogue au sein de votre SI géographique.

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/