Master 2 Géomatique 2011-2012 Jean-Brieuc LEHÉBEL-PÉRON Maîtres de stage : Jérôme MOUCHELIN AQUASCOP BIOLOGIE Tuteur : Jean-Christophe DESCONNETS Master Mention IGT Ingénierie et Gestion Territoriales et Mention Informatique Spécialité Géomatique - Mise en œuvre de nouveaux services de diffusion de l information à composante géographique à travers les technologies du Web. Aquascop Technopole d Angers 1, avenue du bois l Abbé 49070 Beaucouzé Université Paul-Valéry Route de Mende 34 199 Montpellier Université Montpellier 2 Place Eugène Bataillon 34095 Montpellier
Sommaire SOMMAIRE... 1 REMERCIEMENTS... 3 GLOSSAIRE... 4 1. INTRODUCTION... 5 1.1. Contexte du stage... 5 1.2. Présentation du suivi hydrobiologique des masses d'eau du bassin hydrographique Loire-Bretagne... 6 1.3. Objectifs détaillés du stage... 7 1.4. Planning prévisionnel... 8 2. MÉTHODOLOGIE... 10 2.1. Diffusion de données KML... 10 2.1.1. Le KML et Google Earth... 10 2.1.2. Les modes de représentation recherchés... 11 2.1.3. Méthode employée pour créer des couches KML... 12 2.1.4. Présentation des travaux et mise en œuvre d'un outil de génération de KML16 2.2. Diffusion de données par un serveur cartographique... 17 2.2.1. Le service WFS.... 17 2.2.2. Objectifs du volet de diffusion de données géographique par l'utilisation d'un serveur cartographique... 19 2.2.3. La mise en œuvre d'une architecture 3-tiers... 20 2.2.3.1. Niveau 1 : serveur cartographique... 21 2.2.3.1.1 Choix du serveur cartographique... 21 2.2.3.1.2 Optimisation du serveur cartographique... 24 2.2.3.2. Niveau 2 : choix et modélisation de la base de données... 25 2.2.3.2.1 Choix de la base de données... 25 2.2.3.2.2 Modélisation de la base de données... 27 2.2.3.3. Niveau 3 : présentation des données... 29 2.2.3.3.1 Choix des API JavaScript... 29 2.2.3.3.2 Mise en place de l'interface... 31 3. RÉSULTATS... 34 3.1. Le site internet... 34 3.1.1. "Fichier KML"... 34 3.1.2. "Services WFS"... 36 3.1.3. "Visualisation Carto."... 37 1
3.2. Les documents de spécifications... 44 4. LE PLANNING RÉEL ET DIFFICULTÉS RENCONTRÉES... 45 5. CONCLUSION... 46 6. WEBOGRAPHIE ET BIBLIOGRAPHIE... 48 7. ANNEXES... 50 2
Remerciements Avant de commencer ce rapport, je tiens à remercier l'ensemble des personnes ayant contribué de près ou de loin à la réalisation de ce stage. Je remercie tout d'abord Danielle Levet, gérante et Frédéric Leseigneur, directeur, pour m'avoir accueilli au sein d'aquascop pendant ces 6 mois. Un grand merci à mon maître de stage Jérôme Mouchelin, pour son encadrement, ses conseils, sa totale disponibilité et pour la transmission de son savoir professionnel tout au long de ce stage. Merci particulièrement à Séverine Chauvet-Gérard responsable du service Géomatique, pour son aide et sa disponibilité. Bien évidemment merci à Madeline Benner, Guillaume Gallais, Violaine Lamour et Romain Savastano, collègues de bureau Géomatique pour leur présence et leur assistance durant ce stage. Merci au service Informatique, Clément Brosseaud, Frédéric Leseigneur, Edwin Menard, Arnaud Crasnier et Arnaud Drazek pour leurs aides précieuses, leurs disponibilités et pour le travail réalisé durant ces 6 mois de stage. Je tiens à remercier l'ensemble du personnel d'aquascop, qui a fait de ce stage une expérience enrichissante professionnellement et humainement. Merci à l'équipe pédagogique du Master Géomatique, mon tuteur de stage Jean-Christophe Desconnets, pour ses conseils, Jean-Paul Bord, Thérèse Libourel et Olivier Chapelon pour m'avoir permis de réaliser ce stage. Enfin, je remercie mes proches pour leur aide sur ce stage et ce mémoire. 3
Glossaire AJAX : Asynchronous Javascript and XML, permet de créer des applications Web pouvant dialoguer de manière asynchrone avec le serveur Web. Cette technique permet de modifier le contenu d'une page Web à partir de données provenant d'un serveur, sans recharger la page. API : Application Programming Interface, bibliothèque contenant un ensemble de classes et de fonctions permettant la mise en place d'une interface homme-machine facilitée. DOM : Document Object Model est une recommandation du World Wide Web Consortium permettant à des programmes informatiques d accéder à du contenu, telle une page Web. EPSG : European Petroleum Survey Group, est un groupe définissant une liste des systèmes de coordonnées géoréférencées en leur associant un code d'identification. Ext JS : API JavaScript permettant de construire des applications web interactives JavaScript s'approchant des applications bureautiques dans leur apparence et dans leur manière de fonctionner (contrôles). GeoExt : API JavaScript permettant de construire des éléments d'une interface cartographique, liant la librairie Ext JS et OpenLayers. GeoJSON : format d'échange de données géographiques basé sur le format JSON. GML : Geography Markup Language est un format dérivé du XML, permettant l'échange de données géographiques. JavaScript : Langage de programmation utilisé pour réaliser des pages Web interactives. Les scripts sont interprétés et exécutés par le navigateur internet côté client. JSON : JavaScript Object Notation, format de données textuel permettant de représenter de l'information structurée. OpenLayers : API JavaScript permettant de créer une application cliente cartographique. OSM : OpenStreetMap, projet qui a pour but de créer une cartographie mondiale libre. PHP : Hypertext Preprocessor est un langage informatique permettant de créer des pages Web dynamiques en communiquant avec des bases de données. Ce langage est interprété côté serveur. 4
1. INTRODUCTION 1.1. CONTEXTE DU STAGE Aquascop est un bureau d'étude et de recherche spécialisé en écologie et en aménagement des milieux aquatiques. Fondé en 1985, Aquascop est composé d'une équipe d'une quarantaine de personnes qualifiées, constituée aussi bien d'hydrobiologistes (spécialistes en diatomées, invertébrés, macrophytes, poissons et autres organismes aquatiques), que de géomaticiens ou d'informaticiens. Entièrement gérée par son équipe dirigeante, actionnaire de l'entreprise, Aquascop a son siège social à Beaucouzé, commune située en périphérie d'angers (49). Une antenne est également installée à quelques kilomètres au nord de Montpellier, à Saint-Mathieu-de-Tréviers (34), permettant ainsi à l'entreprise d'être représentée sur l'ensemble du territoire métropolitain. Les agences de l'eau, les services de l'état, les Conseils Généraux, les communautés de communes et quelques industriels font partie des nombreux clients d'aquascop. De par la qualification de son personnel, les activités et domaines d'intervention d'aquascop sont multiples : expertises hydrobiologiques et physicochimiques : écologie des peuplements aquatiques, qualité de l'eau et des sédiments, suivi de réseaux de mesure. études d'impact et d'incidence : ouvrages (barrages, stations d'épuration, ouvrages hydroélectriques ), infrastructures de transport, pisciculture études de gestion et de mise en valeur du milieu naturel : aménagement intégré de bassin versant, Schéma d'aménagement et de Gestion des Eaux (SAGE), contrats de rivière, inventaires de zones humides protection de la ressource et des usages : diagnostic d'eutrophisation, suivi de la qualité des eaux, vulnérabilité des milieux, programme de restauration et de prévention. système d'informations et traitement des données : cartographie thématique, analyses spatiales, conception et gestion de base de données, production d'outils Pour ce dernier domaine, et dans le cadre du développement d'un logiciel de gestion de données sur l'eau, Aquascop a la volonté d'acquérir de nouvelles compétences de cartographie dynamique sur internet. C'est donc dans cette optique que mon stage a été réalisé. 5
1.2. PRÉSENTATION DU SUIVI HYDROBIOLOGIQUE DES MASSES D'EAU DU BASSIN HYDROGRAPHIQUE LOIRE-BRETAGNE L'essentiel des travaux réalisés durant ce stage sont en lien avec un marché en cours, commanditée par l'agence de l'eau Loire-Bretagne. Dans le cadre de l'application de la directivecadre sur l'eau, un programme de surveillance des milieux aquatiques a été mis en œuvre pour permettre de suivre l'état physicochimique, hydromorphologique et écologique des eaux de surface. Aquascop travaille depuis 1999 sur le suivi de la qualité des masses d'eau cours d'eau du bassin hydrographique Loire-Bretagne. Figure 1 : Carte du bassin hydrographique Loire-Bretagne Dans un premier temps, ce programme de surveillance permet d'opérer un contrôle dit de surveillance destiné à connaître l'état général des eaux. Dans un second temps, il consiste à réaliser un contrôle dit opérationnel permettant d'établir l'état des masses d'eau risquant de ne pas répondre aux objectifs de bon état écologique en 2015, et d'évaluer leur changement d'état suite aux programmes de mesures. Ces contrôles sont réalisés sur différentes stations de mesure de qualité de l'eau qui regroupent chacune plusieurs sites de prélèvement. Ces sites doivent permettre d'effectuer des 6
mesures physicochimiques et biologiques spécifiques concernant la qualité du milieu aquatique (eau, poissons, macro-invertébrés, diatomées, macrophytes ). Dans ce cadre, Aquascop administre les informations permettant la localisation géographique précise de ces stations et sites et, ainsi, leur positionnement vis-à-vis des masses d'eau associées. 1.3. OBJECTIFS DETAILLÉS DU STAGE La lettre de mission initiale, présentée en annexe 1, donnait trois objectifs à réaliser pendant la durée du stage. Ces objectifs considérés comme trois volets du stage sont les suivants : mettre en place un service de fourniture de données au format KML, mettre en place un système de fourniture de données à travers un service WFS, mettre en place un service de consultation cartographique de données sur internet. Le stage devait, en plus des missions principales listées ci-dessus, permettre au stagiaire de participer ponctuellement aux activités du service géomatique, sans que ces missions secondaires n'empiètent trop sur le déroulement du stage. Le stagiaire doit avoir en charge la définition des différentes spécifications techniques de mise en œuvre des nouveaux services de diffusion de l'information géographique, doit réaliser des tests de mise en place et des tests d'utilisation des différentes technologies. Il est chargé de mettre en œuvre ces nouveaux services dans le cadre d'un cas concret : le site internet dédié à l'étude du suivi hydrobiologique des masses d'eau du bassin Loire-Bretagne. En plus de la mise en place des différents services de diffusion et de consultation de données géographique, le stage doit permettre la réalisation d'un ensemble de documents de spécifications explicitant les architectures et procédures utilisées par le stagiaire, et ceci dans le but de permettre aux services d'aquascop de mettre en place par eux-mêmes, au terme du stage, de nouveaux service de diffusion de données à travers les technologies du Web. Ces documents de spécifications doivent être sous la forme de documents texte contenant des exemples de codes et dont les méthodes et paramètres liés aux différentes technologies sont détaillés. Comme la lettre de mission le spécifie, le suivi et le bon déroulement du stage sont assurés par un des chefs de projet du service géomatique de l'entreprise. Le stagiaire est en même temps sous la 7
tutelle du service géomatique et du service informatique pour l'organisation des différentes composantes du stage. 1.4. PLANNING PRÉVISIONNEL Un planning prévisionnel des tâches à accomplir (Figure 2) a été mis en place en début de stage. Celui-ci avait pour but d'établir les étapes d'avancement du stage sur les différents volets à aborder. De plus, des échéances de validation étaient fixées à intervalles réguliers pour permettre une avancée cohérente et par étapes du stage. Ce planning prévisionnel avait également pour rôle de surveiller, au fur et à mesure de l'avancée globale du stage, qu'il se déroulait dans les délais attribués à chacun des trois volets, ou bien si son avancée était trop rapide ou trop lente, auquel cas des ajustements auraient pu être envisagés. Le temps attribué pour la réalisation du premier volet sur le KML était de cinq semaines. Le volet 2, qui consistait à mettre en place un serveur cartographique et une application de visualisation de données cartographiques, avait un délai de réalisation de treize semaines. Le dernier et troisième volet sur la mise en place d'un service WFS devait être réalisé en trois semaines. Celui-ci ne devant être exécuté que si l'avancée sur les deux premiers volets le permettait. Enfin, trois semaines était réservées pour la réalisation du rapport de stage et à la préparation de la présentation orale de fin de stage. Sur l'ensemble des volets à aborder, si des difficultés devaient être rencontrées, un temps supplémentaire pouvait être accordé à la réalisation de la tâche. Ces délais, classifiés de manière graduelle en fonction du temps nécessaire en supplément, avaient comme optique de ne pas perdre le cours du stage en partant dans des difficultés ne pouvant être résolues. 8
Figure 2 : Planning prévisionnel 9
2. MÉTHODOLOGIE 2.1. DIFFUSION DE DONNEES KML 2.1.1. Le KML et Google Earth Le KML, pour Keyhole Markup Langage, est un format de fichier standardisé basé sur la structure du langage XML. Il est destiné à gérer l'affichage de données géographiques au sein de nombreuses applications. Les principales applications pouvant être citées sont le logiciel Google Earth, les logiciels SIG ou bien les applications de Web mapping telles OpenLayers ou Google Map. Le format KML, acheté par l'entreprise Google en 2004, a depuis été standardisé par l'open Geospatial Consortium (OGC) lui permettant ainsi de devenir un standard interopérable. Il a pour rôle de stocker des informations géographiques, attributaires ou bien même des définitions de styles, sous forme de balises XML spécifiques. Figure 3 : Interface de Google Earth Une des raisons pour laquelle le choix de diffuser des données sous le format KML a été prise par Aquascop, résulte du fait que Google Earth (Figure 3 : Interface de Google Earth) est un logiciel gratuit facilement téléchargeable à partir du site internet dédié de Google. Cette application possède également de nombreux utilisateurs. De plus, pour être utilisé, Google Earth ne requiert aucune compétence géomaticienne, contrairement aux logiciels SIG. La grande force de Google Earth, et ce qui a sûrement participé à sa notoriété, provient du fait qu'il offre, sur une emprise mondiale, un fonds de plans issu de prises de vue aériennes ou satellitaires. Bien que non orthorectifiées, ces vues présentent une très bonne résolution spatiale 10
sur l'ensemble du territoire métropolitain. Elles peuvent, de plus, être drapées sur un modèle numérique d'élévation, ajoutant ainsi une composante 3D à la visualisation des données géographiques sous Google Earth. Ainsi, l'utilisation du couple Google Earth KML permet de représenter de nombreuses données, aussi bien géographiques qu'attributaires, sous une interface agréable et facile à prendre en mains, mais surtout qui est accessible à un grand nombre de personnes. 2.1.2. Les modes de représentation recherchés Les besoins d'aquascop ont été définis à travers un document de synthèse (annexe 2) et lors d'une réunion de démarrage effectuée avec le maître de stage. Ils portent sur la réalisation et la remise, au personnel géomaticien et informaticien, d'un document technique permettant de définir les éléments spécifiques au format KML. À partir de ce document, un géomaticien ou un informaticien doit pouvoir être en mesure de comprendre le langage KML et de produire facilement des fichiers sous ce format, pouvant être visualisables sous Google Earth. Les spécifications pour la constitution des fichiers KML doivent permettre : de paramétrer l'emprise de la vue à afficher, d'afficher des types de données géographiques classiques, d'utiliser une sémiologie propre aux données utilisées, de représenter graphiquement les données selon une analyse thématique, de pouvoir visualiser des données attributaires. Enfin, il convient que le document technique s'adresse à un public de développeurs, afin qu'ils puissent mettre en place un programme ou un outil dont le rôle serait de générer de manière automatique des fichiers KML correctement formatés. Les étapes menées pour réaliser ce volet sont détaillées dans la Figure 4 : Organisation des travaux sur le volet KML. Ce schéma montre l'enchaînement des étapes effectuées lors de la réalisation de cette partie du stage de la réunion de démarrage à la validation de l'outil de génération par le stagiaire. 11
Figure 4 : Organisation des travaux sur le volet KML 2.1.3. Méthode employée pour créer des couches KML Dans un premier temps, en réponse aux besoins exprimés, il a été procédé à la recherche d'un maximum de documentations sur ce format de données géographiques et à leur exploitation. Dans un second temps, en fonction des divers éléments trouvés des tests de fonctionnement du couple Google Earth KML ont été réalisés. Le temps consacré à la recherche et à la compréhension des documentations trouvées a été d'une semaine et demie. Bien que de nombreux exemples soient présents sur internet, la documentation la plus importante a été la documentation de référence sur le KML fournie par 12
Google. Au même titre que le document de standardisation soumis par l'ogc, elle détaille chaque élément composant un fichier KML ainsi que leur organisation les uns avec les autres. <Document> Elément du KML (possède un ID) Feature <Folder> <Placemark> <NetworkLink> <ScreenOverlay> ElementGeogaphique <Point> <LineString> <Polygon> <MultiGeometry> <Style> <StyleMap> <BalloonStyle> <IconStyle> <LineStyle> <PolyStyle> <ListStyle> <LabelStyle> <Region> <LatLonBox> <Lod> Figure 5 : Diagramme des classes KML (developers.google.com, modifié) 13
Le KML étant un langage d'objets à balises, une difficulté rencontrée a été de conceptualiser et de comprendre l'architecture et l'organisation des différentes classes entre-elles (Figure 5 : Diagramme des classes KML (developers.google.com, modifié). Des notions de classes abstraites (apparaissant en grisé sur la Figure 5 : Diagramme des classes KML (developers.google.com, modifié)) non maîtrisées initialement et dont la présence n'était pas pressentie, ont posées quelques difficultés de compréhension de l architecture de ce format. L'essentiel du travail a donc été de comprendre les différentes documentations référençant l'ensemble des éléments pouvant constituer un fichier KML, de faire le tri entre les éléments présentant un intérêt quant aux besoins exprimés et ceux jugés inintéressants pour Aquascop. Lorsque le fonctionnement global du format KML a été compris, des tests ont pu être lancés. Dans un premier temps, il s'agissait de créer de multiples fichiers tests possédant très peu de données, mais qui permettaient de visualiser le rendu global des KML développés sous l'interface de Google Earth. Ces tests ont été réalisés en fonction des différents éléments recherchés et qui répondaient aux besoins initiaux (structures des éléments géographiques, sémiologie des objets, analyses thématiques, quantité de données pouvant être affichées ). Une configuration très simple de fichier KML peut être schématisée selon la Figure 6 : Configuration simplifiée d un fichier KML. Le cheminement est le suivant : un Placemark correspond à une donnée géographique. Plusieurs Placemark peuvent composer un Folder. Plusieurs Folder peuvent composer un Document. Des Style, indiqués dans le Document, sont appliqués à des objets géographiques (Placemark) à travers l usage d identifiants de style. Par la suite, la méthode employée pour générer des fichiers KML à partir de données issues de fichiers Shapefile ou Tab a été d'utiliser les trois logiciels SIG, ArcGIS 10, MapInfo 11 et Quantum GIS 1.7 et de comparer les résultats à l'issue de leur génération. En effet, ces trois logiciels proposent des outils de conversion de données en KML. ArcGIS est également capable de convertir des documents, c est-à-dire plusieurs couches auxquelles une sémiologie est appliquée, au format KML. 14
Les façons dont les trois logiciels génèrent des fichiers KML sont intéressantes à comparer car chaque logiciel présente des différences de structuration des fichiers. Figure 6 : Configuration simplifiée d un fichier KML Par la conversion des documents, ArcGIS est capable d exporter la mise en page réalisée au format KML, permettant ainsi de conserver les différents styles d affichages des données cartographiques, la sémiologie, les analyses thématiques. Les données attributaires des objets géographiques sont quant à elles stockées sous la forme d un tableau HTML dans le paramètre description de l objet Placemark généré. MapInfo propose deux types d export différents. Le premier permet d exporter la fenêtre carte et donc le résultat d'une analyse thématique au format raster qui pourra être drapée sur le relief de Google Earth. Cette génération est de très mauvaise qualité, tant en terme de résolution d image générée que d absence de données attributaires. Heureusement, le second type proposé permet d'exporter des données KML contenant des données vectorisées. Par comparaison, Quantum GIS permet un export KML de meilleure qualité. En effet, les données générées sont plus conformes aux spécifications du KML. Ceci peut probablement s'expliquer par le fait que pour convertir des données au format KML, QGIS exploite la librairie libre et open source OGR. Celle-ci est capable de convertir un grand nombre de formats de 15
données vectorielles dans un autre format. Certes QGIS ne permet pas l export de styles d affichage, mais les données attributaires sont stockées dans un objet SchemaData permettant ainsi de les réutiliser dans le contenu d une infobulle par exemple. Au final, la méthode utilisée pour créer les fichiers tests à partir de données stockées dans des fichiers Shapefile ou des fichiers Tab a été de les convertir dans un premier temps au format KML par le logiciel QGIS. Ces fichiers générés possèdent néanmoins des erreurs d architecture. Par exemple, l'objet SchemaData est présent dans un objet Folder, alors que conformément aux spécifications KML, il doit prendre place dans un objet Document. Comme aucun style n est généré, il est nécessaire, dans un deuxième temps, de les ajouter de manière manuelle, ou à travers l'utilisation d'expressions régulières qui permettent ainsi de remodeler des chaînes de texte correspondant à l'objectif souhaité. Les tests réalisés ont permis, au final, de créer des fichiers KML de démonstration (extrait en annexe 3) représentant des cas concrets pouvant être mis en exploitation par Aquascop. 2.1.4. Présentation des travaux et mise en œuvre d'un outil de génération de KML Au terme des travaux réalisés sur le volet KML, une réunion bilan a été organisée avec mon maître de stage, la responsable du service géomatique ainsi que le personnel du service informatique au cours duquel, sous la forme d une présentation, les différentes solutions qui pouvaient être mises en place ont été exposées. Les résultats ayant été validés à l'issue de la présentation, la main a été donnée au service informatique afin qu'il puisse mettre en œuvre un outil de génération automatique de KML sur les modèles présentés. Bien que le planning prévisionnel prévoyait la réalisation de l'outil à la suite du volet 1, un décalage a du se faire. Les plans de charge du personnel d'aquascop évoluant souvent en fonction des besoins, il a été nécessaire d'adapter l'organisation des tâches et des interventions. L'outil crée par l'équipe informatique a pour rôle de générer des fichiers KML respectant les spécifications du format à partir de données présentes dans une base SQL Server. Il permet ainsi, à partir d'un fichier de configuration, d'appliquer des styles d'affichage aux objets en fonction de leurs données attributaires et de paramétrer le contenu des infobulles. 16
L'outil étant développé par le service informatique, mon intervention sur cette tâche devait seulement permettre de vérifier que les fichiers construits respectaient bien les spécifications liées au format KML, et ainsi apporter des conseils ou des rectifications quant à la mise en œuvre de l'outil pour, au final, le valider. 2.2. DIFFUSION DE DONNEES PAR UN SERVEUR CARTOGRAPHIQUE Dans un second temps, le stage devait permettre la mise en place d'une architecture informatique permettant, d'une part, le déploiement d'une application Web de cartographie interactive et, d'autre part, le déploiement d'une solution de diffusion de données cartographiques par la mise en œuvre d'un service WFS (Web Feature Service). Ce volet du stage, le plus important à réaliser, nécessitait d'aborder un ensemble de technologies Web jusqu'alors non développées par Aquascop mais pourtant indispensables à la réalisation de cette application cartographique. 2.2.1. Le service WFS. Le WFS est un protocole de communication établi entre un client et un serveur cartographique qui le fournit (Figure 7 : Fonctionnement d un service WFS en getfeature). Ce service standardisé est décrit et maintenu par l Open Geospatial Consortium (OGC). Un WFS permet, à partir d une URL structurée, de réaliser une requête sur un serveur cartographique dans le but de recevoir ou de manipuler des objets géographiques. L'URL d'un WFS est composée de plusieurs paramètres dont les valeurs vont jouer sur la réponse émise par le serveur cartographique. Dans cet exemple de requête on distingue trois éléments : http://188.165.239.36:81/cgi-bin/mapserv.exe? map=/ms4w/apps/programme_surveillance_lb/wfs/servicewfs.map& SERVICE=WFS&REQUEST=GetCapabilities&VERSION=1.1.0 - http://188.165.239.36:81/cgi-bin/mapserv.exe? : est l'adresse du serveur cartographique. - map=/ms4w/apps/programme_surveillance_lb/wfs/servicewfs.map& : correspond au fichier du Mapfile configurant le serveur cartographique. - SERVICE=WFS&REQUEST=GetCapabilities&VERSION=1.1.0 : correspond aux différents paramètres liés au WFS qui peuvent être passés au serveur cartographique. La valeur transmise par le paramètre REQUEST va jouer sur le type de réponse émise : 17
REQUEST=getCapabilities renvoie un document XML contenant les métadonnées du WFS. REQUEST=DescribeFeatureType renvoie un document XML contenant les informations sur les champs et les types des données du WFS. REQUEST=GetFeature renvoie un flux GML (Geography Markup Language) permettant d'obtenir les données géographiques. REQUEST= Transaction n'est pas disponible sur l'ensemble des serveurs cartographique. Elle permet de créer, mettre à jour et supprimer des objets géographiques. Lors de l'utilisation d'une requête getfeature, les données sont transmises sous le format GML. Il présente l avantage de stocker des objets en format vectoriel ainsi que les données attributaires liées à ces objets. Figure 7 : Fonctionnement d un service WFS en getfeature Les différents serveurs cartographiques utilisés pour fournir un service WFS peuvent ne pas présenter les mêmes caractéristiques. En effet, si des serveurs cartographiques fournissent seulement des données utilisables en lecture seule, d autres sont capables de fournir des données en lecture et écriture, ceci correspond alors à un Web Feature Service Transactionnel (WFS-T). De ce fait, par l'utilisation d'une requête ayant comme paramètre REQUEST=Transaction, un WFS-T peut créer, mettre à jour, ou bien même supprimer des objets géographiques. 18
2.2.2. Objectifs du volet de diffusion de données géographique par l'utilisation d'un serveur cartographique L objectif de cette partie du stage est de pouvoir remettre au personnel géomaticien et information d Aquascop une documentation technique détaillant la mise en œuvre d une architecture informatique. Celle-ci doit permettre la réalisation d'une application de visualisation cartographique dynamique sur internet et la mise en place d'un service de diffusion de données par WFS. Ce document, qui est destiné à un public de développeurs, se doit d expliquer les méthodes et les outils utilisés lors de l installation, de la configuration et du développement de l'ensemble de l'architecture informatique. Les travaux sur ce volet du stage ont débuté par une réunion de concertation avec le maître de stage. Les objectifs à atteindre par la mise en œuvre de l'application cartographique y ont été définis. Une documentation de synthèse (annexe 5) présentant les principaux points à traiter sur les différents éléments à prendre en compte a également été fournie lors de cette réunion. Les objectifs fixés devaient permettre d'éclaircir les points suivants : côté serveur, connaître les possibilités en termes de : gestion des protocoles Web géographiques (WMS, WFS ), gestion des données attributaires, réalisation de traitements spatiaux. côté client, connaître les possibilités en termes de : développement d interface cartographique, d interactions avec le contenu affiché. La mise en œuvre d'un service WFS doit pouvoir permettre à Aquascop de diffuser des données cartographiques au format vectoriel avec leurs données attributaires associées, de manière interne, mais aussi, selon les études en cours, à des clients ou autres partenaires disposant de logiciels SIG. Pour ce service WFS, seul l'aspect consultation de données doit être exploré, ainsi un service WFS basique, non transactionnel se devait d'être mis en œuvre. Il est spécifié par Aquascop que les différentes solutions choisies doivent être libres et open source. Elles doivent également respecter les standards et les normes soumises par l OGC (Open Geospatial Consortium). 19
En ce qui concerne le choix du serveur cartographique, la lettre de mission ne demandait pas de réaliser une étude comparative des différentes solutions existantes en termes de serveur. De plus, l utilisation de MapServer avait déjà pu être testée rapidement par Aquascop il y a quelques années, sans avoir la possibilité d étudier sérieusement le fonctionnement de ce serveur cartographique et le paramétrage des fichiers de configuration Mapfile. Cependant, une analyse de l existant par rapport aux besoins techniques exprimés a été effectuée. La réalisation d'une architecture de type 3-tiers a été mise en avant. Une réunion de validation a été réalisée deux semaines plus tard afin de présenter les résultats des différents éléments de l'architecture 3-tiers à mettre en œuvre et de les faire valider. 2.2.3. La mise en œuvre d'une architecture 3-tiers Les applications web développées par Aquascop sont hébergées sur un serveur distant. La solution envisagée pour répondre aux besoins exprimés passe par la mise en œuvre d'une architecture 3- tiers. Celle-ci permet de diviser en niveau de couches les éléments du système informatique. Ainsi, on trouvera une couche inférieure de données, une couche intermédiaire de traitement des données et enfin une couche supérieure de présentation. Dans ce système la couche supérieure est cliente de la couche inferieure. Ceci peut être schématisé par la Figure 8 : Schéma d'une architecture 3-tiers Figure 8 : Schéma d'une architecture 3-tiers 20