MapServer REST API

Après plusieurs jours d’un travail intensif, nous avons le plaisir d’annoncer la publication d’une API Restful pour MapServer sur GitHub. L’occasion pour moi de revenir un peu sur le contenu de cette API, qui sera présentée le 11 juin 2013 à l’occasion du FROG2013 à Saint-Mandé et en septembre au FOSS4G à Nottingham.

L’idée de cette API est initialement venue d’un besoin fonctionnel lié à GeoNetwork. Le projet GeOrchestra ayant permis d’y développer un module de publication de données et de services dans GeoServer, le besoin de pouvoir faire de même en direction de MapServer s’est rapidement présenté dans le cadre de nos projets. Dans un premier temps c’est donc sur un périmètre assez restreints de commandes et d’instructions qu’un premier noyau a été mis en œuvre. Mais depuis 2 mois, nous avons entièrement recodé le composant qui couvre désormais le même périmètre fonctionnel que l’API Rest de GeoServer. Pourquoi avoir choisi de coller au plus près de celle-ci plutôt que de développer une API plus proche des spécificités de MapServer ? Pour des raisons d’inter-opérabilité. Il nous semble nécessaire, maintenant qu’au niveau des services le WMS assure une bonne inter-opérabilité entre les différents serveurs cartographiques, de pouvoir mettre en place une inter-opérabilité côté administration des services, ce que le WMS ne permet pas. Répliquer les instructions de l’API Rest de GeoServer en direction de MapServer nous semblait donc être un bon premier pas.

La chose n’a pourtant pas été simple tant les deux produits sont différents au niveau de la modélisation des cartes, couches et styles. MapServer a un modèle très hiérarchique et linéaire : le MAP, doté de LAYERS, eux-même avec des CLASSES qui ont des STYLES. GeoServer par contre a des workspaces, des dataStores, des coverageStores, des featureTypes et ne connaît pas le concept de carte ! Essayer d’établir des équivalence (workspace -> mapfile, dataStore -> CONNECTION…) a donc été la première des tâches, et sans doute celle qui nous a pris le plus de temps à mettre au point. Les choix sont peut-être parfois discutables, mais chacun a été longuement pesé, et l’inter-opérabilité oblige à quelques compromis.

Que permet donc de faire cette MapServer REST API ? Tout simplement de manipuler des fichiers .map avec des URLs et des verbes HTTP (GET, POST, PUT, DELETE). Ainsi pour déclarer un dataStore (une connexion à un entrepôt de données), il faut faire une requête POST à l’URL http://servername/mra/maps/nom_du_map/workspaces/default/datastores avec le contenu suivant :

<dataStore> <name>my_datastore</name> <connectionParameters> <host>xxx.xxx.xxx.xxx</host> <port>5432</port> <database>ma_base</database> <user>moi</user> <password>mon_password</password> <dbtype>postgis</dbtype> </connectionParameters> </dataStore>

Votre dataStore existera alors sous le nom « my_datastore », sera accessible via un GET sur l’URL http://servername/mra/maps/nom_du_map/workspaces/default/datastores/my_datastore.xml et supprime via un DELETE sur la même URL.
Vous en conviendrez, ce n’est pas du plus pratique à utiliser, et il faut bien considérer cette API comme l’élément d’une architecture machine-to-machine plutôt qu’une application pour l’utilisateur final. Néanmoins, pour faciliter la consultation du contenu et de la structure du fichier .map, nous avons particulièrement travaillé le rendu en HTML, généralement parent pauvre de ce type d’outils plutôt destiné à communiquer en XML ou en JSON.

Contenu d'un fichier .map

Côté doc, il faut évidemment se référer pour les instructions HTTP à la doc de l’API GeoServer, ce qui est plutôt cool car on n’a pas eu à faire de doc (!), et cette contrainte nous oblige à l’iso-fonctionnalité des deux API. Sur le GitHub, vous trouverez néanmoins la doc d’installation et le guide de référence contenant les opérations implémentées. La principale difficulté d’utilisation n’est pas vraiment technique, mais plutôt conceptuelle. Pour ajouter une couche à un fichier .map, il faut passer par des étapes intermédiaires qui sont relativement fastidieuses :

  1. Créer un dataStore (le truc qui désigne votre BD ou le Shapefile ou le TIF…)
  2. Créer un FeatureType à partir du dataStore (désigne la table de la BD, ou toujours le ShapeFile, sic…)
  3. Créer un Layer avec ce FeatureType. Il prendra un style par défaut.
  4. Pousser un SLD pour personnaliser le Layer.

Une certaine maîtrise du modèle conceptuel n’est donc pas inutile, mais la publication HTML donne de bonnes pistes pour cela. Sinon il faudra attendre un petit guide en cours d’élaboration dans nos bureaux.

Techniquement, l’API a été bâtie en python, autour du petit framework web.py qui a la particularité de bien implémenter les principes REST. Une belle dépendance à MapScript évidemment, sans qui rien ne serait possible, une autre à GDAL/OGR pour l’introspection des Shapefile et des rasters (ça fait ça aussi…), du PyYaml pour gérer la conf et normalement c’est tout. Fonctionne sans piles en WSGI sous Apache.

Dans cette première version, parfaitement fonctionnelle, nous avons donc le noyau dur du périmètre de recouvrement avec l’API GeoServer. Alors, la suite ? Sans doute d’ajouter des instructions utiles à la manipulation d’éléments propres à un mapfile (les METADATA par ex., les options de publication WMS/WFS aussi, qui sont actuellement chargées depuis un template unique). Mais ne nous y trompons quand-même pas. Cette API n’a pas vocation à devenir un outil d’administration complet de fichiers map, mais bien plutôt une passerelle entre les deux serveurs cartographiques OpenSource les plus utilisés. Donc la prochaine étape sera sans doute orientée utilisateur, avec, qui sait, un plugin QGis permettant de charger/récupérer une configuration MapServer ou GeoServer. Et peut-être accomplir un rêve un peu fou : transcrire automatiquement une configuration MapServer vers GeoServer et vice-versa…

2 commentaires :

  1. Publié le 1 juin 2013, 2:44 par Landry Breuil

    Juste un mot : MERCI de libérer ce code. Il sera d’une grande aide a ceux qui jonglent entre GeoServer & MapServer en fonction des données & besoins d’optimisations. Ca remonte clairement MapServer au niveau de GS pour la facilité d’administration, il y’avait un grand écart..

Publier un nouveau commentaire