Université de Toulouse

MASTER 2 GEOMATIQUE Parcours Professionnel :

« Science de l’Information Géoréférencée pour la Maîtrise de l’environnement et

l’Aménagement des territoires » (SIGMA) http://sigma.univ-toulouse.fr

RAPPORT DE STAGE

PROTOTYPAGE D’UNE APPLICATION WEBSIG

DE RESEAU D’ALIMENTATION EN EAU POTABLE

Gbati Batame TAFAMBA-DABOU

Boubee-Dupont Eau et Environnement Maître de stage : Monsieur Yvain BOUBEE-DUPONT Tuteur-enseignant : Monsieur Laurent JEGOU

Mars - Juin 2013

Remerciements

Je tiens à remercier Mr Yvain BOUBEE-DUPONT, gérant du bureau d’études Boubée-Dupont Eau et Environnement (bdEe) pour cette opportunité et pour son encadrement tout au long de mon stage. Je n’oublie pas tous mes collègues de BDEE pour leur soutien. Je remercie également Monsieur Bruno MORA Directeur du SIAEP ADOUR-COTEAUX et tous ses collaborateurs pour leur contribution dans le développement de l’application. Je tiens à remercier particulièrement mon tuteur enseignant Mr Laurent JEGOU pour tous ses conseils et son expertise dans le domaine du WebMApping. Je voudrais également saisir cette opportunité pour remercier tout le corps enseignant du Master 2 Géomatique SIGMA pour tout ce qu’ils m’ont apporté durant cette année de formation ainsi que tous les camarades de la promotion 2012-2013 de SIGMA pour l’esprit de solidarité et la formidable ambiance qui a permis à tout un chacun de tirer le meilleur de cette formation. Enfin, dans un registre plus personnel, je voudrais remercier les membres de ma famille et tous mes amis qui m’ont encouragé et soutenu tout au long de cette année. Le peu que j’ai réussi à faire c’est grâce à eux.

Résumé

Depuis 20 ans, Boubee-Dupont Eau et Environnement (BDEE) met ses compétences au service des collectivités territoriales dans le domaine de l’eau potable, de l’assainissement ainsi que sur des projets d’aménagement de voirie. La cartographie de précision fait partie des outils indispensables sur lesquels se base BDEE pour mener à bien ses projets. L’objectif de mon stage a été d’améliorer l’application WebMapping existante dans le but de mettre à disposition des collectivités territoriales qui souhaiteraient partager leurs données SIG en ligne, une Plateforme Web sécurisée et simple d’utilisation. Pour ce faire, la tâche à laquelle je me suis premièrement investi a été de réaliser une analyse du site existant afin de comprendre son architecture et son mode fonctionnement. Ce site a été conçu en 2005 sous Mapserver. La seconde tâche de mon stage a été de faire une analyse des besoins. Cette analyse nous a permis dans un premier temps d’établir une liste de données gérées dans un SIG de l’eau avec leurs attributs et, dans un second temps, d’identifier les fonctionnalités de la nouvelle application. Suite à l’analyse des besoins, nous avons proposé pour la nouvelle application une architecture composée d’un SGBD : Postgresql/PostGis, d’un serveur cartographique : GeoServer et de GeoExt comme application cliente. Cette architecture s’est imposée afin de répondre au besoin de mettre à disposition des utilisateurs des outils d’édition de données online. Le prototype réalisé à l’issue de mon stage fonctionne de manière satisfaisante. Toutefois, il faut noter la nécessité de développer une version optimisée pour un terminal mobile. Pour ce faire, j’ai recommandé d’utiliser l’application cliente GXM qui est la version mobile de GeoExt.

Abstract

For 20 years, Boubee-Dupont Eau et Environnement (BDEE) puts its expertise to local community in the field of drinking water, sanitation and on development of road projects. Quality maps are one of the essential tools that BDEE uses to carry out its projects. The objective of my internship training was to improve the existing WebMapping implementation in order to provide to local communities wishing to share their GIS data online, a secure web application which would be easy to use. To achieve this goal, I firstly perform an analysis of the existing application in order to understand its architecture and operation mode. This application was created in the year 2005 with Mapserver. My second task was to do need analysis. This analysis allowed us to establish a list of layers with their attribute values that are managed in a water GIS. I also identify the principal tools which would be developed

in the new application. Following the analysis of the needs we have proposed for the new application architecture Postgresql / PostGIS as database, GeoServer as map server and GeoExt as client application. This architecture emerged to meet the need to provide users with online editing tools. The prototype I realized at the end of the study works properly but it will be necessary to develop an optimized version for smartphone. In order to achieve this, we recommend using the client application GXM which is the mobile version of GeoExt.

Sommaire

Introduction ........................................................................................................................................................................ 1

I. PRESENTATION DE L’ORGANISATION D’ACCUEIL ......................................................................................... 2

1. Historique .................................................................................................................................................................................. 2

2. Activités ...................................................................................................................................................................................... 2

3. Equipe .......................................................................................................................................................................................... 2

II. ORGANISATION DU STAGE ..................................................................................................................................... 3

III. ANALYSE DE L ‘EXISTANT .................................................................................................................................. 4

1. Architecture du site existant .............................................................................................................................................. 4

2. Les points forts ........................................................................................................................................................................ 6

3. Les points faibles..................................................................................................................................................................... 6

IV. ANALYSE DES BESOINS ....................................................................................................................................... 7

1. Choix d’une collectivité partenaire de l’étude ............................................................................................................ 7

2. SIG de gestion d’eau potable .............................................................................................................................................. 8

3. Les composantes du SIG d’eau .......................................................................................................................................... 9

a) Les organes de réseaux dans un SIG .......................................................................................................................... 9

b) Les couches de localisation ......................................................................................................................................... 12

c) Les autres entités gérées dans un SIG de réseaux AEP ................................................................................... 13

4. Les outils à intégrer dans la nouvelle application .................................................................................................. 13

V. ARCHITECTURE DE L’APPLICATION ................................................................................................................ 16

1. Choix d’un serveur cartographique .............................................................................................................................. 16

2. Choix d’une application cliente ...................................................................................................................................... 17

3. Framework CMS (Content Management System) .................................................................................................. 17

VI. MODELISATION DE L’APPLICATION............................................................................................................ 18

1. Réalisation d’une maquette ............................................................................................................................................. 18

2. Diagrammes UML de fonctionnements ...................................................................................................................... 18

a) Diagramme des cas d’utilisation ............................................................................................................................... 18

b) Diagramme des activités .............................................................................................................................................. 20

3. Le modèle conceptuel de données ................................................................................................................................ 23

VII. PROTOTYPAGE DE L’APPLICATION............................................................................................................ 24

1. Installation du serveur cartographique...................................................................................................................... 24

2. Création de la base de données ...................................................................................................................................... 24

3. Configuration de GeoServer ............................................................................................................................................ 25

a) Créer un Espace de travail en lui attribuant un nom et une URI. ............................................................... 25

b) Créer un entrepôt de données dans l’espace de travail. ................................................................................. 25

c) La publication des WMS ............................................................................................................................................... 26

4. Gestion des styles d’affichage ......................................................................................................................................... 26

5. Configuration du client cartographique ..................................................................................................................... 28

6. Gestion des cas d’utilisation ............................................................................................................................................ 29

7. Gestion des fuites ................................................................................................................................................................. 29

8. L’ajout de photos .................................................................................................................................................................. 30

9. Affichage des données attributaires ............................................................................................................................ 30

10. Affichage des images dans un pop-up .................................................................................................................... 31

11. Sécurité des données ..................................................................................................................................................... 32

VIII. RETOUR D’EXPERIENCE .................................................................................................................................. 34

1. Modélisation de la base de données ............................................................................................................................ 34

2. Adaptation de l’application sur un Smartphone ..................................................................................................... 34

3. Quelques améliorations possibles ................................................................................................................................ 35

Conclusion ......................................................................................................................................................................... 36

Glossaire ............................................................................................................................................................................ 37

Table des figures ............................................................................................................................................................. 37

Blogs et forums d’entraide .......................................................................................................................................... 38

Documentation (API) .................................................................................................................................................... 38

Table des annexes .......................................................................................................................................................... 38

Page 1 sur 38

Introduction

Les réseaux d’eaux constituent une part importante du patrimoine d’une collectivité. Ces réseaux sont enterrés et bénéficient d’une perpétuelle évolution grâce à de nouvelles extensions ou des changements de réseaux anciens. L’optimisation de l’exploitation des réseaux d’eau passe par la mise en place d’un SIG. En effet, le SIG est un outil indispensable à la connaissance du réseau car il permet de connaitre la position de conduites et de tous les organes réseaux par la cartographie informatisée. L’analyse des données attributaires d’un SIG permet une meilleure planification des travaux de renouvellement des conduites. L’objectif de bdEe est donc de mettre à disposition des collectivités territoriale et de tout public avisé un outil permettant le partage des données géographiques et attributaires collectées à travers les missions terrain qu’il effectue. Dans les années deux mille, le cabinet s’est doté d’une plateforme WebSIG. A l’époque, cette plateforme « révolutionnaire » permet l’affichage des données géographiques et quelques requêtes attributaires sur ces données. L’application fonctionne grâce à Mapserver qui est le premier serveur cartographique du monde libre. Avec l’évolution fulgurante des années 2010 dans le monde des logiciels libres, l’application WebSIG de BDEE parait désuète aujourd’hui. L’objectif du présent stage intitulé: “Prototypage d'une application WebMapping de Gestion de

Réseaux d'eaux et d'assainissement” est d’analyser les différentes solutions actuelles pour mettre en place une application sécurisée, facile à utiliser et offrant plus de fonctionnalités. L’application prototypée est destinée en priorité aux collectivités gérant un réseau d’eau potable. Elle peut toutefois être adaptée pour les réseaux d’assainissement. La structure de la base de données peut être élargie pour prendre en charge la gestion de l’ensemble des données d’une collectivité. Cette application est un outil de travail pour les exploitants de réseau mais aussi un outil de communication qui peut être utilisé pour mieux gérer les interventions sur les casses de réseaux

Page 2 sur 38

I. PRESENTATION DE L’ORGANISATION D’ACCUEIL

1. Historique

L’activité de Boubée Dupont Eau et Environnement (bdEe) a débuté en 1988 à l’initiative de Madame Nicole BOUBEE-DUPONT, Ingénieur Agrégé INSA en Génie Civil et Hydraulique qui s’est installée en tant qu’Ingénieur libéral. En 2005 le bureau bdEe se restructure et prend la forme d’une SARL dont le siège est situé au 9 rue Caussade à Séméac, Département des Hautes Pyrénées. L’actuel gérant de bdEe est Mr Yvain BOUBEE.

2. Activités

L’activité principale de bdEe est la maitrise d’œuvre sur les projets hydrauliques (eau potable, assainissement). Les activités de bdEe se sont diversifiées depuis quelques années notamment dans le domaine de la VRD, et du SIG de réseaux. bdEe a réalisé plusieurs projets dans les régions Midi-Pyrénées et Aquitaine et s’exporte aujourd’hui vers l’international.

3. Equipe

L’équipe est constituée de neuf salariés dont un à temps partiel. Nom Fonction

Mme Nicole BOUBEE-DUPONT Ingénieur consultante et Chef de projet

Mr Yvain BOUBEE Ingénieur hydraulique, Topographie, gérant

Mme Marie ASSIBAT Assistante de Direction

Mme Anne CHANEAC Ingénieur Génie des procédés et environnement

Mr Jordan ALAIN Ingénieur

Mme Aurélie CIEUTAT Ingénieur Génie Civil et Travaux Publics

Mr Nicolas PEYTA Technicien Génie de l’Eau et VRD

Mr Gbati Batame TAFAMBA-DABOU Technicien SIG

Mr Alain HERNANDEZ Conducteur de travaux (temps partiel)

Page 3 sur 38

II. ORGANISATION DU STAGE

Le stage s’est déroulé au siège de bdEe. Un poste de travail a été créé et a été dédié exclusivement aux travaux de mon stage. Planning du stage Le stage a commencé le 1er Mars 2013 pour une durée de quatre mois. Dès le début de mon stage, ma première tâche à consisté à l’agencement d’un planning prévisionnel. Le planning proposé a été validé par Mr Yvain BOUBEE. Ce planning a été conçu avec le logiciel de gestion de projet Gantt Project téléchargé gratuitement sur internet.

PLANNING DES TACHES

TACHE DATE DE DEBUT DUREE (Jours) DATE DE FIN

ANALYSE DE L'EXISTANT 04/03/2013 4 08/03/2013

ANALYSE DES BESOINS 11/03/2013 4 15/03/2013

ARCHITECTURE DE L'APPLICATION 18/03/2013 11 29/03/2013

MODELISATION DE L'APPLICATION 01/04/2013 4 05/04/2013

PROTOTYPAGE DE L'APPLICATION 08/04/2013 39 17/05/2013

TEST DU PROTOTYPE 20/05/2013 8 28/05/2013

RETOUR D'EXPERIENCE ET CORRECTION DES ERREURS 29/05/2013 22 20/06/2013

MISE EN FORME DU RAPPORT DE FIN DE STAGE 21/06/2013 6 27/06/2013

Tableau 1: planning des tâches

EXTRAIT DU DIAGRAMME DE GANT

Figure 1 Extrait diagramme de Gant

Trois rencontres ont été programmées avec l’enseignant tuteur Mr Laurent JEGOU, afin de faire le point sur d’éventuelles difficultés techniques. Des séances de travail hebdomadaires ont été programmées avec Mr Yvain BOUBEE pour faire le point sur l’état d’avancement du projet. La fin du projet a été fixée au 28 juin 2013.

Page 4 sur 38

III. ANALYSE DE L ‘EXISTANT

1. Architecture du site existant

Le WebSIG actuel est accessible au travers d’un login et d’un mot de passe. Il a été conçu dans les années deux mille cinq et fonctionne grâce à Mapserver.

Figure 2 : architecture de l’application existante

Dans cette configuration, les shp sont insérés dans les Layers. Le style d’affichage des données se configure dans les Layers. Les Layers sont incorporés dans un fichier de configuration appelé : « Mapfile ». Le « Mapfile » contient toutes les informations indispensables à l’affichage de la carte notamment :

les dimensions de la carte, l’unité, le système de projection, l’étendue de la carte, le chemin d’accès aux Layers.

Page 5 sur 38

Extrait de Mapfile

MAP NAME "Sauvagnon" SIZE 650 500 IMAGECOLOR 255 255 255 IMAGETYPE "png24" UNITS METERS STATUS on SHAPEPATH "../../../media/mapserver/Sauvagnon/shp/" SYMBOLSET "../../../media/mapserver/symb/symboles.txt" #Projection Lambert III carto EXTENT 378600 3125600 380100 3126600 PROJECTION "init=epsg:27573" #Lambert III carto END WEB TEMPLATE "../../../media/mapserver/Sauvagnon/Map_Sauvagnon.htm" IMAGEPATH "../../../media/mapserver/tmp/" IMAGEURL "../../../media/mapserver/tmp/" HEADER "../../../media/mapserver/templates/Q_Header_Sau.htm" FOOTER "../../../media/mapserver/templates/Q_Footer.htm" #ERROR "../../../media/mapserver/templates/" END #-------Echelle graphique--------------------------- SCALEBAR IMAGECOLOR 255 255 255 OUTLINECOLOR 0 0 0 LABEL TYPE BITMAP COLOR 0 0 0 SIZE TINY END STYLE 0 SIZE 200 2 COLOR 0 0 0 UNITS meters INTERVALS 4 TRANSPARENT false STATUS embed POSITION lr END #-------Carte pour nquery--------------------------- QUERYMAP SIZE 650 500 STATUS ON STYLE HILITE COLOR 255 0 255 END #-------Definition Calques-------------------------- INCLUDE "../../../media/mapserver/Sauvagnon/Layers/IGN.lyr" INCLUDE "../../../media/mapserver/Sauvagnon/Layers/LC.lyr" INCLUDE "../../../media/mapserver/Sauvagnon/Layers/Ortho.lyr" INCLUDE "../../../media/mapserver/Sauvagnon/Layers/Parcellaire.lyr" INCLUDE "../../../media/mapserver/Sauvagnon/Layers/ConduitTransit.lyr" INCLUDE "../../../media/mapserver/Sauvagnon/Layers/ConduitDistribution.lyr" INCLUDE "../../../media/mapserver/Sauvagnon/Layers/NoeudsTransit.lyr" IEND #Map

Page 6 sur 38

La carte est diffusée par un fichier html qui définit la mise en forme des différents éléments du site : l’emplacement de la carte, les modalités de zoom, l’emplacement de la légende.

Figure 3: impression d’écran du site existant

2. Les points forts

la sécurisation de l’accès aux données, la possibilité d'afficher les données attributaires par un système de requête au clic sur les objets, la possibilité de choisir les entités à afficher.

3. Les points faibles

le souci majeur de l’application dans son état actuel est que la navigation n’est pas optimisée ; les points de déplacements (petits triangles noirs sur la figure ci-dessus) n’ont pas été bien configurés ; l’outil de navigation « PAN » ne fonctionne pas de façon optimale;

l’absence des outils tels que les outils de mesure de distances ou d’impression ne favorise pas l’utilisation du site par des techniciens qui ont plus besoin de précision ;

l’affichage de la carte n’est pas optimisé ; la carte occupe seulement le quart de l’écran. Enfin, le site n’a pas été mis à jour depuis son lancement. De ce fait, son graphisme nécessite une amélioration.

Page 7 sur 38

IV. ANALYSE DES BESOINS

1. Choix d’une collectivité partenaire de l’étude L’objectif de bdEe étant de développer une application adaptée aux besoins en gestion des réseaux d’alimentation en eau potable (AEP), nous avons décidé ensemble, avec mon responsable de stage Mr BOUBEE-DUPONT, de choisir une collectivité en guise de partenaire dans le développement du prototype. Apres analyse des possibilités dont nous disposions, notre choix s’est porté sur le Syndicat d’Alimentation en Eau Potable Adour Coteaux (SIAEP ADOUR COTEAUX). Ce choix a été motivé par le fait que le SIAEP ADOUR COTEAUX dispose d’un SIG à jour ; de ce fait la phase de collecte des données s’annonce ainsi facilitée. Par ailleurs, les agents du SIAEP ADOUR COTEAUX accordent un intérêt certain aux nouvelles technologies et semble par conséquent particulièrement intéressés par ce nouvel outil Enfin, la proximité géographique du siège du SIAEP ADOUR COTEAUX et du siège de bdEe permet de se rencontrer plus facilement pour des séances de travail. Le SIAEP ADOUR COTEAUX gère un réseau de 203km alimentant 9041 abonnés répartis sur 12 communes. Le siège du SIAEP-ADCTX est situé au 9 av François Mitterrand, 65600 à SEMEAC.

Figure 4: communes du SIAEP ADCTX

La définition des objectifs de la nouvelle application a été faite dans un premier temps en interne avec mon responsable de stage Mr Yvain BOUBEE.

Page 8 sur 38

Dans un second temps, les résultats de cette première phase de travail ont été soumis à l’appréciation des techniciens du SIAEP ADOUR COTEAUX. Cette première séance de travail nous a permis d’adopter la démarche décrite ci-après afin d’établir une liste de fonctionnalités à doter à la nouvelle application. Nous avons pensé qu’il était indispensable de comprendre dans un premier temps les objectifs d’un SIG de gestions d’eau, et, dans un second temps, d’identifier toutes les composantes d’un réseau AEP ainsi que leurs attributs dans un SIG, avant de définir les outils à intégrer dans la future application.

2. SIG de gestion d’eau potable

Il convient ici de rappeler que l’eau n’est pas un bien intarissable et que la tendance actuelle pousse vers un renforcement des exigences en matière « d’économie d’eau ». La production de l’eau potable passe par quatre étapes principales que sont le pompage de l’eau brute au niveau des ressources superficielles ou souterraines, le traitement le stockage et enfin la distribution à destination des abonnés.

Figure 5: Etapes de production de l’eau ; Source : http://www.cg66.fr/376-l-eau.htm

Un réseau d’eau est donc composé de plusieurs organes jouant les rôles de transporteur et de régulateur de l’eau brute jusqu’au consommateur final. Les réseaux d’eaux et d’assainissement constituent un patrimoine intergénérationnel dont la durée de vie s’étale sur plusieurs années avec un retour sur investissement de long terme. La connaissance de l’état des réseaux d’eau est souvent imparfaite du fait de leur inaccessibilité. On note souvent un manque d’informations sur l’âge des conduites, la nature des matériaux et la position exacte du réseau sur l’assiette urbaine. Le SIG permet de palier à l’insuffisance de connaissance des réseaux AEP. Grace à la cartographie de précision et la collecte des données attributaires il est possible de mettre à jour le réseau et d’instaurer une véritable politique de gestion patrimoniale des infrastructures. L’analyse des données du SIG permet également non seulement, une meilleure planification des travaux d’extension et de renouvellement de réseaux, mais aussi, une amélioration des conditions d’intervention en cas de dysfonctionnements.

Page 9 sur 38

3. Les composantes du SIG d’eau Un SIG de gestion d’eau Potable est constitué de deux types d’entités : les organes du réseau et les couches de localisation.

a) Les organes de réseaux dans un SIG Réservoirs

Ils assurent la fonction de stockage de l’eau. Installés de préférence en hauteur, ils favorisent la redistribution de l’eau. L’eau est ainsi distribuée gravitairement depuis les réservoirs ce qui permet d’alléger le fonctionnement des pompes. Ils sont représentés par des points dans un SIG. Les principaux attributs d’un réservoir sont énumérés dans le tableau suivant:

Libellé Description Valeurs par défaut

Num_reserv Numéros d’identification

Nom

Type Type de réservoir - Enterré - Semi enterré - Sur tour

Côte_Sol Altitude au niveau du TN en m

Cote_Radier Altitude au niveau du radier en m

Cote_Tp Altitude au niveau du Trop-plein en m

Volume Volume du réservoir en m3

Année Année de construction

Photos

détail Numéros du plan de détail

Conduites

Elles jouent essentiellement un rôle de transit et ou de distribution. Les conduites transportent l’eau de la station de pompage vers un réservoir (conduites d’adduction) ou d’un du réservoir vers les abonnés (conduites de distribution). Les conduites sont représentés dans un SIG sous forme de lignes ; les lignes doivent être jointives afin d’assurer la continuité du réseau. Les principales caractéristiques des conduites d’AEP sont reprises dans le tableau ci-dessous :

Libellé Description Valeurs par défaut

num_cond Numéros d’identification

Type Type de la conduite - Conduite de distribution - Conduites d’adduction

Matériaux -Fonte - Polyetylène (PEHD) - PVC - Acier - Amiante ciment

D N Diamètre nominal

DE Diamètre extérieur

Année Année de pose

Longueur NBA Nombre d’abonnée sur le tronçon

N_d Nœud de départ N_a Nœud d’arrivé

Page 10 sur 38

Vannes

Posées sur les conduites, elles permettent de réguler ou d’interrompre la circulation d’eau. Ce sont des entités ponctuelles :

Libellé Description Valeurs par défaut

Num_vannes Numéros d’identification

Types Type de la vanne - Vannes spéciales, Vanne à opercule ou à passage direct - Vanne à clapet ou robinet à soupape - Vanne à boule ou à boisseau sphérique - Vanne à boisseau conique - Vanne papillon - Vanne guillotine - Vanne à piston - Vanne à cage - Vanne à membrane - Autres

Nature C’est le rôle que joue la vanne dans le fonctionnement global du réseau.

- Vanne de sectionnement - Vanne d’antenne - Vanne de poteau incendie

DN Diamètre Nominal

Etat - Ouverte - Fermée

Raccordement - à brides - à Visses - soudé

Actionnement - Manuel - Motorisé

E_BAC Etat de la bouche à clé - bon - mauvais

V_BAC Visibilité de la bouche à clé - Visible - Invisible

détail Numéros du plan de détail

Photos

Observations

Vidanges

Ce sont des vannes placées au point bas ou en bout de réseau. Elles servent à vider l’eau stagnante dans une conduite afin d’améliorer la qualité de l’eau. Elles ont les mêmes caractéristiques que les vannes.

Ventouses

Les ventouses servent à libérer l’air emprisonner dans un réseau d’eau et garantisse ainsi le débit. On les place au point haut sur le réseau. Elles sont représentées dans un SIG par des points.

Libellé Description Valeurs par défaut

Num_ven Numéros d’identification Type Type de la ventouse - Simple

- Automatique DN Diamètre nominal Photo année Année de pose détail Numéros des plans de détail

Page 11 sur 38

Hydrostabs

Ils servent à transférer les excédents d’un réseau (amont) vers un réseau (aval) à plus faible pression, vers un réservoir ou vers une décharge, dès lors que la pression amont dépasse une valeur prédéterminée, quelles que soient les variations de la pression aval et du débit transféré.

Libellé Description Valeurs par défaut

num_hydro Numéros d’identification

Type - Amont - Aval - Amont-aval

DN Diamètre nominal

Année Année de pose

Photo Liens vers les photos

Hydrants

« Les hydrants, couramment appelés bouche d'incendie ou poteau d'incendie, sont des dispositifs de lutte

contre l'incendie mis en place par les communes, ou les entreprises privées (industrie, établissements recevant du public, sites militaires), dans leurs enceintes » source : Wikipédia

Libellé Description Valeurs par défaut

Numéro Numéro d’identification

Type - Poteaux d’incendie - Bouches d’incendie - Les points d’eau incendie - Points d’eau naturels ou artificiels (cours d’eau, mare, étang, etc.) ; - Points de puisage (puisard relié à un plan d’eau ou cours d’eau) ; - Réserves ou citernes (enterrées ou aériennes)

Débit

Etat - bon - mauvais

année Année de pose

Compteurs Réseau

Ils peuvent être installés soit en entrée de réservoir, soit au départ de chaque branche du réseau. Ils servent à quantifier le volume d’eau d’un secteur. Une brusque variation de volume d’eau au niveau d’un compteur de réseau est souvent le signe de la présence d’une fuite sur le secteur concerné.

Libellé Description Valeurs par défaut

Num_cr Numéro d’identification

Marque

Classe - A - B - C

DN Diamètre nominal

Année Année de pose

Page 12 sur 38

Compteurs Abonnés

Ils servent à quantifier le volume d’eau consommée par un abonné. Ils sont installés sur les branchements.

Libellé Description Valeurs par défaut

Numéro Numéro d’identification

Type Abonné sensible Cimetière Commerce Domestique Ecole Espace vert, Jardin Fontaine Hôtel, restaurant Industrie Médical Résidence Équipement sportif

Marque

Classe - A - B - C

DN Diamètre nominal

Année Année de pose

Outre les organes de réseaux, le SIG de gestion de l’eau intègre également des couches de localisation.

b) Les couches de localisation Les données de l’IGN

Ce sont essentiellement les couches telles que les parcelles cadastrales, le bâti les limites de commune, etc... La liste des couches disponible auprès de l’IGN est accessible à ce lien : http://professionnels.ign.fr/.

Les Secteurs Hydrauliques

Ils sont issus de la division du territoire d’une collectivité en plusieurs parties en respectant une cohérence hydraulique. Leur principale fonction est de favoriser la diminution des pertes sur réseau en pointant les volumes d’eau à l’entrée et sortie de chaque secteur.

Libellé Description Valeurs par défaut

Num_secteur Numéro d’identification

Nom

Service Nom du réservoir qui alimente le secteur

Page 13 sur 38

c) Les autres entités gérées dans un SIG de réseaux AEP

Abonnés Les abonnées sont les consommateurs finaux de l’eau.

Libellé Description Valeurs par défaut

Nom Nom de l’abonné

Date_d Date du début du contrat

Date_f Date de fin du contrat

Adresse Adresse de facturation ; elle peut etre différente de l’adresse du compteur

Conso Consommation de référence ;

Les Fuites

La réduction des fuites sur réseaux constitue l’une des activités principales des exploitants. La collecte des informations sur les fuites permettra au syndicat de planifier le remplacement des conduites.

Libellé Description Valeurs par défaut

Num_tronçon Numéro du troncons concerné

Date_d Date de découverte de la fuite

Importance Importance de la fuite - Mineur - Moyenne - Elevé

Constat - Interne - Externe

Etat - Réparé - Non réparé

Date_r Date de la réparation

Photos _f Numerus de photo de la fuite

Photo_r Photo de la réparation

4. Les outils à intégrer dans la nouvelle application

Une séance de travail destinée à : recueillir l’avis des futurs utilisateurs de l’application, faire le point sur la liste des entités à intégrer ainsi que les fonctionnalités attendues par des exploitants de réseau, a été organisée avec les agents du SIAEP ADOUR COTEAUX. Cette séance de travail a permis de noter six préoccupations devant être prises en compte au cour de la mise en place de l’application WebSIG.

Page 14 sur 38

La rapidité d’affichage du site

Le site actuel met au moins deux minutes pour s’afficher et ce délai d’attente est « insupportable ». Pour ne pas attendre trop longtemps, les agents du SIAEP ADOUR COTEAUX préfèrent utiliser le logiciel AUTOCAD qui est un logiciel de DAO même si ce logiciel ne leur permet pas d’accéder aux données attributaires. La gestion des photos des ouvrages ou des détails

La nouvelle application devra offrir la possibilité de gérer les photos prises sur le réseau (casse sur réseaux, extension de réseaux, installation de nouveaux équipements). La gestion des photos est une grande attente de la part des agents du SIAEP ADOUR COTEAUX car les clichés pris actuellement sont simplement enregistrés dans un dossier et il leur arrive fréquemment de ne plus retrouver soit le chemin d’accès, soit la photo d’un événement. La gestion des photos par une base de données associée à un fond cartographique indiquant l’emplacement de celles-ci serait indéniablement une avancée dans leur travail.

L’édition des données

La possibilité de modifier les données, d’ajouter de nouveaux objets ou d’en supprimer à partir de l’application a été également évoquée pendant cette séance de travail. Sans être une préoccupation urgente, cet outil permettrait d’avoir une bonne base pour la mise à jour des données. Le fonctionnement du site sur Smartphone

L’objectif du syndicat est de doter les agents qui interviennent sur le terrain d’un terminal leur permettant d’accéder au site depuis leur chantier. La nouvelle application devra donc être facilement utilisable sur Smartphone.

Le Recueil des données sur les fuites

Selon le Ministère de l’écologie et du développement durable, on enregistre en moyenne 25% de perte d’eau sur un réseau (http://www.developpement-durable.gouv.fr/La-diminution-des-fuites-dans-

les.html). Ces fuites interviennent le plus souvent en hiver. Faire contribuer la population dans son ensemble permettrait de réduire les temps d’intervention, ce qui aurait un impact positif et non négligeable sur les quantités d’eau perdues. Les données ainsi collectées par le WEBSIG seraient aussi d’une grande utilité dans les projets de renouvellement de conduites. Enfin le développement d’un outil de collecte des données sur les fuites permettrait également de « désengorger » le standard téléphonique. Assurer la confidentialité des données

Les données gérées par le SIAEP ADOUR COTEAUX sont en partie confidentielles : par exemple, le nom des abonnés ou encore leur consommation d’eau ne peuvent être accessibles par tout un chacun. Nous avons donc décidé, d’un commun accord avec les membres du SIAEP ADOUR COTEAUX, que certaines couches, comme le cadastre ou les conduites, seraient accessibles en mode « consultation grand public » et que le reste des couches serait exclusivement accessible au personnel du syndicat. Il en est de même pour les outils d’édition qui devraient être réservés uniquement aux utilisateurs avertis. Suite à cette séance de travail, un tableau récapitulatif de tous les cas d’utilisation de l’application a pu être établi.

Page 15 sur 38

TABLEAU RECAPITULATIF DES CAS DE REALISATION Fonctionnalités Accessibilité

Visualisation des éléments équipements hydrauliques

Tout public

- Signalement de nouvelles fuites - Visualisation des Fuites signalées

Tout public

Visualisation et édition de toutes les fuites

Agents du syndicat autorisés

Édition des Équipement de réseaux

Agents du syndicat autorisés

Visualisation et Édition des données de gestion du syndicat

Agents du syndicat autorisés

Visualisation et Édition des données relative aux abonnés

Agents du syndicat autorisés

Statistiques globales et détaillées sur le syndicat

Agents du syndicat autorisés

impression de plan de réseaux

Tout public

Requêtes sur les données attributaires

Agents du syndicat autorisés

Page 16 sur 38

V. ARCHITECTURE DE L’APPLICATION

Après l’analyse des besoins, il s’avère que la mise en place d’un serveur cartographique s’impose. En effet, seul celui-ci est en mesure de produire des données éditables online.

1. Choix d’un serveur cartographique

Nous avons étudié les forces et faiblesses des principaux serveurs cartographiques libres afin de déterminer celui qui correspondrait au mieux aux besoins de l’application.

TABLEAU RECAPITULATIF DES SERVEURS CARTOGRAPHIQUES Serveur Points forts Points faibles Formats

Mapserver • Grande richesse fonctionnelle

• Grande maturité

• Forte communauté

• Rendu cartographique de qualité moyenne

• Pas d’interface d’administration

WMS WFS WFS

GeoServer • Grande richesse fonctionnelle • Grande maturité • Forte communauté • Effort de standardisation • interfaces d’administration Utilisation des SLD

• Environnement de développement Java

WMS WFS WFS-T

Qgis Server • Richesse fonctionnelle • Fonctionnalités et environnement graphique de QGIS Desktop

(édition de la symbologie/légende)

Nombre limités de formats supporté • Faible performance (Serveur construit sur une architecture

Desktop)

WMS WFS WFS-T

Le WFS-T (Web Feature Service Transaction) est le seul format offrant les possibilités d’édition online. Nous avons donc écarté le choix de Mapserver car celui-ci ne génère pas directement du WFST, à moins d’être associé à Tinyows. GeoServer et Qgis Server génèrent du WFS-T et offrent une interface d’utilisation conviviale ne nécessitant pas beaucoup de connaissances en programmation. Cependant, notre choix définitif s’est porté sur GeoServer, dans la mesure où la documentation est assez riche avec des exemples ce qui devrait nous aider dans la phase de prototypage. La compatibilité entre GeoWebcache que nous comptons utiliser pour accélérer la vitesse d’affichage des WFS et GeoServer a été aussi un point important dans le choix définitif du serveur.

Page 17 sur 38

2. Choix d’une application cliente

Les applications clientes sont des bibliothèques JavaScript qui permettent de : gérer le chargement des couches produites par le serveur cartographique (WFS, WFST, WMS, KML), afficher les données d’une base de données géo spatiales (PostGis) ou de simples couches (SHP).

Le client cartographique gère également l’envoi des données aux serveurs et les interactions HOMME - MACHINE (Zoom sur une couche, déplacement, mesure de longueur). Le choix du client cartographique est d’autant plus important qu’il représente le lien entre l’utilisateur et le serveur.

Il existe de nos jours plusieurs applications clientes. Nous avons décidé d’analyser les principales d’entre elles afin de sélectionner la plus adaptée à nos besoins. nom points forts points faibles

Leaflet - Bonne documentation - Présentation graphique harmonieuse - Légèreté

- absence de possibilité de filtrage par les attributs

OpenLayers - Bonne documentation - Présentation graphique harmonieuse - Beaucoup de fonctionnalités - Grande popularité

- bibliothèque lourde

GeoExt - Bonne documentation - Association d’Ext et OpenLayers - Interface riche - Bonne documentation

- bibliothèque lourde

Notre choix de bibliothèque se porte sur GeoExt. Cette dernière hérite un peu de la lourdeur d’OpenLayers mais, nous l’avons choisie car elle permet de réaliser facilement des tris sur les attributs, ce qui correspond le mieux aux fonctionnalités de requêtes attributaires que nous comptons développer dans notre application. Les outils d’OpenLayers peuvent y être directement intégrés.

3. Framework CMS (Content Management System)

Les CMS ou SGC (Système de Gestion de Contenu) permettent de disposer de feuilles de style CSS prêtes pour l’emploi et facilement adaptables. Nous utiliserons un Framework CSS principalement pour soigner l’affichage du Site web. Sans avoir étudié plus spécifiquement toutes les possibilités dont nous disposons en la matière, nous avons décidé d’utiliser twitter bootstrap (http://twitter.github.io/bootstrap/) et Jquery (http://jquery.com/). Ces deux applications sont largement suffisantes pour les besoins de notre site. En effet, nous comptons utiliser le CSS responsive de bootstrap pour rendre le site directement utilisable directement sur Smartphone.

L’architecture que nous avons proposée a été validée par le responsable de stage, Mr Yvain BOUBEE-DUPONT, ainsi que par l’enseignant tuteur Mr Laurent JEGOU.

Figure 6: Architecture de l’application

Page 18 sur 38

VI. MODELISATION DE L’APPLICATION

1. Réalisation d’une maquette

Figure 7: Maquette de l’application

Cette maquette a été inspirée de GeoExplorer. Nous y avons ajouté un bouton pour signaler une fuite, un lien pour se connecter et un entête comportant les logos du SIAEP ADOUR COTEAUX et de bdEe. La maquette a été réalisée avec le logiciel GIMP, logiciel de traitement d’image libre

2. Diagrammes UML de fonctionnements

L’UML (Unified Modeling Language) est un langage de programmation qui permet de modéliser les interactions entre les classes d’une application grâce à des diagrammes. Pour mieux penser les étapes de fonctionnement de l’application, nous avons d’abords réalisés « le diagramme des cas d’utilisation » puis « les diagrammes d’activités ».

a) Diagramme des cas d’utilisation

Le diagramme des cas d’utilisation donne une vision globale des fonctionnalités accessibles à tous les utilisateurs potentiels de l’application. Ils résultent des cas d’utilisation identifiés lors de la phase d’analyse des besoins. Nous distinguons cinq types d’utilisateurs :

Page 19 sur 38

L’utilisateur nommé « tout public », représentant toute personne connectée L’utilisateur appelé « tous les agents du syndicat» qui représente les utilisateurs inscrits par l’administrateur. Ces utilisateurs disposent d’un mot de passe et d’un nom d’utilisateur grâce auxquels ils peuvent se connecter à leur session d’utilisation. Ils ont la possibilité de consulter toutes les données mais, ne peuvent les modifier.

L’utilisateur nommé « les agents du syndicat autorisés » concerne les utilisateurs inscrits par l’administrateur mais, avec un statut qui leur permettant de modifier les données. Ils doivent être sensibilisés sur les méthodes d’éditions utilisées, sur le type et le format des données attributaires, et sur le fait qu’ils agissent directement sur la base de données ; L’utilisateur « administrateur local » s’adresse au responsable du syndicat. Il peut ajouter ou désactiver les utilisateurs ; il peut également leur changer de statut (simple visualisation ou possibilité d’édition) ; Le dernier utilisateur est « l’Administrateur bdEe». Il gère la base de données et le serveur. Il veille au bon fonctionnement de l’application et assure la mise à jour fréquente des données.

DIAGRAMME DES CAS D’UTILISATION

Figure 8: Diagramme des cas d’utilisation

Page 20 sur 38

b) Diagramme des activités

Le diagramme des activités permet de modéliser le déroulement d’un cas d’utilisation. Le diagramme ci-dessous, représentant la page d’accueil du site, décrit l’enchainement de trois actions possibles :

l’action « Navigation », l’action « Imprimer un plan », l’action « Signaler une fuite ».

Figure 9: Diagramme des activités (utilisateur tout public)

Page 21 sur 38

Les actions suivantes nécessitent une connexion par un mot de passe un login : l’édition des WFS-T (modification, suppression, ajout), la recherche de données par requêtes attributaires.

Figure 10: Diagramme des activités (utilisateur autorisé)

Page 22 sur 38

le tableau de bord Outre l’onglet cartographique, nous avons estimé qu’il était indispensable d’ajouter un onglet tableau de bord à l’application. Cet onglet permet d’obtenir des tableaux récapitulatifs ou des statistiques sur l’ensemble des couches disponibles dans la base de données. On peut ainsi connaître, par exemple, le nombre exact de vannes sur un secteur hydraulique, ou encore le linéaire de réseau.

Figure 11: Diagramme des activités (tableau de bord)

Page 23 sur 38

3. Le modèle conceptuel de données

« Le modèle conceptuel de données (MCD) a pour but d'écrire de façon formelle les données qui seront utilisées par le système d'information. Il s'agit donc d'une représentation des données, facilement compréhensible, permettant de décrire le système d'information à l'aide d'entités » source : http://www.commentcamarche.net.

Figure 12: MCD simplifié

Le MCD ci-dessus est une illustration simplifiée du MCD réalisé pour le prototype de l’application. Il montre les relations existant entre l’ensemble des données. Les ouvrages (forages, stations de traitement, stations de pompage) alimentent un ou plusieurs réservoirs ; Parallèlement, un réservoir peut avoir plusieurs sources d’alimentation ce qui est matérialisé dans le MCD par la relation « Alimenter réservoir ». Les réservoirs jouent le rôle de stockage et alimentent les conduites ; une conduites peut être alimentée par plusieurs ouvrages en amont c’est la relation « Alimenter ». Les conduites servent à transporter l’eau des réservoirs vers les abonnés, un abonné est reçoit l’eau d’une conduite à la fois: c’est la relation « Distribuer ». Les organes (Vannes, Ventouse, Poteau incendie, stabilisateur, compteur réseaux) qui joue le rôle de régulateur sont posés sur les conduites. Enfin tous les éléments précités sont situés sur une unité territoriale c’est-à-dire sur une commune, et sur un secteur hydraulique). A partir de ce MCD nous avons généré un MLD. Voir en annexe 1 le MCD détaillé.

Page 24 sur 38

VII. PROTOTYPAGE DE L’APPLICATION

1. Installation du serveur cartographique D’un commun accord avec le Responsable du stage Mr Yvain BOUBEE, il a été décidé que l’ordinateur qui nous a été affecté pour le stage fera office de serveur provisoire. Nous y avons donc installé OpenGeo Suite. L’OpenGeo Suite est une association de plusieurs applications libres dont la documentation est accessible à partir de ce lien : http://opengeo.org/products/suite/register/. Nous avons fait ce choix car, c’est une solution « tout en un » , c’est-à-dire que sont installés en même temps GeoServer, le serveur cartographique, PostGis, la base données spatiales, et GeoWebcache qui permet de mettre en cache les WMS. L’OpenGeo Suite intègre également GeoExplorer, une application cliente permettant de visualiser directement les données d’un serveur local ou d’un serveur distant. Une fois téléchargée, l’installation de l’OpenGeo Suite est assez simple (un exécutable Windows).

OpenGeo Suite installe par défaut PostGis sur le port 5432 et GeoServer sur le port 8080. L’application cliente étant provisoirement hébergée par Alwaysdata, il a fallu ouvrir les ports 8080 et 5432 pour permettre la communication entre GeoExt et GeoServer d’une part, et l’accès de la base de données Postgresql/PostGis par les requêtes PHP d’autre part. Nous avons été contraints de faire appel aux informaticiens qui gèrent le réseau informatique du cabinet car, le poste de travail sur lequel GeoServer est installé faisant partie d’un réseau local connecté par un routeur, il fallait prendre des mesures de sécurité afin de protéger les autres ordinateurs du réseau d’une quelconque attaque. Nous avons également installé phpPgAdmin, une interface d’administration de Postgresql/PostGis, plus conviviale que pgAdmin , l’interface de gestion par défaut.

2. Création de la base de données

Le SIAEP ADOUR COTEAUX dispose des données au format SHP des conduites, organes et ouvrages du réseau, ainsi que des limites administratives. Ces données, collectées par bdEe en 2010, suite à l’arpentage du réseau et aux levés GPS, ne souffrent d’aucun défaut. Nous avons malgré tout pris soin d’effectuer des vérifications de topologie et épuré les tables en supprimant les informations jugées les moins pertinentes. Suite à cette vérification, les SHP ont été importés dans PostGis via le plugin PgShpLoader intégré à l’OpenGeo Suite. Le système de projection utilisé lors de l’import des SHP est le Google Mercator ou EPSG:900913 ; système de projection aussi utilisé par les WMS de Google. Il faut noter ici que l’opération d’import de données peut se faire également avec Qgis et aussi que les données auraient pu être importées dans leur système de projection natif car PostGis ou GeoServer sont en mesure de faire des projections, mais nous avons voulu optimiser les temps d’exécution de nos requêtes en mettant l’ensemble des données dans le même système de projection. Outres les données spatiales, les autres tables (les fuites, les utilisateurs etc..) ont été ajoutées à la base de données via l’interface d’administration de phpPgAdmin.

Page 25 sur 38

3. Configuration de GeoServer

L’interface d’administration web de GeoServer est accessible sur le serveur (en mode localhost) par le lien suivant : http://localhost:8080/geoserver/web. Cette interface permet de gérer assez facilement tous les paramètres de production de WMS. Un tutoriel détaillé de l’utilisation de l’interface web de GeoServer est disponible sur lien suivant: http://docs.geoserver.org/stable/en/user/webadmin/. Dès la première connexion il faut changer le nom d’utilisateur et le mot de passe. Le nom d’utilisateur et le mot de passe par défaut sont : « admin » et «geoserver ». Une fois les configurations de base effectuées, trois étapes sont à suivre pour publier les WMS.

a) Créer un Espace de travail en lui attribuant un nom et une URI.

Pour créer un espace de travail, il suffit de cliquer sur le bouton « Espaces de travail » dans la colonne gauche puis sur le bouton vert pour ajouter un nouvel espace de travail

b) Créer un entrepôt de données dans l’espace de travail.

Pour créer un entrepôt de données, il faut choisir le type de ressource (le type de données à publier). Dans notre cas, il s’agit de PostGis (PostGIS Database) ; on renseigne ensuite l’emplacement de la ressource ; pour une base de données PostGis, il faudra indiquer le nom (IP) du serveur hôte, son port d’écoute, le nom d’utilisateur et le mot de passe puis le nom de la base de données ; pour la publication d’un Shapefile, il suffira simplement d’indiquer le chemin d’accès au dossier dans lequel il se trouve. Dans notre cas, la base de données est sur le localhost (GeoServer et PostGis sont installés sur le même ordinateur), le port : 5432 est celui utilisé par défaut par Postgresql/PostGis et le nom de la base est « adctx ».

Page 26 sur 38

c) La publication des WMS

Après avoir créé l’entrepôt de données, il faut juste choisir la table à publier parmi la liste des tables présentes dans l’entrepôt de données, puis procéder au paramétrage d’affichage du WMS. La fenêtre de configuration des paramètres d’affichage comporte quatre onglets :

le premier onglet intitulé (Données) permet de donner un nom au WMS, de lui attribuer un système de projection et de calculer l’emprise de la couche. GeoServer reconnaît automatiquement le système de projection natif si celui-ci a été bien configuré dans la base de données,

le second onglet intitulé (Publication) permet de gérer les paramètres de publications du WMS, notamment le Style d’affichage de la couche,

le troisième onglet est intitulé (Dimension), le dernier onglet intitulé (Tile Caching) permet de mettre en cache des couches afin de rendre leur

l’affichage des WMS par l’application cliente plus rapide. L’outil « Tile Caching » est basé sur une implémentation de GeoWebCache. En effet GeoWebCache fonctionne comme un proxy entre le serveur cartographique et l’application cliente en sauvegardant les tuiles. A chaque requête de l’application cliente, GeoWebCache vérifie si les tuiles correspondant à la réponse à cette requête a déjà été existent ; si oui, elles sont envoyées à l’application cliente en réponse, dans ce cas la réponse est rapide, sinon, GeoWebCache enregistre la réponse de GeoServer pour une utilisation ultérieure. Les serveurs de Google Map fonctionnent sur le même principe.

4. Gestion des styles d’affichage Nous avons deux possibilités pour gérer la mise en forme des couches : la première possibilité est de la paramétrer au niveau du client cartographique (GeoExt) en JavaScript, la seconde de l’effectuer avec GeoServer. Notre choix s’est orienté vers la seconde solution car nous souhaitons effectuer le moins de tâches possibles coté client ; notre objectif final étant d’optimiser les temps d’affichage des WMS. Le SLD (Styled Layer Descriptor) est le langage qu’utilise GeoServer pour éditer la mise en forme des WMS. Le SLD « est un schéma XML indiqué par l’OGC (The Open Geospatial Consortium) afin de décrire le style des couches de carte. Il est capable de traiter des données vectorielles et Raster. Une utilisation typique des SLD est destinée aux WMS (Web Map Service) pour que ces derniers puissent interpréter efficacement une couche de donnée spécifique » source Wikipédia. La documentation sur l’utilisation du SLD par GeoServer est accessible ici : http://docs.geoserver.org/latest/en/user/styling/sld-cookbook/. GeoServer dispose d’un éditeur de SLD mais nous avons préféré importer le SLD préalablement édité par QGIS ou UDIG car nous trouvons cette solution plus rapide et plus simple. Nous avons constaté lors de nos différents tests que GeoServer affiche mieux le SLD de Udig, surtout les étiquettes des données, alors qu’il génère des erreurs avec certaines étiquettes de QGIS. Nous avons utilisé la charte graphique de bdEe dans la mise en forme des couches, ceci afin que les futures utilisateurs puissent les identifier sans difficultés. La technique utilisée est différente en fonction du type d’entité. La mise en forme des conduites, par exemple, a nécessité une discrétisation en fonction de la nature du matériau et du diamètre nominal de la conduite. La figure ci-après récapitule la charte graphique qu’utilise bdEe dans ses projets et dont nous nous sommes inspirés dans la mise en forme des entités de l’application.

Page 27 sur 38

Figure 13 Charte graphique de BDEE

Figure 14 extrait de SLD des vannes

Page 28 sur 38

5. Configuration du client cartographique Le client cartographique utilisé pour notre prototype est GXP. C’est une bibliothèque basée sur GeoExt. Il est utilisé par l’Opengeo, notamment dans l’application GeoExplorer. La documentation de GXP est accessible sur ce lien : http://gxp.opengeo.org/master/doc/, et on peut voir quelques exemples d’applications développé à partir de GXP à ce lien http://gxp.opengeo.org/master/examples/. Notre choix s’est orienté vers cette librairie car, les fonctionnalités d’édition, de requêtes attributaires ou d’impression que nous pensons mettre en place, y ont déjà été développées. Il ne reste plus qu’à les intégrer. L’extrait de code ci-après montre comment intégrer l’ensemble des outils d’édition (modification, suppression, ajout). Voir l’annexe n°2 pour le code complet.

On constate que la plus part des outils ont déjà été codés et sont facilement réutilisables. Mise en place d’un proxy

Les restrictions en matière de sécurité en JavaScript bloquent l’exécution des requêtes XMLHTTP sur un serveur distant. Les requêtes XMLHTTP permettent de récupérer toutes sortes de données ; dans notre cas, il s’agit de récupérer les WMS produits par GeoServer. La conséquence de ce blocage est le non-affichage des couches. Pour contourner ce problème il faut configurer un proxy. Nous avons passé pas moins d’une semaine à chercher la meilleure méthode pour mettre en place le proxy. Nous avons dans nos recherches trouvées deux solutions ; la première est de récupérer les données du serveur par un script PHP. Cette méthode est expliquée sur ce lien : http://khayer.wordpress.com/2010/07/04/solution-of-cross-domain-ajax-call-problem/. Les tests réalisés avec cette première méthode nous ont permis d’afficher les WMS de GeoServer cependant, l’utilisation des outils d’édition génère une erreur « Java null point exception ». Les requêtes attributaires sur les WMS ne donnent aucun résultat avec cette méthode. Il nous fallait dès lors trouver une autre alternative pour le bon fonctionnement de l’application. La seconde solution est l’utilisation du proxy d’OpenLayers disponible sur ce lien : http://svn.openlayers.org/trunk/openlayers/examples/proxy.cgi. L’utilisation de ce script nécessite préalablement l’installation de Python. Suite aux tests que nous avons réalisés, nous avons constaté que le fichier Proxy.cgi que fourni OpenLayers ne fonctionne qu’avec la version 2.7 de Python. L’étape suivant l’installation de Python est la configuration du proxy. Cette étape se déroule en quatre phases :

copier le fichier Proxy.cgi téléchargé, puis le coller dans le dossier cgi–bin d’apache. modifier la première ligne du script, en indiquant le chemin vers l’exécutable de Python. Dans notre

cas : « #!/usr/bin/env python » devient « #!C:/Python27/python.exe –u ». Il faut ensuite chercher la balise « allowedHosts », puis y ajouter l’adresse IP de l’ordinateur sur lequel

GeoServer est installé, On enregistre le fichier puis on redémarre l’ensemble des services d’apache.

La mise en place du proxy a permis de faire fonctionner correctement l’application. Il faut toutefois noter l’existence d’un bug avec l’hébergement gratuit d’Alwaysdata, ce qui nous a obligé à migrer le prototype sur un hébergement payant.

Page 29 sur 38

6. Gestion des cas d’utilisation Les utilisateurs qui se connectent avec leur email et leur mot de passe ont accès soit, aux fonctionnalités de visualisation et d’interrogation des données, soit à toutes les fonctionnalités, y compris l’édition. Le rôle des utilisateurs est géré côté client par un script en PHP qui détecte les variables de sessions et charge un type de carte, en fonction du rôle de l’utilisateur. Pour plus de détail, voir l’annexe n°4 le fichier header.php qui gère le chargement des cartes en fonction de la variable de session.

7. Gestion des fuites Le recueil de données sur les fuites est l’un des principaux objectifs que nous souhaitons assigner à l’application, car il devrait permettre de réduire le temps de réparation des fuites et de planifier le renouvellement de vieilles conduites (les tronçons sur lesquels on constate régulièrement des fuites doivent être remplacés en priorité). Nous avons développé un outil destiné au grand public, pour lui permettre de signaler tout incident sur le réseau, constaté chez eux ou sur la voie publique. Nous pensons que plus tôt la fuite est détectée, mieux est sa prise en charge. Le développement de cet outil a nécessité deux techniques :

le recueil de la longitude et de la latitude par la fonction getLonLatFromPixel d’OpenLayers. L’extrait de code ci-dessous montre la fonction pour récupérer les coordonnées.

la transformation des points en format PostGis puis l’insertion à la base de données. Les coordonnées récupérées à l’étape précédente sont, dans un premier temps transférées à un formulaire de saisie d’informations via une fancybox. Ce formulaire sert également à recueillir la description de la fuite, le contact de la personne qui la signale puis la date. L’ensemble des informations est intégré à PostGis grâce à une requête SQL en PHP, qui convertit la longitude et la latitude en géométrie reconnaissable par PostGis. Ci-dessous l’extrait de code montrant la requête SQL pour ajouter les données d’une fuite à la base de données.

Page 30 sur 38

Afin de vérifier l’exactitude des informations recueillies, nous avons ajouté un tableau nommé « Liste des

fuites signalées » dans l’onglet « tableau de bord ». Ce tableau permet de gérer les informations collectées. Lorsque les fuites signalées se sont avérées vraies, leur description est transférée dans une liste nommée : « fuites constatées », sinon, elles sont simplement archivées dans une autre table. Dans tous les cas, après les vérifications, effectuées par les agents du syndicat, la fuite signalée n’est plus affichée sur l’interface cartographique, ceci afin de ne pas surcharger l’interface cartographique de signalement de fuites avec celles qui ne sont plus d’actualité.

Figure 15: impression d’écran : fuites signalées

8. L’ajout de photos Les agents du syndicat prennent souvent des photos des travaux sur les conduites ou sur les organes de réseaux. Ces photos permettent d’avoir une précision sur la position exacte du réseau et de ses composants et sont d’une grande utilité dans l’exécution des futurs travaux. Eu égard à l’importance de ces photos dans la gestion quotidienne du réseau, nous avons pensé les intégrer dans la base de données de notre prototype, en leur ajoutant une dimension spatiale. Pour ce faire, nous avons développé un bouton « ajouter un repère » qui utilise la même technique que le bouton « signaler une fuite » pour récupérer la longitude et la latitude d’un point. Ces coordonnées sont insérées à la base de données via un formulaire, qui permet d’ajouter une description du repère et une requête SQL qui s’effectue en PHP.

9. Affichage des données attributaires

La possibilité d’afficher les données attributaires des couches dans un pop-up n’est active que lorsque l’utilisateur s’identifie par son nom d’utilisateur et son mot de passe. Cette fonctionnalité est gérée par GXP qui utilise la fonction « GetFeatureinfo » de GeoExt. L’extrait de code suivant montre comment ajouter la fonction « GetFeatureinfo » à l’application.

Page 31 sur 38

Figure 16: impression d’écran : affichage des données attributaires dans un pop-up

10. Affichage des images dans un pop-up Il existe deux techniques pour afficher les images dans un pop-up :

la première solution est de modifier le template de GeoServer, comme expliqué sur ce lien : http://docs.geoserver.org/latest/en/user/tutorials/GetFeatureInfo/index.html.

la seconde méthode est d’ajouter un lien HTML dans la table attributaire qui permet d’ouvrir l’image. Nous avons opté pour la deuxième solution car nous souhaitons ouvrir les images dans une fancybox. Ainsi pour l’affichage des détails des vannes qui sont des fichiers PDF, nous avons ajouté une colonne détail à la table attributaire des vannes, et dans cette colonne nous avons ajouté un lien avec le numéro de détail de chaque vanne. Par exemple pour ouvrir le détail SO2-3.pdf nous avons écrit ceci : <a class="fancypdf" href="detail/SO2-3.pdf">Cliquer ici pour afficher le pdf</a>. Nous avons écrit dans la page principale de notre programme le script suivant, qui permet d’ouvrir un PDF dans une fancybox :

Page 32 sur 38

Figure 17: impression d’écran : Affichage d’un pdf dans une fancybox

11. Sécurité des données Certaines données du Syndicat étant confidentielles, il s’avère indispensable de sécuriser l’accès à ces données, avant tout déploiement définitif du site. Le premier niveau de protection que nous avons mis en place est l’accès aux fonctionnalités de requêtes et d’éditions par identification. En effet, au moment de l’ajout d’un utilisateur par l’administrateur, un mot de passe généré automatiquement est envoyé à l’utilisateur dans sa boite mail. Chaque utilisateur est seul à connaître son mot de passe et a la possibilité de le modifier s’il le souhaite. Les mots de passe des utilisateurs sont cryptés dans la base de données par la fonction « hashsecure ». Ce premier niveau de protection permet de sécuriser l’accès aux données côté client, mais ne protège pas les WFS émis par le serveur. Il existe deux méthodes possibles pour protéger les couches de GeoServer :

Méthode n°1

Elle consiste à créer des groupes d’utilisateurs, puis à attribuer un nom d’utilisateur, un mot de passe et un rôle (simple visualisation, modification de WFS) à chaque utilisateur. GeoServer bloque dès lors la modification des données si l’utilisateur connecté n’appartient pas au groupe autorisé à effectuer des modifications. La procédure détaillée pour la mise en place de cette méthode est disponible à cette adresse : https://github.com/nfms4redd/nfms-documentation/blob/master/geoserver/security/layer_level.rst

L’inconvénient de cette méthode est le risque de dévoiler les identifiants de connexion dans le fichier de configuration de l’application en JavaScript.

Page 33 sur 38

Méthode n°2

Elle consiste à mettre le serveur web et GeoServer sur le même ordinateur. Par exemple, GeoServer peut être installé sur le port 8080, Postgresql/PostGis sur le port 5432, puis WampServer ou Apache Tomcat sur le port 80. Cela nous permet de bloquer l’accès au port 8080 utilisé par GeoServer, car les échanges entre le serveur web et GeoServer se feront en mode « localhost ». Seul le port 80 est alors accessible depuis internet. Nous avons réalisé un test avec cette solution en installant WampServer et GeoServer sur l’ordinateur qui a été affecté pour le stage. Les résultats de ce test montrent que le délai d’affichage des couches a été divisé par deux. L’inconvénient de cette méthode est qu’elle nécessite un bon débit d’accès à internet.

Configuration de l’interface

Figure 18 : impression d’écran : interface tout public

Figure 19 : impression d’écran : interface administrateur

L’interface de l’application est la partie visible par l’utilisateur ; elle fait le lien entre l’utilisateur et le serveur. Outre l’espace carte, l’interface est constituée d’un entête et d’une barre de navigation sur laquelle se trouve deux, quatre ou cinq boutons, selon que l’on est connecté ou non. Lorsqu’on accède au site, la page d’accueil s’affiche avec la barre de navigation avec deux boutons : Le premier bouton, en rouge, permet de signaler une fuite, le second permet de s’identifier. En cas d’identification, la barre de navigation se compose d’au moins quatre boutons :

le bouton « cartographie» (il permet d’accéder à l’espace carte), le bouton « ajouter un repère » (il permet d’ajouter une photo d’un organe), le bouton « tableau de bord » (il permet de visualiser les tableaux récapitulatifs), le bouton « mes paramètres » (il permet de changer le mot de passe), le bouton « Administrateur » (ce bouton ne s’affiche que si l’utilisateur est administrateur il permet

d’ajouter ou de désactiver un utilisateur, d’envoyer un mail à tous les utilisateurs ou à un seul utilisateur),

le bouton « déconnexion ».

Page 34 sur 38

VIII. RETOUR D’EXPERIENCE

J’ai passé environ quarante pour cent du stage à développer les principales fonctionnalités du prototype. J’ai souvent eu recours aux conseils de Mr JEGOU pour trouver des solutions alternatives à chaque fois que les difficultés rencontrées me paraissaient complexes ; ce fut le cas par exemple pour la mise en place du proxy. Les solutions aux difficultés rencontré durant mon stage , m’ont permis d’acquérir une expérience dans la modélisation de la base de données pour une application web de gestion de réseau, de faire des recherches sur les adaptations indispensables à réaliser afin de tirer le meilleur d’une application WebMapping sur un Smartphone.

1. Modélisation de la base de données Le Prototypage de l’application nous a permis de nous rendre compte de la difficulté d’utilisation de la base de données en l’état où nous l’avions initialement modélisée. En effet, nous n’avons pas trouvé une méthode adéquate pour mettre à jour automatiquement les clefs étrangères et les tables issues d’associations lorsque nous ajoutons les données online via GeoServer. Nous avons donc décidé de supprimer toutes les clefs étrangères des tables, ainsi que toutes les associations, et d’utiliser les requêtes spatiales de PostGis pour mettre en relation les entités. Par exemple, pour connaitre le nombre d’abonnés par commune, nous avons utilisé la requête suivante :

SELECT commune.nom_comm AS Commune, COUNT (abonnes.geom) AS NB_Abonnés, commune.geom AS geom FROM commune, abonnes WHERE ST_CONTAINS (commune.geom, abonnes.geom) GROUP BY commune.nom_comm, commune.geom ORDER BY commune.nom_comm

La fonction ST_CONTAINS permet de tester si une géométrie est incluse dans une autre. Le résultat est le même que s’il existait une relation entre la table ‘abonné’ et la table ‘commune’. Le délai d’exécution des requêtes est un peu plus long que si nous avions créé une relation entre les deux tables.

2. Adaptation de l’application sur un Smartphone Après un premier test sur Smartphone, nous avons constaté que, malgré l’utilisation d’un CSS Responsive, le site n’est pas adapté à un terminal mobile. En effet, l’entête du site sur lequel se trouvent les logos de bdEe et du SIAEP ADOUR COTEAUX occupe trop de place. Il ne reste plus qu’une petite place pour l’affichage de la carte. Pour remédier à ce défaut de dimensionnement de l’application sur terminal mobile, nous avons pensé qu’il fallait développer une version mobile de l’application. Cette version devra utiliser la bibliothèque GXM qui est la version mobile de GeoExt. La documentation de GXM est accessible à ce lien : http://trac.geoext.org/wiki/mobile . Faute de temps, pour prototyper la version mobile, nous avons fait quelques adaptations du site actuel pour le rendre un peu plus pratique sur Smartphone. Ces adaptations concernent d’abord l’entête du site, qui a été séparée de l’espace carte. En effet, lorsqu’un terminal mobile est détecté, un message d’accueil vous avertit que vous allez être redirigé vers la version mobile du site. Enfin, nous avons supprimé la barre de légende que nous n’estimons pas indispensable pour ce cas d’utilisation.

Page 35 sur 38

Figure 20: impression d’écran : Accueil Smartphone

Figure 21: impression d’écran : Carte sur Smartphone

L’adaptation réalisée permet de visualiser la carte, mais l’accès aux données attributaires grâce au clic sur l’objet ne fonctionne pas sur les versions androïdes de chrome et de Mozilla. Pour remédier à ce problème, nous pensons qu’il faudrait utiliser le « touch navigation control » d’OpenLayers, dont les spécifications sont accessibles sur ce lien : http://dev.openlayers.org/docs/files/OpenLayers/Control/TouchNavigation-js.html

3. Quelques améliorations possibles Les principales améliorations consistent à personnaliser les outils fournis par GXP. On pourrait utiliser les possibilités offertes par la méthode développement d’application web AJAX qui permet l’utilisation de XML sur HTTP en mode asynchrone en JavaScript, pour ajouter des listes déroulantes sur les formulaires, lors d’éditions. Cela faciliterait la saisie des données par l’utilisateur d’une part, et permettrait, d’autre part, de mieux contrôler les informations saisies (envoyées au serveur) par l’utilisateur. Par exemple, éviter de saisir du texte dans un champ de type numérique. Il faudrait également personnaliser le module d’impression fourni par GXP. On pourrait, par exemple, ajouter le logo du syndicat aux mises en page.

Page 36 sur 38

Conclusion

Le prototype réalisé pendant ce stage est un modèle pour les collectivités désireuses de mettre à disposition de leurs techniciens une Plateforme de partage d’informations géographiques. Ce prototype, développé exclusivement à partir d’applications OpenSource, fonctionne de manière très satisfaisante. Il permet la consultation du plan de réseau, de faire des requêtes attributaires, d’éditer les couches, de mesurer les distances et les surfaces, puis d’imprimer des extraits de plans. L’outil « signaler une fuite », que j’ai conçu permettra de collecter les données sur les fuites, mais, aussi de faire participer toute la population à une meilleure gestion de ce bien public : l’eau. L’application que j’ai développée répond aux principaux objectifs fixés en début de stage. Outre la partie cartographique, j’ai exploité la puissance du SGBD Postgresql et de son module spatial PostGis pour ajouter à l’application les tableaux statistiques basés sur des requêtes spatiales. Ces tableaux permettront d’avoir instantanément une idée globale sur l’état du réseau (nombre total d’abonnés, nombre de vannes, de fuites etc..). Comme toute application SIG, la valeur ajoutée du site dépendra de la capacité des utilisateurs à mettre à jour les données, et de la volonté de bdEe à améliorer ses performances. J’ai travaillé en toute autonomie dans la phase de développement du prototype, car je n’ai pas au sein de bdEe un référent en programmation web. J’ai eu à gérer en outre les problématiques purement informatiques, comme l’accès depuis internet à mon poste de travail, qui fait office de serveur provisoire. En effet, nous avons travaillé sur un réseau local et il ne fallait pas compromettre la sécurité des autres ordinateurs du réseau. Ces difficultés ont eu une incidence sur le planning de stage, mais nous ont permis de nous confronter aux réalités de la gestion de projets. Sur le plan personnel, ce stage, qui est avant tout l’aboutissement d’une volonté de formation de ma part, m’a permis de mettre en pratique les connaissances théoriques acquises durant la formation. J’ai ainsi pu modéliser une base de données sous Postgresql/ PostGis, mettre en place un serveur cartographique avec GeoServer, puis tester plusieurs API de WebMapping , notamment OpenLayers, GeoExt, Gxp, Leaflet, ainsi que des de SIG OpenSource à l’instar de Qgis, Udig. Le stage a été pour moi l’occasion d’améliorer mes compétences en programmation web surtout en PHP et JavaScript. J’ai aussi appris à tirer profit des débuggeurs de chrome et de Mozilla pour mieux comprendre le fonctionnement des scripts.

Page 37 sur 38

Glossaire

AEP : Alimentation en Eau Potable AJAX: Asynchronous JavaScript and XML EPSG: European Petroleum Survey Group KML: Keyhole Markup Language MCD : Modèle Conceptuel de données MLD : Modèle Logique de données OGC: Open Geospatial Consortium SIG: Système d’Information Géographique SLD: Styled Layer Descriptor VRD: Voierie et Réseaux Divers WFS: Web Feature Service WFS-T: Web Feature Service Transaction WMS: Web Map Service URI: Uniform Resource Identifier XMLHTTP : est un objet ActiveX ou JavaScript qui permet de faire des requêtes HTTP afin de

récupérer des données au format XML qui pourront être intégrées à un document. Cela peut être très utile pour mettre à jour des données sans pour autant recharger la page. c’est la base du fonctionnement AJAX

Table des figures

Figure 1 Extrait diagramme de Gant ...................................................................................................................................................................... 3 Figure 2 : architecture de l’application existante ............................................................................................................................................. 4 Figure 3: impression d’écran du site existant .................................................................................................................................................... 6 Figure 4: les communes du SIAEP ADCTX ........................................................................................................................................................... 7 Figure 5: Etapes de production de l’eau ; Source : http://www.cg66.fr/376-l-eau.htm ................................................................ 8 Figure 6: Architecture de l’application ............................................................................................................................................................... 17 Figure 7: Maquette de l’application ..................................................................................................................................................................... 18 Figure 8: Diagramme des cas d’utilisation ....................................................................................................................................................... 19 Figure 9: Diagramme des activités (utilisateur tout public) .................................................................................................................... 20 Figure 10: Diagramme des activités (utilisateur autorisé) ....................................................................................................................... 21 Figure 11: Diagramme des activités (tableau de bord) .............................................................................................................................. 22 Figure 12: MCD simplifié .......................................................................................................................................................................................... 23 Figure 13 Charte graphique de BDEE ................................................................................................................................................................. 27 Figure 14 extrait de SLD des vannes ................................................................................................................................................................... 27 Figure 15: impression d’écran : fuites signalées ............................................................................................................................................ 30 Figure 16: impression d’écran : affichage des données attributaires dans un pop-up ................................................................. 31 Figure 17: impression d’écran : Affichage d’un pdf dans une fancybox ............................................................................................. 32 Figure 18 : impression d’écran : interface tout public ................................................................................................................................ 33 FFigure 19 : impression d’écran : interface administrateur ..................................................................................................................... 33 Figure 20: impression d’écran : Accueil Smartphone .................................................................................................................................. 35 Figure 21: impression d’écran : Carte sur Smartphone .............................................................................................................................. 35

Page 38 sur 38

Blogs et forums d’entraide

ForumSIG : http://www.forumsig.org

PortailSIG : http://www.portailsig.org

Geotribu : http://www.geotribu.net

GeoRezo : http://georezo.net

Forum des professionnels en informatique : http://www.developpez.net/forums

Sencha (ExtJS) : http://www.sencha.com/forum

Développement PHP: http://www.siteduzero.com/

Documentation (API)

OpenLayers (version 2.10) : http://dev.openlayers.org/releases/OpenLayers-2.10/doc/apidocs/files/OpenLayers-js.html ExtJS (version 3.4) : http://dev.sencha.com/deploy/ext-3.4.0/docs GeoExt (version 1.0) : http://www.geoext.org/lib/index.html GXP : http://gxp.opengeo.org/master/doc/ GeoServer : http://opengeo.org/technology/geoserver/

Table des annexes

ANNEXE 1: MCD DETAILLE ......................................................................................................................................................................................... i

ANNEXE 2: CONFIGURATION DE LA CARTE ...................................................................................................................................................... ii

ANNEXE 3: PROXY.CGI .............................................................................................................................................................................................. vii

ANNEXE 4: HEADERS .PHP ........................................................................................................................................................................................ ix

Page i

ANNEXE 1: MCD DETAILLE

Page ii

ANNEXE 2: CONFIGURATION DE LA CARTE

Page iii

Page iv

Page v

Page vi

Page vii

ANNEXE 3: PROXY.CGI

#!C:/Python27/python.exe -u """This is a blind proxy that we use to get around browser restrictions that prevent the Javascript from loading pages not on the same server as the Javascript. This has several problems: it's less efficient, it might break some sites, and it's a security risk because people can use this proxy to browse the web and possibly do bad stuff with it. It only loads pages via http and https, but it can load any content type. It supports GET and POST requests.""" import urllib2 import cgi import sys, os # Designed to prevent Open Proxy type stuff. allowedHosts = ['localhost:8080','localhost','localhost:80','www.openlayers.org', 'openlayers.org', 'labs.metacarta.com', 'world.freemap.in', 'prototype.openmnnd.org', 'geo.openplans.org', 'sigma.openplans.org', 'demo.opengeo.org', 'www.openstreetmap.org', 'sample.azavea.com', 'v2.suite.opengeo.org', 'v-swe.uni-muenster.de:8080', 'vmap0.tiles.osgeo.org', 'www.openrouteservice.org'] method = os.environ["REQUEST_METHOD"] if method == "POST": qs = os.environ["QUERY_STRING"] d = cgi.parse_qs(qs) if d.has_key("url"): url = d["url"][0] else: url = "http://www.openlayers.org" else: fs = cgi.FieldStorage() url = fs.getvalue('url', "http://www.openlayers.org") try: host = url.split("/")[2] if allowedHosts and not host in allowedHosts: print "Status: 502 Bad Gateway" print "Content-Type: text/plain" print print "This proxy does not allow you to access that location (%s)." % (host,) print print os.environ

Page viii

elif url.startswith("http://") or url.startswith("https://"): if method == "POST": length = int(os.environ["CONTENT_LENGTH"]) headers = {"Content-Type": os.environ["CONTENT_TYPE"]} body = sys.stdin.read(length) r = urllib2.Request(url, body, headers) y = urllib2.urlopen(r) else: y = urllib2.urlopen(url) # print content type header i = y.info() if i.has_key("Content-Type"): print "Content-Type: %s" % (i["Content-Type"]) else: print "Content-Type: text/plain" print print y.read() y.close() else: print "Content-Type: text/plain" print print "Illegal request." except Exception, E: print "Status: 500 Unexpected Error" print "Content-Type: text/plain" print print "Some unexpected error occurred. Error text was:", E

Page ix

ANNEXE 4: HEADERS .PHP

Page x