Développement d'une application de webmapping MapServer/PostGIS

II - MISE EN OEUVRE ET RENDU

1- Organisation de travail

Pour la réalisation du projet, j'ai disposé d'une totale liberté d'organisation et d'une large marge de manoeuvre dans le choix de la solution, les éléments de cadrage étant définis en amont, dans le cahier des charges.

Après la phase assez rapide de diagnostic portant sur le matériel et les données, j'ai dû travailler en tant que prestataire externe. En effet, aucun poste adapté n'était disponible et aucune compétence en géomatique et développement orienté web (notamment php) susceptible de m'aider n'existaient en interne. Comme il a été dit, cette mission était encadrée par le responsable informatique de la Mairie, M. Chazot, lequel a aussi des responsabilité au sein du service financier. Pour la Mairie, il ne s'agissait donc pas de coordonner cette mission avec le travail d'un service ou d'un agent en particulier, mais de produire un outil conforme aux attentes en termes de fonctionnalités et aux prescriptions techniques détaillées dans le cahier des charges. De mon côté, ma démarche avait une forte dimension technique et ne consistait donc pas à me sensibiliser à des logiques procédurales en dehors de celles existant entre commanditaire et prestataire de service.

Connaissant déjà le monde de l'entreprise, cette organisation devait me permettre de m'adapter à une autre façon de travailler caractérisée par une plus grande responsabilisation.

Entre la phase d'inventaire (matériel et données) et celle du déploiement du serveur sur site, l'essentiel de la mission a donc consisté en un travail de développement en local sur mon poste personnel.

Au final, on verra que la comparaison entre le planning tel qu'il a été établi de façon prévisionnelle (Fig. 5.) et celui observé au terme de la mission (Fig. 14.) montre quelques décalages.

A ce stade, mon approche de ce travail était en effet linéaire alors que ses phases de réalisation se sont révélées être peu cloisonnées dans les faits. Il a notamment fallu procéder à plusieurs compilations de différentes distributions et à différents moments de la réalisation du projet.

Finalement, l'entrée en matière et le choix définitif de la solution ont pris plus de temps que prévu, ce dernier point s'est en outre fait en parallèle de l'élaboration de l'interface web notamment (voir II. 3.).

Cependant, les délais définis dans le planning prévisionnel ont été globalement tenus.

2- Choix de la solution

2.1. Technologies libres disponibles

Il existe actuellement quatre principales solutions techniques libres permettant de publier en ligne des données cartographiques. Le choix entre celles-ci est facilité par leurs limites respectives ainsi que par la lourdeur de leur déploiement qui permettent de circonscrire chacune à un type d'usage et de finalité particulier (Fig. 6.).

a. HTML simple (carte statique)

Il s'agit de la solution la plus légère et la plus facilement mise en place. Elle consiste à insérer une simple image (.jpg, .png, .gif, .bmp) dans une page HTML classique.

Le HTML ne permet cependant que de définir des zones cliquables pointant vers une autre page (fonctionnalité utilisable par exemple pour proposer à la navigation un zoom sur zone prédéfinie) ou associées à un événement javascript permettant par exemple l'affichage de données attributaires au passage de la souris.

Cette solution ne gère pas les sources vectorielles ni la projection et demeure très limitée en termes d'outil de navigation. Elle ne permet pas non plus l'intégration d'outil d'analyse et de recherche attributaire ou spatiale.

b. Solution SVG (Scalable Vector Graphics)

Il s'agit d'un format image vectoriel ouvert (basé sur la norme XML) permettant un encodage et un affichage sans perte de qualité de formes géométriques.

Les données peuvent être stockées comme table (.tab ou .shp par exemple) avant d'être encodées en SVG et envoyées au poste client. Elles sont alors chargées dans la mémoire cache du navigateur pour pouvoir être visualisées par l'utilisateur, ce qui permet une grande fluidité dans la navigation mais peut être lourd en temps et en ressource pour le poste client.

Cette solution permet notamment de développer des outils de requête spatiale et de procéder à la mise à jour des données (notamment géométriques si le fichier source est une table SIG).

En revanche, elle nécessite l'installation d'un visualisateur gratuit (Adobe SVG viewer) côté client. Certains navigateurs -excepté Microsoft Internet Explorer- supportent toutefois le SVG en natif selon leur version mais demeure marginaux en termes de part de marché. Enfin pour les plateformes Linux, la librairie librsvg peut permettre notamment de convertir du .svg en .jpg ou .png (module rsvg) pour autoriser l'affichage sur des navigateurs ne supportant pas le SVG en natif.

c. Applet Java

Comme le SVG, il s'agit d'une application exécutée côté client. Elle consiste en un module écrit en Java (Sun Microsystem) et inséré dans une page web. L'application doit donc être téléchargée par le poste client avant l'affichage des données et à chaque visite du site (Alov Map, JShape 2, ArcJ).

Les données sont extraites des tables SIG (en général le format .shp d'ESRI est privilégié). Les données attributaires sont stockées dans une base de données.

A l'instar du SVG, l'avantage de cette solution est sa légèreté mais suppose aussi un volume de transfert potentiellement lourd et des délais avant visualisation pouvant être longs selon les données visualisables (hors applet en lui-même qui pèse environ 200 ko) puisque l'ensemble des couches doivent être préalablement téléchargées par le client.

Il existe toutefois une solution hybride permettant à l'utilisateur de sélectionner les données (raster ou vectorielles) qu'il veut afficher avant de les télécharger (Dynamic Alov dérivé de l'applet Java Alov Map).

Enfin, une variante client-serveur en Java a été développée toujours dans la gamme Alov et permet un téléchargement progressif des données ainsi que leur stockage dans un SGBD (servlet Java^®).

L'exécution d'une applet Java nécessite comme pour le SVG, l'implémentation côté client d'un plugin (Java Runtime Environment).

d. Serveur cartographique open source

Il s'agit de la solution la plus lourde mais la plus complète en termes de fonctionnalités. Elle suppose une architecture logicielle plus complexe que les solutions précédemment évoquées et un investissement en temps plus important pour les phases de compilation, de développement et d'intégration.

Ce type d'architecture classique client-serveur nécessite l'installation sur un serveur dédié ou partagé, des composantes logicielles minimum nécessaires au fonctionnement de l'application cartographique : serveur web, interprétateur de script, moteur cartographique. L'implémentation d'APIs PHP, Javascript, .NET, Perl, Python, Java, C# ou Ruby pour le développement d'applications spécifiques ou d'un framework (environnement d'interfaçage) permet d'intégrer ou de développer des outils de navigation plus ou moins avancés accessibles dans une interface web personnalisable.

Le moteur cartographique est le coeur du système. Il existe actuellement trois choix possibles : la plateforme Autodesk MapGuide proposée par le célèbre éditeur Autodesk, dont une version est libre (Autodesk MapGuide Open Source^4(*)) et hébergée par l'OSGeo^5(*). Cette solution offre une large panoplie de fonctionnalités ainsi qu'une interface de navigation clé en main mais doit être couplée à un autre produit, Autodesk MapGuide Studio (version de démonstration renouvelable, non libre), pour gérer les sorties d'impression ou image (layout) notamment.

MapGuide Open Source supporte de nombreux formats vecteurs ou matriciels.

GeoServer est une solution écrite en Java développée depuis 2001 et consacrée à l'implémentation de webservices (WFS-T, WMS, WCS, WMC, SLD,...)^6(*).

La troisième solution est représentée par MapServer. Très connu et réputé, MapServer est un moteur cartographique (écrit en C++) performant sur lequel sont basées de nombreuses applications cartographiques présentes aujourd'hui en ligne. Il s'agit d'un environnement de développement libre, très populaire, développé à partir de 1994 par l'Université du Minnesota (UMN) en coopération avec la NASA et le Département des Ressources Naturelles du Minnesota (MNDNR). MapServer n'est donc pas une solution clé en main personnalisable mais un moteur cartographique générant notamment les images envoyées au client. C'est un exécutable CGI (Common Gate Interface)^7(*) qui se place dans la partie inactive du serveur (Apache/cgi-bin dans le cas d'Apache).

Exploitables grâce l'API^8(*) MapScript (PHP, Python, Perl, Ruby, Java ou C#), les fonctionnalités de MapServer sont nombreuses : échelles dynamiques, étiquetage, gestions de symboles, cartographie thématique avec expressions logiques ou régulières,... (voir annexe 1 « Diagramme de classe PHPMapscript » p.36).

MapServer gère de nombreux formats vecteurs (dont les .shp) ou raster (dont TIFF/GeoTIFF et ECW) grâce aux bibliothèques GDAL pour le raster et OGR pour le vecteur et supporte la projection de cartes grâce à la bibliothèque PROJ4.

MapGuide Open Source, GeoServer et MapServer peuvent être déployés sur les plateformes Windows ou Linux et supportent les serveurs HTTP Apache et IIS.

* ⁴ http://www.autodesk.fr/adsk/servlet/index?siteID=458335&id=7499959 et http://mapguide.osgeo.org/

* ⁵ Open Source Geospatial Foundation, plateforme collaborative visant à piloter et développer les projets open source dans le domaine de la géomatique (http://www.osgeo.org/node/172).

* ⁶ WFS-T (objet vectoriel), WMS (carte), WCS (raster), WMC (sources) etc sont des protocoles de l'OGC portant sur le transfert par internet de données géoréférencées à partir de serveurs distants.

* ⁷ Un programme CGI est exécuté côté serveur. Il permet l'échange de données entre le serveur et le navigateur. Quand il reçoit une requête du poste client, le CGI détermine (en fonction de l'extension) l'action à effectuer. MapServer utilise ainsi les informations passées dans l'URL (et les paramètres renseignés dans le(s) fichier(s) de configuration -Mapfile-) pour dessiner la carte demandée ainsi que l'échelle et les envoyer via le serveur web au poste client dans une page HTML standard modélisée (template).

* ⁸ Application Programming Interface (Interface de programmation d'Application). Il s'agit ici de l'ensemble des commandes permettant d'accéder aux fonctionnalités du noyau MapServer.