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

2.2. Technologie et distribution choisies

Le cahier des charges prévoyait des outils de navigation qui excluaient le recours à la solution la plus légère, la carte statique. De la même façon, il spécifiait qu'aucune installation ne devait être nécessaire sur le poste client pour visualiser les données. Les options SVG et Java ont donc dû être écartées (Fig. 6.).

Le choix s'est alors porté sur la solution serveur cartographique mais il restait à ce stade, à arbitrer entre le produit open source de la gamme MapGuide d'Autodesk, GeoServer et MapServer. C'est finalement MapServer qui a été retenu compte tenu de sa grande adaptabilité qui permet le développement d'applications personnalisées, du fait aussi que la gestion de la mise en page de sortie (layout) est libre, de la richesse de la documentation disponible et du dynamisme de sa communauté de développeurs.

La solution choisie pour la Mairie de Crest est finalement l'une des plus fréquentes et des plus éprouvées puisqu'elle est construite autour de MapServer. Elle a été développée pour un environnement Windows. Il s'agit d'une distribution associant à MapServer, le serveur web Apache, l'interprétateur de script PHP qui permet au serveur de lire les scripts, l'API MapScript, les librairies GDAL/OGR et PROJ4, un client web à partir duquel est développée l'interface utilisateur et un Système de Gestion de Bases de Données (SGBD) permettant une administration centralisée des données et facilitant leur mise à jour notamment (Fig. 7.).

MapServer n'est ni compilé ni associé avec aucun client web prédéfini. Il a donc fallu opter soit pour un développement ex nihilo de l'interface web et des fonctionnalités demandées dans le cahier des charges, à partir de l'API PHPMapscript de MapServer, soit choisir un framework (environnement de développement de l'interface web) libre existante.

Là encore, plusieurs projet open source existent (MapBuilder, Ka-Map, Cartoweb, Chameleon, MapBender, OpenLayer etc). Après un listing exhaustif de ces solutions et des essais comparatifs limités à quelques unes d'entre elles compte tenu des délais de la mission, Chameleon (Configurable Web Mapping Client Component - CWC2)^9(*) a été retenu.

Il s'agit d'un environnement de développement libre pour l'interfaçage d'applications de webmapping basées sur MapServer. Ce client respecte les standards définis par l'OGC (Open Geospatial Consortium) et permet d'intégrer des fonctionnalités basiques de navigation écrites en php (widget) existantes, d'en adapter et d'en développer de plus avancées et personnalisées. Outre sa praticité lors de la phase de développement et d'intégration de la solution, l'avantage du framework est d'établir un environnement normé de développement facilitant l'adaptation du géomaticien ou développeur appelé ultérieurement à étendre ou adapter les fonctionnalités actuelles de l'application.

Enfin, le serveur cartographique devait être couplé à un SGBD relationnel supportant les données géographiques pour répondre aux spécifications du cahier des charges en matières d'administration des données^10(*).

Le choix est ici plus restreint dans le monde du libre. Le très populaire MySQL supporte les données géométriques et géoréférencées depuis sa version 4.1. L'autre solution est représentée par PostgreSQL et son extension spatiale PostGIS^11(*), très utilisée dans le domaine spécifique du webmapping et souvent associé à MapServer. Cette dernière solution a été retenue, complétée par l'interface web intuitive d'administration des données stockées dans le SGBD, PhpPgAdmin.

Au total le système utilise environ 8 Mo de ressource mémoire, Apache et PostGIS tournant en service windows. L'espace disque nécessaire varie en fonction des données.

3- Intégration et développement

* ⁹ Chameleon a été développé par DM Solutions Inc. pour le Canada's GeoConnections Access Program (http://chameleon.maptools.org).

* ¹⁰ Cette architecture classique est en outre nécessaire pour envisager l'implémentation future de nouvelles fonctionnalités telles que le traitement de requêtes spatiales. Cet outil n'était pas prévu par le cahier des charges où la simplicité et l'intuitivité étaient souhaitées, mais fortement envisagé dans une nouvelle phase de développement de l'application.

* ¹¹ Portails communautaires : http://www.postgresqlfr.org et http://www.postgis.fr