Réalisation et mise en place d`un intranet et de son appliquation

Rapport de stage du Master SIG et Gestion de l’Espace
Méthodologie de mise en oeuvre
Étude de réalisation et mise en place d'un intranet et de son application cartographique de mise en ligne
des données du SIG du CPNRC
Parcours Professionnel Auteur : Y. Jacolin
T. Joliveau
Mars­août 2006
L. Lestrat
E. Favier
Remerciements
Je tiens à remercier les personnes grâce auxquelles ce rapport de stage a pu être réalisé :
● Ludovic Lestrat, tuteur de stage, qui m'a accueilli et initié à la géomatique en 2003 ;
● le Conservatoire pour m'avoir accueilli et pour l'ambiance amicale qui y règne ;
● la société Camptocamp pour avoir écrit et libéré le code de CartoWeb3 et en particulier David Jonglez, Pierre Giraud, Oliver Christen, Alexandre Saunier, Sylvain Patches, et tout les autres développeurs pour leurs aides et leurs précieux conseils ;
● Damien Alliau qui m'a soufflé l'idée de reprendre mes études et plus particulièrement au Master SIG et gestion de l'espace de Saint­Étienne ;
● Alolise pour l'hébergement de la documentation non officielle sur CartoWeb3 ;
● l'équipe de Géorézo et de ForumSIG.
This work is licensed under the Creative Commons Attribution­Noncommercial­Share Alike 2.0 France License. To view a copy of this license, visit http://creativecommons.org/licenses/by­nc­sa/2.0/fr/ or send a letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA.
Table des matières
AIntroduction........................................................................................................................5
BPrésentations......................................................................................................................6
B.IPrésentation de la structure..........................................................................................6
B.IIDéfinitions des objectifs..............................................................................................6
B.IIIIntervenants du projet................................................................................................7
B.IVOrganisation..............................................................................................................8
B.IV.aÉtat des lieux......................................................................................................8
B.IV.bSynthèse.............................................................................................................8
B.IV.cPropositions.........................................................................................................8
B.IV.dDéveloppement...................................................................................................9
B.IV.eMise en place......................................................................................................9
B.VPlanification................................................................................................................9
CÉtude préalable.................................................................................................................10
C.IÉtat des lieux..............................................................................................................10
C.I.aAnalyse de l'existant............................................................................................10
C.I.bAnalyse des besoins.............................................................................................11
C.IISynthèse....................................................................................................................11
C.IIIPropositions.............................................................................................................12
C.III.aSolutions...........................................................................................................12
C.III.bScénario choisi..................................................................................................12
C.III.cChiffrage...........................................................................................................15
DRéalisation........................................................................................................................17
D.IPrésentation détaillée de l'outil..................................................................................17
D.I.aRappel des objectifs............................................................................................17
D.I.bL'interface...........................................................................................................17
D.I.cLes modules existants..........................................................................................19
D.I.dLa documentation et la formation.......................................................................20
D.I.eL'installation........................................................................................................21
D.IIAjustements réalisés..................................................................................................21
D.II.aLe module layerManager...................................................................................21
D.II.bLe module exportFile.........................................................................................22
D.IIIProblèmes rencontrés..............................................................................................23
EConclusion........................................................................................................................24
FBibliographie.....................................................................................................................25
GGlossaire...........................................................................................................................26
HAnnexe.............................................................................................................................27
Index des illustrations
Illustration 1 : Capture d'écran de l'interface de CartoWeb modifiée..................................17
Illustration 2 : Barre d'outil de base (navigation, requête, calculs, ...)................................18
Illustration 3 : Barre de menu rajoutée à l'interface de base...............................................18
Illustration 4 : Capture d'écran du module de navigation...................................................19
Illustration 5 : Module d'export en PDF..............................................................................20
Illustration 6 : Module de création de couche dans une table PostGIS (en anglais)............22
Index des tables
Tableau 1: Planification du stage........................................................................................10
Tableau 2: Résultat de l'analyse des besoins.......................................................................12
Tableau 3: Liste des logiciels et version utilisée..................................................................15
Tableau 4 : Investissements réalisés....................................................................................15
Tableau 5: Estimation des coûts des scénarii......................................................................16
Méthodologie de mise en oeuvre
Introduction
AIntroduction
Avant de commencer à présenter en détail la problématique du stage dans le chapitre suivant, je vais présenter le contenu de ce rapport et ses objectifs.
Ce rapport est un compte rendu du stage que j'ai effectué du 6 mars au 30 août 2006 au sein du Conservatoire du Patrimoine Naturel de la Région Centre à Orléans. Il présente la mise en place d'un serveur cartographique pour une problématique particulière. L'accent a été mis délibérément sur la méthodologie (la problématique, les objectifs, ...) et moins sur la technique pure. Celle­ci a été éventuellement placée en annexe (installation, description des logiciels testés, ...).
Ce rapport permet la compréhension de la stratégie mise en place. En effet, il existe plusieurs techniques abouties pour arriver à partager ou à diffuser des données via Internet. Aucune n'est meilleure que l'autre dans l’absolu et il est nécessaire de définir précisément la problématique, les contraintes et les fonctionnalités désirées afin de choisir l'une plutôt que l'autre.
Cependant, il ne s'agit pas ici de comparer ces techniques mais bien d'expliquer les choix qui ont amenés à utiliser telle ou telle technologie. Après le choix effectué et expliqué, la solution mise en place est décrite le plus précisément possible : quelles sont les fonctionnalités utilisées ? Pourquoi ? Quelles sont celles qui ont dû être développées, pourquoi ? Quelle stratégie de développement ? Quels problèmes rencontrés pour le développement ou la mise en place de cet outil ? Quel retour peut­on en attendre ?
Enfin, le présent rapport apportera des indications quant aux problèmes et limitations qui peuvent apparaître pendant son utilisation et proposera éventuellement des pistes à explorer.
5
Méthodologie de mise en oeuvre
Présentations
BPrésentations
B.IPrésentation de la structure
Créé en 1990, à l’initiative du milieu naturaliste (association de protection de la nature, ...), le Conservatoire du Patrimoine Naturel de la Région Centre (C.P.N.R.C.) s’est donné pour mission la sauvegarde des milieux naturels les plus remarquables pour leur faune, leur flore, leur qualité paysagère ou géologique.
Ses axes de travail sont :
●
la connaissance des espèces et des milieux ;
●
la préservation par la maîtrise foncière et la maîtrise d'usage ;
●
la gestion des parcelles dont ils sont propriétaire ;
●
l'ouverture au public, l'information et l'animation.
Le Conservatoire, outil novateur, partenarial et consensuel de protection de la nature, est constitué en association de type « Loi 1901 ».
Avec le soutien et la participation du public et de nombreux partenaires (l'Union Européenne, le ministère de l'Environnement, des collectivités territoriales comme le Conseil régional, plusieurs conseils généraux, des organismes publics comme l'Agence de l'eau ainsi que des entreprises privées), le Conservatoire préserve et gère près de 2 000 hectares répartis sur une centaine de sites.
À cette superficie, il convient d'ajouter les milieux protégés par le Conservatoire des sites du Loir­et­Cher qui coopère étroitement avec le Conservatoire du Centre pour ce département.
Le Conservatoire possède une structure éclatée. Le siège, basé à Orléans, gère la partie administrative, financière et le personnel. Les antennes bi­départementales, basées à Chateauneuf­sur­Loire (départements 28 et 45), à Vierzon (départements 18 et 36) et à Tours (départements 37 et 41), gèrent et animent le réseau de sites dans leurs départements. La gestion des sites consiste après avoir fait l'inventaire, à mettre en place un plan de gestion sur 6 ans puis de gérer les travaux (devis, réalisation, suivi) et enfin à faire vivre le site en l'ouvrant au grand public : animation pédagogique avec les écoles, lors d'événements nationaux, régionaux ou locaux.
B.IIDéfinitions des objectifs
L'objectif du stage est de permettre aux antennes d'avoir un accès aux données spatiales. Il y a pour cela plusieurs contraintes : des contraintes de coût, techniques, et d'organisation.
La contrainte de coût est due à l'absence de budget pour la réalisation de cet outil. Les coûts, qui ont été déterminés dans un premier temps, sont des coûts de licence de logiciels ou de données. Il s'agira de les minimiser autant que possible. Les contraintes d'organisation découlent de la structure du Conservatoire. Le siège gérant les données du SIG, il est nécessaire que celles créées dans les antennes y remontent de façon transparente et la moins contraignante pour les utilisateurs.
6
Méthodologie de mise en oeuvre
Présentations
Enfin les contraintes techniques sont influencées par les besoins des antennes et par la volonté d'utiliser des logiciels fonctionnant sous environnement Linux et libres.
Les objectifs du stage sont définis comme suit :
1) détermination des besoins d'un intranet dont ceux déjà pressentis : réservation de matériel, agenda commun, agenda événementiel, photothèque, rédaction de notes d'informations, ... et de son volet cartographique :
■
prise en compte notamment des problématiques de droits d'utilisation des données sous copyright, ■
des formats compressés d'images, ■
des besoins de création d'objets, ■
d'auto­hébergement, ■
financières,
■
propositions de solutions.
2) mise en place de la structure de l'Intranet et de ses premières applications déterminées par l'étude de besoins,
3) réalisation d'une maquette de la partie cartographie en ligne,
4) prospections sur les évolutions à donner au projet.
B.IIIIntervenants du projet
Plusieurs personnes sont amenées à intervenir sur le projet. Ludovic Lestrat, responsable SIG, a la charge de contrôler et de confirmer les décisions prises. Les douze personnes qui constituent le public visé dans le cadre de la mise en place du serveur cartographique interviendront au cours du processus d'évaluation des besoins. Celles­ci constituant la cible d'utilisateur.
Ludovic Lestrat
Yves Jacolin
(tuteur de stage)
(stagiaire)
Coordinateurs
Animateurs
Eco-interprètes
Médiateurs
(utilisateurs)
(Utilisateurs)
(utilisateurs)
(utilisateurs)
7
Méthodologie de mise en oeuvre
Présentations
B.IVOrganisation
Le stage est organisé en plusieurs étapes. Chacune d'elle est terminée par une réunion avec le responsable SIG (Ludovic Lestrat) afin de :
●
faire un état des lieux d'avancement du projet ;
●
définir et corriger les problèmes éventuels qui apparaîtront.
Les différentes étapes sont :
●
état des lieux du système d'information géographique (logiciels, données et procédure interne) ;
●
synthèse de l'état des lieux et des besoins ressentis ;
●
propositions techniques ;
●
développement ;
●
mise en place.
B.IV.aÉtat des lieux
Existant et besoins :
L'état des lieux permet d'avoir une bonne connaissance du système géographique tant au niveau des logiciels utilisés qu'au niveau des données et de leur structuration. Ceci permet également de bien connaître les besoins des utilisateurs potentiels du serveur cartographique.
L'état des lieux est réalisé sous la forme d'interviews. Le responsable SIG et les différents salariés des trois antennes sont interrogés.
Solutions possibles :
Il est important de bien connaître les solutions techniques existantes, de tester leurs fonctionnalités, la facilité d'installation, ... L'étude doit également permettre de s'orienter sur une technologie plutôt qu'une autre (serveur WMS/WFS ou outil de cartographie en ligne).
B.IV.bSynthèse
La synthèse permet de confirmer le choix de la structure du système d'information et les besoins des utilisateurs. Toutes les personnes interrogées reçoivent cette synthèse afin que toutes remarques puissent être formulées.
B.IV.cPropositions
Lorsque la synthèse est validée par l'ensemble des personnes, une proposition technique est alors précisée. Une maquette avec des données de test est mise en place. Bien entendu, celle­ci ne peut pas proposer l'ensemble des fonctionnalités nécessaires.
8
Méthodologie de mise en oeuvre
Présentations
B.IV.dDéveloppement
La période de développement est une période qui dépend fortement des propositions retenues. Elle­même dépendant fortement de la demande et des besoins des utilisateurs. Cette période consiste à développer des fonctionnalités qui n'existent pas dans l'offre de base de CartoWeb.
B.IV.eMise en place
La mise en place concerne la réalisation finale du serveur cartographique et la période de formation des différents utilisateurs. La mise en production en régime régulier doit débuter vers la fin du stage (fin août).
B.VPlanification
Le tableau ci­dessous indique les périodes pour chaque étape du projet. Il est seulement indicatif et a évolué en fonction de la proposition retenue.
Tableau 1: Planification du stage
Tâches
État des lieux
Synthèse
Propositions
Développement
Mise en place
Date limite
mars
avril
mai
juin
juillet
août
avril 06
mai 06
juin 06
juillet 06
août 06
9
Méthodologie de mise en oeuvre
Étude préalable
CÉtude préalable
C.IÉtat des lieux
C.I.aAnalyse de l'existant
Moyens humains
Le SIG au Conservatoire est géré au siège par un géomaticien à temps plein depuis juin 2005.
Moyens techniques
ArcGIS est utilisé et le SIG est au format shapefile. Au niveau des antennes, le logiciel TatukGIS Viewer [1] permet de créer des cartes très simplement. Les données sont donc dupliquées dans les antennes. Toutes les modifications doivent remonter au siège pour correction/vérification et intégration dans la base de données SIG.
Il existe également trois SIG mobiles dans les antennes avec le logiciel ArcPad installé.
Les données existantes
Les données sont classées en deux catégories : les données dont le Conservatoire est producteur (et donc propriétaire) et les données externes, très souvent achetées, provenant essentiellement de l'IGN [2].
Les données externes au Conservatoire sont :
●
BD Carthage ;
●
BD Ortho ;
●
GéoFLA ;
●
Scan 25 ;
●
Scan 250 ;
●
SIEL Ortho.
Les données du Conservatoire sont constituées des inventaires des sites gérés (objectif « connaissance des espèces et des milieux » du Conservatoire). Ces données évoluent régulièrement en fonction des inventaires réalisés par le chargé d'études scientifiques de l'antenne en charge du site.
D'autres données existent sous forme de base de données Access : base foncière, BD Nat, ...
La structure du SIG est la suivante :
●
Data : répertoire contenant les données géo­référencées (rasteur, vecteur, tableur, texte, ...). Celui­ci contient un répertoire référentiel (scan25, BD Ortho, GeoFLA, ...), un répertoire thématique (agriculture, eau, géologie, ...), un répertoire analyse (résultat des analyses), un répertoire acquisition et un habillage. Les données 10
Méthodologie de mise en oeuvre
Étude préalable
contenues dans les répertoires analyse et acquisition sont déplacées dans le répertoire thématique après validation.
●
Proj : contient les fichiers de gestion projets (apr, wor, ...).
●
Echange : données reçue ou envoyé à d'autres organismes.
●
Outils : les script développés en internes ou non.
Les données dans répertoire Data/thématique, créées par le Conservatoire, ont un volume total de l'ordre de 1,6 Go.
C.I.bAnalyse des besoins
Une première analyse des besoins a été réalisée avec le responsable SIG. Celui­ci avait déjà pu discuter avec les différents utilisateurs potentiels des problématiques rencontrées. Les utilisateurs potentiels peuvent être classés en fonction de leur poste de travail, leurs besoins étant directement liés à celui­ci.
Une deuxième analyse est réalisée après la démonstration de l'outil à l'ensemble des antennes. Cette démonstration a pour but de montrer ce qu'il est possible de faire, de tester l'intérêt des utilisateurs potentiels et leur compréhension.
Les besoins retenus après ces deux analyses sont présentés dans le tableau suivant.
Typologie des besoins
Localiser des sites
Description détaillée
Zoomer, dé­zoomer, se déplacer, trouver un emplacement rapidement (raccourci), échelle.
Éditer/créer des données Ajouter des données, créer de nouvelles couches, importer des données ou des couches réalisées à partir du SIG mobile, valider les données après intégration dans le SIG pour vérification.
Créer des cartes
Créer des cartes en A3, A4, pleine page, dans une mise en page éditable ou succincte pour le terrain.
Exporter des données
Exporter les données vectorielles
Calcul – statistique – lire Calculer une distance, une surface. Faire des des données
requêtes très simples.
Tableau 2: Résultat de l'analyse des besoins
Ces besoins, pour la plupart, existent dans toutes solutions Desktop ou Internet.
C.IISynthèse
L'organisation en antenne du Conservatoire et l'utilisation des données dans chaques antennes posent quelques problèmes. Tout d'abord d'un point de vue des droits de diffusion, certaines données ne peuvent pas être copiées. De plus, les données produites 11
Méthodologie de mise en oeuvre
Étude préalable
doivent remonter jusqu'au responsable du SIG pour intégration après contrôle dans le SIG principal.
Les solutions proposées devront donc prendre en compte des contraintes de diffusion (droit et copyright des données), des contraintes organisationnelles (les informations doivent remonter jusqu'au responsable avec le moins de contraintes possibles), des contraintes techniques (logiciel libre, documenté, avec les fonctionnalités nécessaires), et enfin des contraintes de coûts.
Enfin, la solution choisie devra faire l'objet d'une documentation pour l'utilisateur final. Cette documentation devra être suffisamment pédagogique puisque le public visé a de faible connaissances en géomatique et en informatique.
C.IIIPropositions
C.III.aSolutions
Les logiciels présentés ici peuvent être classés en deux catégories : ●
les solutions client distant/serveur ;
●
les solutions client­serveur. Les solutions client distant­serveur sont constituées d'un serveur WMS/WFS et d'un client installé sur la machine de l'utilisateur. Les solutions client­serveur sont constituées d'un « client » et d'un serveur sur la même machine. Ces solutions sont plus connues sous le terme de solution de webmapping.
Les solutions à base de client distant nécessitent un serveur cartographique WMS/WFS. Celui­ci est généralement constitué avec UMN MapServeur (appelé MapServer par la suite). D'autres serveurs existent tels que Geoserver, mapGuide Open Source (appelé mapGuide OS par la suite) et Chameleon. Les clients distants sont moins nombreux, on trouve uDIG, QGIS, GvSIG, deegree, JUMP et OpenJUMP.
Les solutions de cartographie sur Internet utilisent généralement MapServer et ses possibilités en PHP. Parmi ceux­ci, on trouve CartoWeb, MapLab, MapBender, ka­Map. Certains utilisent leurs propres moteurs cartographiques, tel que Chameleon, MapBender et mapGuide OS. Pour plus d'informations sur certains de ces logiciels, confère l'annexe A et l'entrée bibliographique [3], qui présente une description plus détaillée.
C.III.bScénario choisi
Le scénario choisi est constitué d'un ensemble de logiciels et de procédures. Pour la partie logicielle, l'ensemble MapServer et CartoWeb a été choisi. Au niveau des procédures, il est nécessaire de guider les utilisateurs dans leur démarche, notamment pour la création des données : procédure de création et de validation des données. Une documentation et une formation sont incluses dans ce scénario.
Le couple MapServer et CartoWeb a été préféré pour plusieurs raisons. Après avoir testé l'ensemble des techniques décrites dans la section précédente, il s'est avéré que ceux­ci étaient les plus utilisés [4], les plus pratiques à mettre en place, les plus documentés et les 12
Méthodologie de mise en oeuvre
Étude préalable
plus intéressants sur le long terme notamment pour ce qui concerne CartoWeb qui a été pensé comme un ensemble modulaire pouvant facilement évoluer.
Un autre critère a été important dans le choix de ce scénario : la minimisation des contraintes pour les utilisateurs. Pas d'installation, indépendant de leur station de travail, les données sont gérées sur le serveur directement par le responsable géomatique.
L'interface peut être personnalisée mais celle­ci reste très agréable par défaut. La possibilité de gérer les données créées et/ou importées directement sur le serveur permet une gestion facilitée pour les mises à jours. En effet, le SIG mis à disposition par cette interface ne sera pas le SIG officiel géré par le responsable SIG mais une copie de celui­ci. De plus cela assure que les données soient centralisées. Le schéma page suivante illustre la structure du réseau.
D'autres solutions auraient pu utiliser les possibilités WFS/WMS/WCS de MapServer couplé avec un client tel que uDIG, OpenJUMP ou GvSIG, comme décrit dans la section précédente. Malheureusement, MapServer ne gère pas le WFS­T (WFS transactionnel, c'est à dire la possibilité de mettre à jour les données, seul l'affichage est possible). Il était donc nécessaire soit d'utiliser une base de données PostGIS pour l'édition couplé à QGIS, soit d'utiliser Geoserver, qui permet le WFS­T. Pour plus d'informations à ce propos, lisez le document [5] qui propose d'utiliser la première solution.
Le choix entre ces deux solutions s'est fait sur la manière de gérer les données et la facilité d'utilisation de cette infrastructure par les utilisateurs.
En effet, CartoWeb, tout en étant simple d'installation et d'utilisation, remplissait l'ensemble des critères techniques : édition des données, calcul des distances et des surfaces, export des cartes aux formats HTML et PDF, ...
Cependant, quelques fonctionnalités manquaient à CartoWeb3 pour convenir parfaitement aux besoins. Ces besoins étaient :
●
importer et créer des données ;
●
exporter des fichiers ;
●
modifier la symbologie des couches.
Les deux premiers besoins ont fait l'objet d'un développement interne pendant le stage. Cela a donné deux modules appelés layerManager et exportFile. La possibilité de modifier la symbologie n'a pas été réalisée, la société Camptocamp va être amenée à développer un tel module, beaucoup plus puissant d'ici quelques mois. Les annexes B et C présentent le cahier des charges techniques des deux modules développés.
L'utilisation des logiciels libres fait partie des contraintes déclarées. Ils ont donc été abondamment utilisés. Chacun constitue une brique qui permet par leur assemblage et leurs interactions (inter­opérabilité) de constituer un ensemble cohérent et efficace. L'ensemble des logiciels et leurs versions sont présentés dans le tableau ci­dessous.
13
Méthodologie de mise en oeuvre
Étude préalable
Illustration 1 : Schéma du réseau extranet
14
Méthodologie de mise en oeuvre
Logiciel
Étude préalable
Version
Description
Proj4
4.4.9
Bibliothèque de gestion de projection.
GDAL­OGR
1.3.1.2
Bibliothèque de gestion de format vectoriel et raster.
libECWj
2­3.3­RC2­ Bibliothèque du format ECW.
2006­02­08
GEOS2
2.1.4
Bibliothèque de GEOS qui fourni des opérateurs topologiques.
PHP
5.0.4
Langage de script.
Apache
2.0.54
Serveur web.
PostGreSQL
8.0.7
Base de données.
PostGIS
1.1.1
Cartouche spatiale de PostGreSQL.
UMN MapServer 4.8.3
Moteur cartographique.
CartoWeb3
Interface graphique à UMN MapServer.
3.2
Tableau 3: Liste des logiciels et version utilisée
C.III.cChiffrage
Il est encore trop tôt pour avoir une idée précise du chiffrage du coût. Cette section s'attachera simplement à mettre en avant les économies réalisées entre cette stratégie et celle qui consistait à copier les données et installer un logiciel de SIG dans chaque antenne (appelé scénario refusé).
Produits
Coût € TTC
BD Ortho (546 dalles)
6 600
Scan 25 + BD Carthage
20 606
Total
21206
Tableau 4 : Investissements réalisés
La licence nécessaire pour la mise en place d'un serveur cartographique est calculée sur la base du nombre d'utilisateur simultané et en fonction des données diffusées. Ainsi pour 10 postes clients potentiels, la diffusion de l'ensemble des scan25 de l'IGN coûtera 1,8 fois le coût de la licence mono­poste. La licence mono­poste ayant déjà été achetée, la mise en place du serveur cartographique est calculé ainsi : 80 * 21 206 / 100.
15
Méthodologie de mise en oeuvre
Étude préalable
Typologie des coûts
Scénario choisit
Scénario alternatif
Scénario refusé
Logiciels
CartoWeb
QGIS + WFS­T
ArcGIS
0
0
3 * 4 500 HT
Données
Total
Scan25
Scan25
16 965
21 206 * 3
16 965
77 118
Tableau 5: Estimation des coûts des scénarii
16
Méthodologie de mise en oeuvre
Réalisation
DRéalisation
D.IPrésentation détaillée de l'outil
D.I.aRappel des objectifs
L'objectif du serveur cartographique est de permettre de partager les données du SIG entre les différentes antennes afin que celles­ci aient accès à l'information géographique dans le cadre de leur travail.
D.I.bL'interface
L'interface doit être conviviale, les outils accessibles facilement. Celle­ci est composée d'une barre d'icônes et d'une barre de menu pour utiliser les principales fonctionnalités de cet outil (1), d'une partie de gestion des modules (navigation, export, import, ...), de la carte principale (légende et carte de situation comprises, 2 et 3), et d'une partie dans laquelle certains messages peuvent apparaître (4). Illustration 2 : Capture d'écran de l'interface de CartoWeb modifiée
17
Méthodologie de mise en oeuvre
Réalisation
Les barres de menu et d'icônes
La barre de menu permet de lancer l'affichage des modules (naviguer, exporter, importer, ...). Cette barre comprend également une liste déroulante pour passer entre les différentes antennes et une échelle numérique.
Illustration 3 : Barre d'outil de base (navigation, requête, calculs, ...)
Illustration 4 : Barre de menu rajoutée à l'interface de base
La gestion des modules
Les modules sont gérés par une interface graphique à l'intérieur du navigateur, c'est à dire qu'il n'y a pas de fenêtre qui s'ouvre. Leurs affichages sont gérés par le menu. Ainsi dans le menu « Affichage », on trouve « Navigation » qui permet d'afficher la gestion de la navigation : se localiser à partir d'un point référencé, zoomer sur une région définie (raccourcis), ...
Chaque module s'affiche indépendamment l'un de l'autre. Il ne peut y avoir qu'un seul module d'ouvert en même temps.
La carte principale
La carte principale se compose de la carte en elle­même et de certaine fonctionnalité de navigation (se déplacer à l'est, l'ouest, au nord, au sud, ...), et de situation (coordonnée en Lambert 93), et l'échelle graphique, en plus de l'échelle numérique dans la barre de menu. Le déplacement à l'aide des flèches de direction (nord, sud, ...) permet un recouvrement de 20 % entre l'ancienne situation et la nouvelle.
L'affichage des messages et des résultats
Les messages pour le développement de CartoWeb ont été désactivés. Seuls les résultats des requêtes s'afficheront dans cette partie lors de la mise en production de l'outil final.
18
Méthodologie de mise en oeuvre
Réalisation
D.I.cLes modules existants
Module navigation
Ce module doit permettre de se situer dans l'espace géographique maximale (la région), de connaître l'échelle, ou d'avoir des raccourcis pour atteindre un niveau de zoom et une région précise.
Illustration 5 : Capture d'écran du module de navigation
Module couches thématiques et ordre des couches
Ce module permet d'ajouter ou d'enlever des couches à la carte ainsi que d'exporter ces couches au format shapefile.
Ces couches peuvent être déplacées les unes au­dessus des autres sous la forme de calque. Ces calques peuvent être mis en transparence.
Module exporter
Exporter des données ou des cartes est une demande importante. L'objectif est de pouvoir insérer une carte dans un rapport, de l'imprimer sur une feuille A3 pour l'utiliser sur le terrain et enfin pour pouvoir l'intégrer dans le SIG mobile pour numérisation.
Pour cela, il existe trois modes d'exportation. Le premier permet d'exporter la carte, l'aperçu et la barre d'échelle graphique au format image. Le second permet d'exporter une mise en page de la carte définie par défaut. Plusieurs choix sont possibles dans la mise en page : A3 ou A4, paysage ou portait, ... Enfin le dernier mode permet de sauver la couche au format shapefile pour une couche vecteur et au format d'origine pour une couche raster.
19
Méthodologie de mise en oeuvre
Réalisation
Illustration 6 : Module d'export en PDF
Module gestion des projets
Les couches ajoutées, les niveaux de zoom et d'autres paramètres peuvent être sauvegardés dans des fichiers sur le serveur afin de pouvoir retrouver son travail après une pause ou un arrêt prolongé.
Module couche brouillon
Ce module est présent dans la version finale de l'outil mais ne constitue pas une demande précise de la part des différentes antennes. Cependant cela peut s'avérer utile pour discuter, faire des tests ou bien pour calculer des surfaces ou des distances rapidement.
Module d'édition
Le module d'édition doit permettre d'ajouter des données dans les couches proposées. Cependant, dans le but de garder un SIG stable et fonctionnel, une procédure précise sera mise en place. Cette procédure est en annexe D. En voici quelques points importants : ●
L'utilisateur créé la couche et entre les données ●
il doit prévenir par mail le responsable SIG lorsqu'il juge sa couche terminée. ●
celui­ci l'exporte et la valide. La validation de la couche consiste à vérifier les méta­données, le nom des champs et leurs types, le nom de la couche, et les géométries.
D.I.dLa documentation et la formation
La documentation et la formation sont très importantes dans la réussite de cet outil. Les utilisateurs cibles n'ont pas eu de formation en géomatique. Il est nécessaire, lors de ces journées de formations, d'utiliser des exemples précis à la manière d'un how­to (comment faire pour ... ?) et de ne pas trop insister sur les concepts.
La documentation pourra être beaucoup plus orientée fonctionnalités que la formation, 20
Méthodologie de mise en oeuvre
Réalisation
basée sur des procédures. Il s'agira d'un document type aide­mémoire.
D.I.eL'installation
L'installation de CartoWeb n'est pas compliquée à mettre en oeuvre. Cependant, il existe des contraintes qui ne doivent pas être ignorées. Par exemple, PHP doit être de version 5 ou supérieure, installée en mode CGI. PHP/Mapscript doit être installé également.
De plus, le Conservatoire utilise des fichiers raster au format ECW. Cela implique l'installation de la bibliothèque libECWj avec GDAL­OGR. Ces outils ne peuvent pas être installés à partir des fichiers binaires, soit parce qu'ils n'existent pas (par exemple pour libECWj) soit parce que la version binaire n'est pas configuré correctement (par exemple GDAL­OGR). La compilation de GDAL­OGR avec libECWj n'est pas forcément une chose aisée ce qu'il faut signaler.
De plus, certaines versions de MapServer possèdent des problèmes, notamment en ce qui concerne les requêtes, ces versions doivent donc être évitées. La version binaire diffusée avec la distribution utilisée pour le serveur (une Mandriva 2006) est une version qui pose problème. Il faut donc, là encore, compiler MapServer.
D.IIAjustements réalisés
Deux des demandes étaient de pouvoir créer de nouvelles couches ou d'importer des couches qui provenaient du SIG mobile et de pouvoir exporter les couches dans un fichier shapefile, là encore pour pouvoir les utiliser dans le SIG mobile.
Aucun des modules ne répondaient à l'une de ces demandes. Il a donc fallu développer deux nouveaux modules pour y répondre. Ces modules ont été appelés layerManager et exportFile.
D.II.aLe module layerManager
Le module layerManager permet de créer de nouvelles couches dans une base de données PostGIS. Vous trouverez en annexe B le cahier des charges technique.
Ce module doit éviter que l'utilisateur entre des informations contradictoires et erronées tout en l'obligeant à renseigner celles qui sont importantes. Ainsi, il doit renseigner les informations suivantes :
●
nom de la couche ;
●
type de la couche : point, polyligne ou polygone ;
●
auteur ;
●
description ;
●
échelle de précision ;
●
éventuellement la projection, par défaut, Lambert93 ;
●
les champs (au moins un est nécessaire) et son type : entier, chaîne, booléen dans le cas d'une création de table ;
21
Méthodologie de mise en oeuvre
●
Réalisation
le fichier à importer pour le second cas.
Le fichier à importer doit être un fichier compressé, contenant les trois fichiers du format shapefile : shx, shp et dbf. Tout autre format causera une erreur. Il n'y a pas de limite de taille de fichiers, ce qui dans certains cas pourrait provoquer une erreur.
D'autre part, il est possible, lors de la création des champs d'une couche de type polygone de définir un champ dans lequel la surface sera calculée par PostGIS. Ce champ doit s'appeler surf, être de type entier et la couche doit être de type polygone.
Illustration 7 : Module de création de couche dans une table PostGIS (en anglais)
D.II.bLe module exportFile
Le module exportFile permet d'exporter les couches au format shapefile pour les vecteurs et, aux formats d'origine pour les raster. Vous trouverez en annexe C le cahier des charges technique.
Ce module ne peut que générer du shapefile pour les vecteurs, que la couche provienne d'une base de données PostGIS ou d'un fichier vecteur. Pour les fichiers raster le format du fichier n'a pas d'importance et le fichier envoyé sera du même format que celui d'origine.
22
Méthodologie de mise en oeuvre
Réalisation
D'autre part, il est possible de limiter l'export des fichiers en fonction de leur nom. Ainsi les couches qui sont trop importantes pour être compressées peuvent être ainsi limité. En effet, la taille du fichier peut être limité mais seulement du côté serveur de CartoWeb. Le processus d'envoi du fichier, quant à lui, débute dans la partie client. Il n'est donc plus possible de l'arrêter. Cette limitation, bien que prévue dans le cahier des charges, n'a pas pu être développé faute de temps.
D.IIIProblèmes rencontrés
Les problèmes rencontrés sont de plusieurs types. Mais ceux­ci sont liés au fait qu'il a fallu prendre du temps pour parfaire ma connaissance du PHP orienté objet, de PHP/mapscript et de CartoWeb. Ce dernier manque de documentations mais la liste de diffusion est cependant suffisamment active pour obtenir les informations nécessaires.
La recherche de ces informations, et plus particulièrement, l'amélioration de mes compétences dans ces trois domaines, a retardé le développement de ces deux modules. De plus, ceux­ci sont un premier développement et on y retrouve les limitations de mes connaissances techniques. Ainsi, pour ce qui concerne l'importation des fichiers du module layerManager, il serait plus intéressant d'utiliser les capacités de MapServer pour la lecture des données vecteurs et leur création et la possibilité de créer un mapfile à l'aide de la fonction save() de PHP/Mapscript.
Pour le module exportFile, la taille des fichiers à exporter reste problématique, même si une solution a été trouvée. Une réflexion sur le module exportPlugin de CartoWeb doit être faite. Doit­il être utilisé pour ce module ?
D'autre part, une demande a été formulée pour pouvoir exporter au format SVG mais n'a pu être développée faute de temps. Il est possible de s'inspirer du module exportFile pour créer un module exportSVG qui pourra utiliser la possibilité de PostGIS pour obtenir les données géométriques au format SVG. Pour les couches au format autre que PostGIS, il y a la possibilité d'utiliser l'outil shp2svg.
23
Méthodologie de mise en oeuvre
Conclusion
EConclusion
L'outil réalisé répond en grande partie aux demandes exprimées par les utilisateurs tout en répondant aux contraintes du projet. L'utilisation de l'ensemble MapserServer – CartoWeb – PostGIS semble être une bonne alternative à celle d'utiliser un logiciel SIG de bureau avec copie des données du SIG en local, ou lorsque l'on utilise un logiciel client d'un serveur de base de données PostGIS couplé ou non avec un serveur de web­service.
Cependant, cela n'est pas complètement satisfaisant au regard du confort d'utilisation que l'on a lors d'une utilisation des données en local par exemple. CartoWeb est un outil encore jeune pour une utilisation comme « SIG de bureau ». Certaines fonctionnalités de création ou d'export de couches n'existent pas. D'autre comme la modification de la symbologie (ajout d'étiquettes, création d'une carte thématique, ...) absente pour le moment, pourraient voir le jour d'ici quelques mois dans une prochaine version de CartoWeb.
Les limitations de cette solution que l'on peut donc mettre en avant sont :
●
Une limitation dans la création et l'import des couches et l'export des données insatisfaisantes. Ces deux modules ont été développés dans le cadre de ce stage, mais les connaissances trop limites dans le développement en PHP orienté objet et dans CartoWeb rendent ces modules non portables. Seule l'utilisation dans le cadre du serveur cartographique du Conservatoire ne pose pas de problème, les modules n'ayant pas été développé dans les règles de l'art.
●
Le débit de la bande passante ajoute une contrainte supplémentaire. Selon le débit, la création, l'export ou tout simplement le travail sur le serveur cartographique peuvent devenir pénibles. Aucun test n'a été effectué pour connaître la réaction du serveur lors d'une utilisation intensive avec plusieurs utilisateurs, sachant que celui­
ci est utilisé pour héberger l'ensemble des outils de l'Intranet (agenda, album photo, ...). Lors de la présentation de l'outil dans les différentes antennes, l'utilisation semblait possible. Mais la bande passante de la connexion Internet de certaines antennes laisse à désirer (débit très faible, déconnexion, ...).
L'outil CartoWeb couplé à MapServer et à PostGIS est une bonne alternative à l'achat de licences logiciels. Cependant, il ne faut pas oublier les autres contraintes qui apparaissent selon les outils mis en place. CartoWeb est un outil encore assez jeune mais dont les bases du développement (modulaire, développement GPL, ...) le rendent peu à peu incontournable, au moins dans la phase d'étude des solutions techniques.
Les prochaines versions amèneront de nouvelles fonctionnalités telles que la sélection ponctuelle, surfacique (polygone ou rectangulaire), l'export de la carte au format image, la gestion des projets et de la symbologie. Ces fonctionnalités constituent les derniers manques dans l'utilisabilité du serveur cartographique du Conservatoire.
24
Méthodologie de mise en oeuvre
Bibliographie
FBibliographie
[1] TatukGIS company, http://www.tatukgis.com
[2] IGN, http://www.ign.fr
[3] Paul Ramsey. The State of Open Source GIS,Refractions Researcg inc. May 2006.
[4] Diop, Bouard, Stancioff, Van der Biest. Mapserver, solution de SIG en ligne – Un état des lieux de son utilisation en France. Mai 2006, Mastère SILAT.
[5] Brunet, Lançon, Reyreau, Saunal. Mini­projet, Réalisation d'un prototype sur une architecture client/serveur pour la saisie de données géographique à distance. http://www.geo2i.com/serveur_open_source/serveur_open_source.pdf
[6] Ludovic Lestrat et al. La cartographie sur Internet : introduction à un état de la technique. 2002­2003. http://sig.cwriter.org/index.php/Webmapping
[7]Open Source Geospatial Foundation Website, https://www.osgeo.org/
[8] The FreeGIS Project, http://freegis.org/
[9] Open Geospatail Consortium (OGC) Website, http://www.opengeospatial.org/
[10] Jody Garnett, User­firendly Desktop Itnernet GIS, Refractions Research Inc. Nov. 2005.
[11] Camptocamp. Cartoweb Documentation – 3.2.0 Edition. Camptocamp. February 2006.
[12]Frédéric
Bauer.
Présentation
http://www.alolise.org/wiki/index.php?title=CartoWEB3
de
CartoWeb3. [13] Yves Jacolin, Documentation de CartoWeb3 en français, http://www.alolise.org/wiki/index.php?title=CartoWeb3.1.0
[14] Brock Anderson, A Comparison of ArcIMS to MapServer. MUM/OGEO 2005. Refractions Research Inc. Juin 2006.
25
Méthodologie de mise en oeuvre
Glossaire1
GGlossaire1
Mapfile : fichier contenant les informations du projet c'est à dire les couches à afficher par MapServer, l'étendu géographique, le format d'image pour l'export, l'échelle graphique, l'image de référence, les symboles, les polices, ...
SOAP : Simple Object Access Protocol (SOAP) est un protocole de RPC orienté objet bâti sur XML. Il permet la transmission de messages entre objets distants, ce qui veut dire qu'il autorise un objet à invoquer des méthodes d'objets physiquement situés sur une autre machine. Le transfert se fait le plus souvent à l'aide du protocole HTTP, mais peut également se faire par un autre protocole, comme SMTP.
WFS : Un service Web Feature Service ou WFS permet à un client de réaliser des manipulations sur un ou des objets géographiques en utilisant une plate­forme informatique. Le WFS est décrit dans des spécifications maintenues par l'Open Geospatial Consortium. Il s'oppose au Web Map Service qui offre un accès à un ensemble de cartes.
WMS : Web Map Service ou WMS permet de produire des cartes de données géoréférencées à partir de différents serveurs de données. Ainsi, cela permet de mettre en place un réseau de serveurs cartographiques à partir desquels des clients peuvent construire des cartes interactives. Le WMS est décrit dans des spécifications maintenues par l'Open Geospatial Consortium. OSGEO – OGC : L'Open Geospatial Consortium, ou OGC, est une organisation internationale à but non lucratif dédiée au développement des systèmes ouverts en géomatique. Plus de 300 organismes commerciaux, gouvernementaux et de recherches dans le monde entier, collaborent à encourager le développement des systèmes ouverts, des normes et des standards pour le contenu et les services geospatiaux, les SIG et les échanges informatiques. Cet organisme était autrefois connu sous le nom de Open GIS Consortium.
1 Les définitions proviennent du site wikipédia, sauf mention contraire.
26
Méthodologie de mise en oeuvre
Annexe
HAnnexe
A – Description de quelques logiciels qui peuvent être utilisés dans une gestion décentralisée de l'information géographique.
B – Cahier des charges techniques du module layerManager.
C – Cahier des charges techniques du module exportFile.
D – Protocole de création et de validation des données PostGIS.
E – Documentation de CartoWeb3.
F – Protocole de création/importation de données sur le serveur cartographique du Conservatoire.
27