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

3.1. Installation de la distribution

On a vu que le choix de la solution a impliqué un certain nombre de compilations et de tests visant à sélectionner une solution répondant au cahier des charges et une distribution stable.

Finalement, c'est donc la distribution listée précédemment qui a été retenue incluse en partie dans le paquet ms4w qui rassemble une version précompilée de MapServer, Apache, PHPMapScript et les librairies GDAL/OGR et PROJ4.

L'architecture de l'application est classique comme on l'a vu mais nécessite à ce stade l'intégration et le paramétrage de l'ensemble des composantes logicielles. Ces opérations sont rapidement évoquées ci-dessous mais pour le détail de l'installation étape par étape, voir annexe 3 « Extrait Guide de Maintenance et Utilisation » - Partie 2 « Installation » p.42.

L'installation est simple puisqu'elle consiste à copier le répertoire du paquet ms4w sur le disque dur (en général à la racine du lecteur), d'exécuter deux scripts batch (l'un installant Apache en service Windows et l'autre chargeant les librairies pour MapServer), de paramétrer les fichiers de configuration du serveur web et de PHP, de mettre à jour le path de Windows et de redémarrer la machine.

A ce stade MapServer est installé mais il reste à initialiser le SGBD et à intégrer le framework pour achever l'installation de l'environnement de travail.

Dans la distribution choisie, ces manipulations sont simples et consistent là encore à copier le répertoire de PostgreSQL sur le disque dur (en général à la racine du lecteur) et celui du framework dans le répertoire `apps' de la distribution ms4w.

Il est ensuite nécessaire de mettre à jour les alias d'Apache contenus dans le répertoire `httpd.d' du paquet ms4w ou directement dans le fichier de configuration du serveur `httpd.conf' afin que le serveur prenne en charge le framework Chameleon (la même manipulation doit être faite pour l'interface du SGBD PhpPgAdmin).

Là encore, il faut mettre à jour les variables d'environnement de Windows pour indiquer au système d'exploitation le chemin vers PostgreSQL, quel port est affecté au SGBD (port 5432 par défaut) ainsi que le nom de la machine serveur. Une fois chose faite, il faut redémarrer la machine et il ne reste plus alors qu'à initialiser le SGBD sous l'invite de commande, de charger le module spatial PostGIS et de créer la/les base(s) de données dans la/lesquelle(s) doivent être stockées les tables.

3.2. Intégration des données

L'environnement de travail étant installé et fonctionnel, il s'agissait à partir de ce moment de préparer et intégrer les données.

Deux bases de données ont été créées, l'une contenant les couches, l'autre destinée à l'administration du serveur, contenant dans un premier temps uniquement les couples login/mot de passe permettant l'accès à l'entrée protégée. Les orthophotographies (dalles ECW) ont été stockées dans un répertoire `data' de l'application puisque PostgreSQL/PostGIS ne gère pas les rasters.

La préparation des données a notamment consisté dans un premier temps à vérifier leur intégrité, certaines tables pouvant être `mitées'. Il a aussi été jugé préférable pour certaines tables, de concaténer les champs nominatifs dans un nouveau champ destiné à un étiquetage facilité sous MapServer.

Les données étaient constituées des couches métiers relatives à l'assainissement, du réseau hydrographique, des données cadastrales, du PLU, de la voirie et des emprises SNCF.

L'ensemble des tables de la base `données' a été importé à partir de .shp issues des fichiers cartographiques exploités par les services municipaux. Toutes allaient contenir un champ géométrique créé à l'import de la couche dans PostgreSQL grâce à l'extension PostGIS. Ce champ (`the_geom') contient donc les coordonnées de chaque point constituant un objet géométrique de la table ainsi que le code EPSG^12(*) correspondant à la projection Lambert III Sud (epsg :27593). Ce champ géométrique permet à MapServer de dessiner le(s) objet(s) en fonction de la requête et de générer ensuite l'image envoyée au client.

A sa création, la base `données' serait ainsi composée uniquement de tables contenant des objets géographiques qui à ce titre, pourraient être exploitées par le biais de requêtes spatiales. De plus, les données concernaient des thématiques assez indépendantes et n'entretenaient que rarement des relations autres que géométriques (spatiales) entre elles (Fig. 9.).

Seules les données cadastrales (bâti, parcelles et sections), la couche risques naturels et le zonage PLU contenaient des informations attributaires permettant une exploitation à partir du module de requête sur champ prévu par le cahier des charges.

* ¹² European Petroleum Survey Group. Organisme créé en 1985, devenu depuis le Oil and Gas Producers Surveying and Positioning Committee (OGP) ayant mis en place une base de données (www.epsg.org) contenant les systèmes de référence spatiale existant dans le monde et auxquels il a attribué un identifiant à 5 chiffres. Cette codification est utilisée dans les standards de l'Open Geospatial Consortium (OGC).