système d'information et gestion des ... - ori-oai: accueil

Stage de fin d'études

Système d'information et gestion des bassins

versants au Vanuatu

Résumé

Rapport de stage de �n d'études réalisé entre Mars et Septembre 2009 à l'Institut de Recherche

pour le Développement de Nouvelle Calédonie.

Géographie, Projection, SIG, OGC, WMS, WFS

Javascript, OpenLayers, ExtJS, Java, JEE

Alban Diguer

Ecole Supérieure d'Ingénieurs de Luminy

Département Informatique

Tuteur de stage: Touraivane

Référent ESIL: Léon Mugwaneza

29 septembre 2009

1

Historique des révisionsVersion Date Description des évolutions Auteurs

1.0 01/08/09 Création Alban Diguer

Table des matières

1 Glossaire 6

2 Résumé 7

3 Sujet et contexte 8

3.1 Sujet du stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.1.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.1.2 Sujet initial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.1.3 Sujet réel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2 Présentation de l'organisme et du service . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2.1 Institut de Recherche pour le Développement et unité ESPACE . . . . . . . . 10

3.2.2 UNC et PPME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3 Rôles occupés dans les services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Description détaillée du sujet 12

4.1 Travaux à réaliser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.1.1 Architecture du système et développement logiciel . . . . . . . . . . . . . . . 12

4.1.2 Recueil de données et intégration dans l'entrepôt . . . . . . . . . . . . . . . . 13

4.2 Description de l'existant, état de l'art . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.3 Solutions envisageables, choix des solutions et raisons . . . . . . . . . . . . . . . . . . 15

4.3.1 Optimiser le chargement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.3.2 Faire un code maintenable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.3.3 Protéger le code de l'application . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.3.4 Spéci�er l'outil pour une zone . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.3.5 Mettre en place le stockage de la donnée . . . . . . . . . . . . . . . . . . . . . 16

4.3.6 Sécuriser l'accès aux données . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.3.7 Gérer les cycles de vie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.4 Description technique de la solution choisie . . . . . . . . . . . . . . . . . . . . . . . 18

4.4.1 Optimiser le chargement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.4.2 Factoriser le code et faire un code maintenable . . . . . . . . . . . . . . . . . 19

4.4.3 Protéger le code de l'application . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.4.4 Spéci�er l'outil pour une zone . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.4.5 Mettre en place le stockage de la donnée . . . . . . . . . . . . . . . . . . . . . 21

4.4.6 Sécuriser l'accès aux données . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.4.7 Cycle de vie de l'application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.4.8 Cycle de vie de la donnée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.5 Méthodes et outils utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.5.1 Méthodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.5.2 Outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.6 Organisation du travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.7 Planning prévisionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5 Résultats obtenus 27

5.1 Résultats de mon travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.2 Di�cultés rencontrées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.3 Planning réel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.4 Limites éventuelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.5 Exploitabilité pour l'organisme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.6 Suites à donner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.7 Suggestions à l'organisme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6 Bilan 30

6.1 Apport à l'entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6.2 Apport de l'entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6.3 Apport de l'école . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6.4 Retour d'expérience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6.5 Si c'était à refaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

A Annexes 31

A.1 Documents rédigés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

A.1.1 Document sur l'architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

A.1.2 Document sur les données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

A.2 Liste des couches de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

A.3 Description du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

A.3.1 Aide en ligne - Fonctionalités . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

A.3.2 Captures d'écran . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

A.4 Exemples de code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

A.4.1 Amélioration des performances de l'application . . . . . . . . . . . . . . . . . 42

A.4.2 Intégration des données dans GeoServer . . . . . . . . . . . . . . . . . . . . . 42

A.4.3 Internationalisation par Javascript . . . . . . . . . . . . . . . . . . . . . . . . 43

A.4.4 Connexion et gestion des droits d'accès . . . . . . . . . . . . . . . . . . . . . . 44

1 Glossaire

CRISP / GERSA GERSA/CRISP

SIG Un système d'information géographique (S.I.G) est un outil informatique permettant d'orga-niser et présenter des données alphanumériques spatialement référencées, ainsi que de produiredes plans et cartes.

Projection cartographique La projection cartographique est un ensemble de techniques géodé-siques permettant de représenter la surface de la Terre dans son ensemble ou en partie sur lasurface plane d'une carte.

OGC Open Geospatial Consortium est un consortium international pour développer et promouvoirdes standards ouverts.

WMS Web Map Service permet de produire des cartes de données géoréférencées à partir de di�é-rents serveurs de données.

WFS Web Feature service est un protocole décrit dans des spéci�cations maintenues par l'OpenGeospatial Consortium.

GeoServer GeoServer est une conceptualisation en code source des impératifs de l'OpenGIS pourles serveurs d'applications cartographiques sur le Web. Cette application s'ajoute à votre basede données cartographique existante et s'utilise comme un service de cartographie sur Inter-net, permettant d'accéder aux informations géographiques. Ce contenu pourra être modi�é etconstamment enrichi.

JavaScript JavaScript est un langage de programmation de scripts principalement utilisé dansles pages web interactives. C'est un langage orienté objets à prototype, c'est-à-dire que lesbases du langage et ses principales interfaces sont fournies par des objets qui ne sont pas desinstances de classes, mais qui sont chacun équipés de constructeurs permettant de générer leurspropriétés, et notamment une propriété de prototypage qui permet d'en générer des objetshéritiers personnalisés.

OpenLayers OpenLayers est un logiciel libre, publié sous licence BSD. Il constitue une bibliothèquede fonctions JavaScript permettant la mise en place d'applications cartographiques �uides.OpenLayers permet d'a�cher des fonds cartographiques tuilés ainsi que des marqueurs prove-nant d'une grande variété de sources de données.

ExtJs Ext est une bibliothèque Javascript permettant de construire des applications web interac-tives. C'était au départ une extension à la bibliothèque Javascript YUI de Yahoo, Ext peutmaintenant être utilisée avec les bibliothèques Prototype, JQuery ou encore toute seule.

http://www.espace.ird.fr/04_fiche_crisp.htm

Stage de �n d'études Rapport de stage

2 Résumé

Ce document rend compte de mon stage de �n d'études à l'Institut de Recherche pour le Déve-loppement de Nouvelle-Calédonie en partenariat avec l'Université de Nouvelle-Calédonie.

Ce stage s'intègre dans un programme environnemental et porte sur la mise en place d'un outild'aide à la décision intégré dans un système d'information pour le Vanuatu.

Ce travail s'est fait parmi deux équipes, dans l'unité de service (US 140) ESPACE 1 de l'IRD 2

et au sein du pôle pluridisciplinaire de la matière et de l'environnement(PPME) de l'UNC 3.

D'une durée de 6 mois, le stage s'est vu décomposé en 3 parties.� Une première concernant l'architecture de l'outil (d'une durée de 2,5 mois),� une seconde concernant les données associées (d'une durée de 2,5 mois),� la mise en place �nale du système (d'une durée d'un mois).Il en résulte la mise en place du système d'information environnemental qui sera présenté dans

le courant du mois d'octobre à Vanuatu lors d'une mission sur le terrain.

1. Expertise et SPAtialisation des Connaissances en Environnement2. Institut de Recherche pour le Développement3. Université de Nouvelle Calédonie

Auteur: Alban Diguer ESIL - Informatique 7 sur 45

mailto:[email protected]


3 Sujet et contexte

3.1 Sujet du stage

3.1.1 Contexte

Les îles du Paci�que sont largement tributaires, pour leurs besoins de subsistance, des récifscoralliens et des habitats associés, de la protection côtière et du développement économique.

L'IRD a mis en place le programme GERSA 4/CRISP 5 dont l'objectif est de doter les collectivitésdes moyens nécessaires pour leur permettre de mettre en place des actions e�caces de préservationet de gestion de la biodiversité marine et les aider à accomplir une utilisation durable des ressourcesmarines.

Au travers GERSA, plusieurs organismes se mobilisent pour mettre en oeuvre des approches spa-tiales et intégrées des territoires(territorialité et valeur socio-économique), un système d'informationenvironnement & modélisation et, en�n, la dynamique et la modélisation hydrologique des bassinsversants.

Les actions plani�ées dans le cadre de ces projets devront concerner les actions de cartographiedes risques et des dégradations écologiques, des études de cas et sites de démonstration, de la mo-délisation et la mise en place d'un système d'information environnemental pour la gestion intégréelittoral/bassin versants et la plani�cation : du local au national.

3.1.2 Sujet initial

Voici le sujet initial tel que décrit dans l'o�re de stage.

L'objectif du stage consiste à mettre en place un entrepôt de données distribuées etinteropérables pour la gestion intégrée du littoral du Vanuatu.

� Compilation des données existantes (organisation et structuration de l'information),� Mise en place d'un système d'information distribué interopérable,� Structuration de la coordination des di�érents services techniques du Vanuatu.

3.1.3 Sujet réel

Voici quelques éléments de précision pour étayer le sujet initial.

La problématique globale est la suivante. L'IRD doit mettre en place, dans le cadre de sonprogramme GERSA, un système d'information environnemental (abrégé SIE) pour le Vanuatu.

Il comportera deux éléments.� Un serveur de données interrogeable de manière interopérable. Il inclura les données récupéréessur un outil SIG 6 vieillissant en fonctionnement à Vanuatu(VanRis) ainsi que les données pro-duites par l'institut lors de ses travaux. Par exemple des couches de données ont été produitesconcernant l'étude de l'érosion et la gestion des bassins versants.

� Un outil dit d'aide à la décision permettant d'interroger des serveurs de données interopérables.Dans notre cas, c'est une application permettant d'a�cher (mapper) et de croiser ces donnéesgéographiques distantes récupérées de manières interopérable sur des serveurs de données.

4. GEstion intégrée des bassins versants/littoral Récifal : du Satellite à l'Acteur5. Coral Reef Initiative for the South Paci�c6. Système d'Information Géographique




Voici une vue du système à mettre en oeuvre pendant mon stage




3.2 Présentation de l'organisme et du service

3.2.1 Institut de Recherche pour le Développement et unité ESPACE

L'Institut de Recherche pour le Développement (anciennement ORSTOM) est un établissement àcaractère scienti�que et technologique, placé sous la double tutelle des ministères chargés de laRecherche et de la Coopération. L'IRD remplit trois missions fondamentales : la recherche, l'expertiseet la formation.

L'institut dispose de 36 implantations :� 26 dans des pays situés essentiellement dans la zone intertropicale,� 5 en France métropolitaine : Paris, Bondy, Montpellier, Brest et Orléans,� 5 outre-mer : Guyane, Polynésie française, Martinique, La Réunion et la Nouvelle- Calédonie.

L'évolution des moyens d'observation de la Terre, l'apparition d'enjeux nouveaux (scienti�ques,technologiques, industriels, de coopération, commerciaux . . .) et l'émergence d'une demande socialeforte pour des approches globales en environnement nécessitent la mise en oeuvre d'expertises multi-disciplinaires, une plus grande maîtrise des géotechnologies et le développement de méthodes intégréesd'aide aux processus de décision en environnement.

Dans ce contexte, l'Unité de Service 140 Expertise et SPAtialisation des Connaissances en Envi-ronnement (Espace) a pour vocation de développer des méthodologies innovantes de spatialisationdes connaissances sur l'environnement tropical, par télédétection et approche intégrée, depuis l'ac-quisition des données jusqu'au processus décisionnel. Il s'agit notamment de

� spatialiser des données issues des satellites d'observation de la Terre pour créer des indicateurs,produits spaciaux thématiques et des informations pertinentes qui permettront d'observer,de comprendre et de gérer des milieux tropicaux fragiles faisant l'objet d'enjeux locaux etrégionaux.

� Appréhender, par des approches géographiques des territoires et des paysages, les probléma-tiques environnementales et les logiques d'acteurs et ainsis participer à la mise en oeuvred'approches intégrées de développement durable à l'échelle locale.

� Intégrer des sources d'informations hétérogènes, partager des représentations et rapprocher lesacteurs pour permettre la mise en place de scénarios d'aide à la décision.




3.2.2 UNC et PPME

L'université de Nouvelle-Calédonie est une des rares universités françaises à taille humaine. En 2008,elle compte 2800 étudiants et 82 enseignants-chercheurs et enseignants.

Ses missions sont :� la formation initiale et continue� la recherche scienti�que et technologique et la valorisation des résultats� la di�usion de la culture et de l'information scienti�que et technique� la coopération internationale� l'orientation et l'insertion professionnelle

Divers laboratoires de recherches sont rattachés à l'université, dont le Pôle Pluridisciplinaire de laMatière et de l'Environnement (PPME) avec lequel je partageais les locaux à l'université, participantà certains projets ponctuellement.

3.3 Rôles occupés dans les services

En coordination avec l'équipe de l'UNC mon rôle était� d'appréhender l'existant concernant l'outil d'a�chage et de croisement des données,� de participer au développement du produit,� et adapter l'outil à mon cas d'étude.

Au sein de l'IRD, mon rôle était de me mettre en relation avec les di�érentes personnes de l'unitéESPACE pour

� recueillir des informations,� comprendre le contexte social, géographique et plus largement le contexte métier de l'applica-tion,

� récupérer les données,� mettre en place l'entrepôt et insérer les données.

Ce sont donc deux rôles complémentaires qui traitent des deux grands aspects du système d'in-formation.




4 Description détaillée du sujet

4.1 Travaux à réaliser

Revenons sur les travaux à réaliser. Nous pouvons les regrouper en deux thématiques.

1. Architecture du système et développement logiciel.

2. Recueil de données et intégration dans l'entrepôt

4.1.1 Architecture du système et développement logiciel

Ces travaux sont pour certains des travaux � au �l de l'eau �et s'intègrent dans un travail globalde l'équipe de développement à l'université.

Tâche PrécisionsConsulter la documentation technique deJavaScript et ses librairies JQuery etOpenLayersTutoriel GeoServer, prise en main des ou-tils

Mettre en place une architecture basiqueidentique à celle de notre application

Etudier l'architecture Utilisation des briques logicielles, clari�ca-tion, objectifs, documentation, interfaces,dé�nition du domaine, de l'applicatif etc.

Documenter l'architectureOptimiser les chargements et sécuriser lecode

Mini�er 7, date d'expiration headers,charge serveur

Comparer et décider de l'utilitaire de do-cumentation

Comparer les solutions NaturalDocs, JS-Doc . . .et les présenter au groupe de tra-vail

Participer aux réunions de projetDévelopper certains points Refactoring, traitementsAméliorer les performances au chargement Tests de chargement, recherche de solu-

tion, tentatives d'adapter un code asp,mise en place de la solution et rapport detests

Identi�er les CMS multisite viables A présenter lors de la réunion du portailscienti�que

Mettre en place le serveur de données etcon�guration

Tomcat, Apache, owsProxyServer, créerles niveaux de restrictions . . .

Travailler sur la sécurité des données Gérer les droits d'accès aux couches du ser-veur de données Vanuatu

Quelques précisions sur les éléments clés.

Etude et document d'architecture Sur la demande de l'IRD et de la CPS, il fera o�ce depremier livrable du stage. Celui-ci détaille les aspects techniques globaux de l'application, les méca-nismes, concepts et pattern mis en jeu.




Optimisation du chargement L'application sera utilisée dans des milieux très contraints tech-nologiquement. Le débit internet usuel à Vanuatu est de 56KBps. Il faut donc prendre ce paramètreen compte et optimiser tant que possible le chargement de l'application. Nous verrons plus loin dansce rapport quelles ont été les décisions prises.

Gestion de la sécurité Le concept d'interopérabilité implique deux points� L'échange de données est normé. On utilise des standards de communication dé�nis par uneentité tierce qui en a la charge.

� Les acteurs gardent le contrôle de leur donnée. L'idée est e�ectivement que les organismes quiinteragissent puissent conserver la propriété de leurs données et les localiser où bon leur semble.Ils ne fournissent que le service de di�usion.

Comment donc gérer cette question de la sécurité des données ?

La gestion du cycle de vie L'outil étant imbriqué dans un projet global de l'université. Laquestion du cycle de vie paraît essentielle. Gestion de branches, releases, déploiement, des élèmentsdont nous parlerons plus loin dans le document.

4.1.2 Recueil de données et intégration dans l'entrepôt

Voici le tableau des tâches

Tâche DescriptionIdenti�er les acteursExtraire les couches, analyser VanRisMétadonnéesAssister au séminaire SIG/IRD Concepts interopérabilité, donnée, pro-

priétéDocumenter pour IRD et CPSMettre en place l'entrepôtInsérer les couchesGérer les cycles de vie Stockage à terme etc.

L'extraction des couches Une application étant déjà utilisée sur place, il s'agît de produire uneapplication qui présente à minima les données déjà présentes. L'application en question est de typeStandAlone et non communicante. Il faut donc récupérer les données intéressantes dans les sourceset réaliser la migration vers la nouvelle application.

Documenter la donnée Ce document sera le second livrable pour l'IRD et la CPS, il spéci�erala donnée existante, les normes utilisées et protocoles d'échanges.

Gestion du cycle de vie La question du cycle de vie des données est également à se poser.Comment vit la donnée, comment la di�use-t-on ? comment la pérennise-t-on ?




4.2 Description de l'existant, état de l'art

Lors de mon arrivée, Sébastien Pouillet, ingénieur à la DTSI 8 en détachement à l'UNC avaitétabli un premier prototype d'application pour l'a�chage de données géo référencées à partir d'unnavigateur internet. Nous appelons ça un outil de webmapping.

Cet outil permet déjà plusieurs choses.� A�cher un fond de carte� A�cher une liste des serveurs à attaquer� Lister les couches de ces serveurs� Zoomer sur la carte� Ajouter une couche de données� Supprimer une couche de données

Il est déjà donc relativement abouti et permet d'e�ectuer l'essentiel des actions dont a besoin.Voici des éléments par lesquels il doit être complété.

� Optimiser le chargement� Faire un code maintenable� Protéger le code de l'application� Spéci�er l'outil pour une zone� Mettre en place le stockage de la donnée� Sécuriser l'accès aux données� Gérer les cycles de vie

Concernant la donnée l'état, de l'art est assez simple. Des données sont conservées sous di�érentsformats et supports, il y a donc un travail prospection, recueil, réparation et uniformisation. Ontrouvera des données sous les formats et supports suivants,

� Sur dvd, couches produites sur des logiciels propriétaires de type ArcGIS� Sur les serveurs du Land Departement et Fishery Departement à Vanuatu� Intégrées dans les sources de l'application lourde VanRis déployées à Vanuatu

8. Direction des Technologies et Services de l'Information




4.3 Solutions envisageables, choix des solutions et raisons

Les solutions envisageables se discutent sur autant de points que d'éléments à apporter à l'appli-cation. Revenons sur ces points

4.3.1 Optimiser le chargement

Notre application est une application web. Ce type d'application autrement dénommé � appli-cation client-léger �permet en général d'être maintenu facilement et est utilisable par le biais d'unnavigateur internet. Cependant, la nature même de l'application impose à l'utilisateur de devoircharger l'application avant de pouvoir débuter l'utilisation, frein considérable dans certains cas.

Rappelons que les états insulaires du paci�que ont des débits internet assez faibles. Il faut doncmettre l'accent sur l'optimisation du chargement. Par là nous entendons qu'il faut trouver un outild'évaluation de la charge (outil de benchmarking) puis faire ressortir les critères ralentissant et en�nmettre les solutions en place. Les solutions envisageables sont celles-ci.

� Limiter le nombre de librairies externes� Limiter la taille du code� Diminuer le nombre de requêtes http� Utiliser les content delivery network (CDN)� Utiliser le système de cache dès que possible� Utiliser la compression gzip� Ajouter des en-têtes http qui expirent loin dans le futurVoici un tableau présentant ces solutions, leur utilisation ou non et la justi�cation.

Solution Retenue Justi�cation

Limiter le nombre de librairiesexternes

oui La taille des librairies JavaScript

Optimiser la taille du code oui aucun inconvénient à noterDiminuer le nombre de re-quêtes http

oui

Utiliser les content deliverynetwork (CDN)

oui Ce sont des lieux � in the cloud �de stockage deslibrairies connues

Utiliser le système de cachedès que possible

oui

Utiliser la compression gzip oui C'est une optimisation proposée par le serveurhttp Apache

Ajouter des en-têtes http quiexpirent loin dans le futur

non Cette méthode qui consiste à rajouter une dated'expiration éloignée pour les �chiers dans lacon�guration du serveur apache permet de maxi-miser la période pendant laquelle un �chier resteen cache. Le problème évident intervient lors-qu'une mise à jour doit-être faite, cela nécessitede modi�er tout ou partie le nom des �chiers.

4.3.2 Faire un code maintenable

Un enjeu important est de produire un code maintenable, chose non nécéssairement évidente avecdu JavaScript, langage réputé pour son obscurité, il est faiblement typé, très permissif et donc peut




sou�rir rapidement d'illisibilité. Plusieurs solutions s'o�rent à nous pour faciliter la maintenance ducode.

� Utiliser des librairies JavaScript qui s'articulent bien,� Utiliser des patterns architecturaux (type Model-View-Controller 9) dans le code,� Utiliser un JavaScript orienté objet.

4.3.3 Protéger le code de l'application

La licence �nale n'ayant pas encore été déterminée il s'agît de protéger temporairement le code,nous verrons par la suite que ce point est rejoint l'optimisation du chargement. Comment prémunirle code d'une copie par un oeil extérieur, les composants essentiels de l'application sont écris enJavaScript et sont par conséquent téléchargés et accessibles par quiconque utilise l'application. Lasolution envisageable est de pratiquer une � mini�cation 10 �du code avec suppression des espaces,des commentaires, tout ce qui ne rentre pas dans la � logique applicative �et de modi�er les nomsdes variables. Par exemple

1 maclasse {2 var mavariable = ’value’;3 }

devient

1 a{var b=’value’;}

4.3.4 Spéci�er l'outil pour une zone

L'outil d'aide à la décision pour le Vanuatu hérite d'un sous-ensemble des fonctionnalités dugeoportail global en développement à l'université. Comment fait-on vivre ces deux projets ? Le projetde geoportail UNC est en développement au sein d'un dépôt subversion, qui est un gestionnaire deversionning. On pourra donc utiliser la copie/modi�cation du code dans un répertoire de déploiement,le � fork 11 �de versions stables du projet avec des fusions de code dans la branche lors des mises àjour.

4.3.5 Mettre en place le stockage de la donnée

La question du stockage de la donnée est un aspect important de l'application. L'essentiel desdonnées récupérées sont des �chiers � shape�le 12 �. Les deux solutions possibles pour le stockage duserveur sont

� Conserver le �chier shape�le qui est lu par le serveur de donnée.� Intégrer les shape�les dans une base de donnée PostgreSQL+ PostGIS.

9. Model-View-Controller(MVC) : Méthode qui organise l'interface homme machine d'une application logicielle10. réduction11. bifurcation : on crée un nouveau projet à partir d'un autre à l'identique, sans détruire celui-ci12. Shape�le(extension shp) : Fichier de formes, c'est un format issu du monde des Systèmes d'informations Géo-

graphiques devenu un standard. Il contient toute l'information liée à la géométrie des objets décrits qui peuvent êtredes points, lignes ou polygones.




4.3.6 Sécuriser l'accès aux données

La notion d'interopérabilité et de réseau de donnée n'impose en rien de partager sa donnée avectout le monde. Aussi il faut proposer de pouvoir attribuer des droits de lecture sur certaines couchesde données.

4.3.7 Gérer les cycles de vie

Ce projet arrive dans la phase de mise en production, il faut donc gérer deux choses correctement.Le cycle de vie de la donnée d'une part, une mise à jour d'une base de donnée ou du serveur doitêtre possible et nous devons garantir la pérennité des données lors de l'opération. Le cycle de vie del'application d'autre part, pour proposer des versions stables et limiter le déni de service.




4.4 Description technique de la solution choisie

4.4.1 Optimiser le chargement

Plusieurs éléments sont associés pour parvenir à un résultat correct.

Le premier élément est le service qui permet de réduire la taille du code, .

Lorsque l'utilisateur accède à l'application, il doit charger celle-ci. Il e�ectue donc, après avoir regardédans le cache du navigateur, une requête HTTP qui permet de demander le �chier au serveur. C'està ce niveau que l'on fait intervenir le service de mini�cation. Deux cas se présentent

� Le serveur possède dans son cache une version déjà mini�ée du �chier et renvoi cette versionau navigateur.

� Le serveur ne possède pas encore ce �chier dans son cache, il récupère donc le �chier concernédans le répertoire, e�ectue le traitement dessus, en place une copie dans le cache et retournele résultat au navigateur.

Ce service de mini�cation est couplé à la possibilité de diminuer le nombre de requêtes HTTP,par exemple dans le code de l'application nous avons ceci.

1 <script type="text/javascript" src="scripts/ifrecor-app.js"></script>2 <script type="text/javascript" src="scripts/ifrecor-ol.js"></script>3 <script type="text/javascript" src="scripts/ifrecor-layout.js"></script>4 <script type="text/javascript" src="scripts/feature-popup.js" charset="utf-8"></script>

Soit 4 �chiers JavaScript contenant l'essentiel du code de l'application appelés consécutivementpar requête http. Le serveur Apache HTTP ne sait pas paralléliser le traitement des requêtes HTTP.

Analyse du tra�c réseau

Il serait donc pro�table de faire un appel http unique pour diminuer le phénomène de queuing.Le service de mini�cation permet cela. Voici l'appel qui remplace le précédent.

1 <script type="text/javascript" src="/min/?g=ifrecor"></script>




Et l'on dé�nit dans le service un � groupe �de �chiers sous l'appellation � ifrecor �. Le serveurréceptionne alors cet appel de type GET sur l'adresse http ://serveur/application/min/ avec enparamètre g ayant la valeur groupe. Il retourne au navigateur ces 4 �chiers JavaScript mini�és etregroupés en un seul.

Analyse du tra�c réseau

On peut ainsi procéder à plusieurs regroupements de �chiers.

Dans les faits on regroupe les �chiers qui ne concernent que le code spéci�que à l'application.Par exemple on ne pratique pas de regroupement sur les librairies externes de types ExtJS, JQueryetc. La raison vient de la possibilité o�erte par des � géants �de l'internet tels que Yahoo ou Googled'héberger les librairies largement connues et utilisées. Deux grands avantages à utiliser cette méthode

� Pro�ter de la qualité des serveurs de ces fournisseurs, on peut supposer que les librairies sontmises à disposition sur des serveurs à très hauts débits et le chargement se fera en conséquenceplus rapidement.

� Eviter de charger plusieurs fois la même librairie dans certains cas. Par exemple si l'utilisateura auparavant parcouru la toile et a chargé la librairie ExtJS par le CDN 13 de Google alors iln'aura pas à le recharger, la réponse sera de type 304 Not modi�ed. Ci dessous une méthoded'appel au CDN de Google, on spéci�e la librairie à intégrer ainsi que la version, plusieurs sontdisponibles.

Par exemple pour la librairie JQuery dans sa version 1.3.2 en utilisant le CDN de Google, nousobtenons.

1 <script src="http://www.google.com/jsapi"></script>2 <script>3 //Load jquery4 google.load("jquery", "1.3.2");5 </script>

4.4.2 Factoriser le code et faire un code maintenable

Nous utilisons des libraires phares du langage� JQuery et ExtJs pour la manipulation du DOM, de l'Ajax et faire une application web2.0 (pasde rupture de la navigation)

� OpenLayers outil permettant la manipulation dynamique de cartes dans une page WebBien que ce langage soit orienté objet, il di�ère considérablement des langages objet classiques telsque Java et C++ puisqu'il se fonde sur une variante de ce paradigme, à savoir la programmationorientée objet par prototype. Cette variante propose entre autres que l'héritage soit possible entreclasse mais aussi entre objets et il permet de modi�er la structure des objets après leur instanciation.Voici donc le diagramme d'objet qui décrit l'articulation du programme en exécution, le diagrammede classe n'étant pas su�sant.

13. CDN : Content Delivery Network




4.4.3 Protéger le code de l'application

La protection du code reste encore un point en suspend, elle ne sera motivée que par le choix dela licence �nale. Une licence privative n'étant pas le meilleur choix à terme, il convient cependant defermer la lecture du code le temps que cette question soit réglée.

Une piste possible est abordée en amont dans la partie � optimiser le chargement de l'applica-tion �nous avons vu que lors du processus de mini�cation nous pouvons supprimer les commentaires,et modi�er/simpli�er les noms de variables. Cela permet clairement de réduire la compréhension/-copie du code par un oeil extérieur.

4.4.4 Spéci�er l'outil pour une zone

La zone qui nous intéresse est le Vanuatu. L'outil existant n'est pas adapté à une zone en parti-culier, il peut convenir pour n'importe quelle région géographique. Par conséquent il doit être assezgénérique pour que l'on puisse l'adapter à une zone en particulier assez rapidement. La solutionutilisée est la dé�nition regroupée des éléments permettant de dé�nir une zone géographique dansune variable contenue dans l'objet de gestion des cartes. Voici la variable utilisée pour le Vanuatu.

1 var geographicZones = [2 {URLParamName:"vanuatu",3 projection:’EPSG:45555’,4 maxExtent:new OpenLayers.Bounds(166.54035949707,5 -20.2553405761719,170.239151000977,-13.0722312927246),6 units:’degrees’,7 resolutions:[0.02, 0.01, 0.005, 0.0025, 0.00125, 0.000625, 0.0003125,8 0.00015625, 0.000078125, 0.0000390625, 0.00001953125, 0.000009765625,9 0.0000048828125, 0.00000244140625, 0.000001220703125, 6.103515625e-7],

10 baseLayerName:’gersa_vanuatu:buffer_islands_region’,11 baseLayerURL:"http://gersa.univ-nc.nc:7080/geoserver/wms"},12 {autre zone}13 ]




La variable présente des aspects métiers géographiques tels que la projection utilisée sur cette zone,le compact de coordonnées a�ché, l'unité et la projection.

4.4.5 Mettre en place le stockage de la donnée

L'université met à notre disposition une machine virtuelle dédiée au système. Outre l'application,nous y déployons le serveur de gestion des données, GeoServer. GeoServer un serveur open sourceécrit en Java qui permet à l'utilisateur de partager et d'éditer de la donnée geospatiale. Conçu dansune optique d'interopérabilité, il reprend et implémente les normes et standards déterminés parl'OGC.

Ce serveur fonctionne à travers le serveur d'application Tomcat, en déployant très simplement laWeb Archive correspondante.

1 root@gersa:~# cd /usr/share/tomcat6/2 root@gersa:~# sh /bin/shutdown.sh3 root@gersa:~# cd /webapps/4 root@gersa:~# wget http://path/geoserver.war5 root@gersa:~# sh ../bin/startup.sh

Pour des questions d'optimisation, le serveur Apache utilisé n'est pas celui contenu dans Tomcat,celui-ci étant une version allégée, nous avons un Apache StandAlone et un Tomcat démarré sur unautre port, la redirection des requêtes est dé�nit dans les �chiers de con�guration d'Apache.

Voici la description dans le �chier de con�guration

1 ProxyPass /geoserver/ http://gersa.univ-nc.nc:7080/geoserver/2 ProxyPassReverse /geoserver/ http://gersa.univ-nc.nc:7080/geoserver/

Tous les accès à /geoserver/ sont envoyés sur l'adresse correspondante. Nous démarrons le serveurTomcat sur le port 7080 et on peut éventuellement rajouter un load balancing par le module Apachenommé Modjk qui utilise le paradigme du worker. Un worker est une instance de Tomcat lancée pourtraiter les requêtes de servlets en provenance du serveur web.

4.4.6 Sécuriser l'accès aux données

Les services OGC actuels sont des standards ouverts pour la géomatique, interopérables (WMS,WFS) mais ne sont pas sécurisés et ne disposent pas de contrôles d'accès. Les besoins sont clairs




� Garder la compatibilité (pour que l'utilisateur garde sont client standard OGC, Mapserver,QGIS, ArcGIS . . .)

� L'accès au services doit être contrôlé et la sécurité assurée

L'implémentation d'une solution requiert les critères suivants� Fonctionnelle avec les clients existants� Simple à implémenter� Portable et facile à déployer� E�cace� S'adapte aux contraintes d'environnements existantes� Sure� Permettant des restrictions simples d'accès

La solution technologique choisie permet l'encapsulation HTTP en utilisant une authenti�cationpar utilisateur et mot de passe et l'encryptage SSL pour prévenir des écoutes clandestines.

Côté serveur nous avons un servlet Java. La validation du couple nom d'utilisateur/mot depasse se fait sur la base d'un �chier XML. On fait une journalisation des demandes dans un �chier(utilisateur, temps, paramètres des requêtes, . . .) et un �ltrage pour le contrôle d'accès (couchedemandée et la zone pointée BBOX).




Concernant la politique de sécurité, prenons un exemple sur le GetMap nous pouvons véri�er lesaccès sur les couches, la zone la hauteur max et la largeur max pour restreindre l'étendue d'a�chage

Ces critères sont véri�ables en pré condition (non transmission de la requête au serveur) ou enpost condition (modi�cation de la réponse du serveur).

On peut ainsi paramétrer les rôles, services et restrictions (voir en Annexe � Connexion et gestiondes droits d'accès �).

4.4.7 Cycle de vie de l'application

Le cycle de développement adopté se rapproche du modèle itératif. On y distingue 4 phases� la faisabilité : l'acceptation d'un nouveau besoin� l'élaboration : on imagine comment on va le réaliser� la fabrication : construction� la transition : tout est mis en oeuvre pour livrer au clientD'un point de vue plus pragmatique, l'outil subversion permet de gérer le cycle de vie, créer et

fusionner les branches et marquer les releases de simplement. Par exemple lors d'une release, il n'y àqu'à marquer (tag) une certaine version comme release et e�ectuer un � checkout �de la version pourdéployer l'application. Dans le système de branches, des � merges 14 �sont possibles entre brancheset tronc pour gérer les modi�cations au cas par cas entre les di�érentes versions de l'application.

4.4.8 Cycle de vie de la donnée

Le cycle de vie désigne toutes les étapes de la vie de la donnée, de sa création à sa disparition.Dans le contexte métier géographique on peut discerner les étapes suivantes.

� Décision de pertinence� Analyse terrain� Création de la donnée� Stockage de la donnée� Modi�cation de la donnée� Perte de la donnée

Qui donne l'automate suivant réduit à ses 4 états principaux.

14. fusions




Dans ce projet la donnée provient intégralement de l'IRD, on y retrouve des données très variéestelles que les épicentres de séismes, la position des batîments ayant rapports avec la santé ou encoreles points d'ancrages de bateaux.

Le stockage est momentanément localisé à l'Université de la Nouvelle-Calédonie sur une machinevirtuelle. Ce serveur stocke les �chiers GeoTi� et propose le webservice Geoserver. Celui-ci est coupléà une base de donnée PostgreSQL et PostGIS 15

Voir en annexe pour l'insertion des Geoti� dans la base de données

4.5 Méthodes et outils utilisés

4.5.1 Méthodes

UML2 a été utilisé pour représenter la modélisation métier de l'application ainsi que le conceptdu domaine.

La méthode de gestion du cycle de vie est de type RUP, c'est d'ailleurs le plan dé�ni dans cetteméthode qui est utilisé dans le document d'architecture livré à l'IRD et la CPS 16. Nous y retrouvonsles points suivants

� Objectifs� Structure de l'architecture� Comportement� Concepts du domaine� Qualité de l'architecture

15. PostGIS est le logiciel à utiliser avec le SGBD PostgreSQL pour créer des bases de données utilisées par lessystèmes d'informations géographiques.16. Communauté du paci�que Sud




4.5.2 Outils

Pour le travail collaboratif et le versionning nous utilisons subversion, il permet de gérer lesnuméros de versions de �chiers, les branches de projet (très utile dans notre projet qui est intégrédans un projet global) ainsi que la gestion des releases avec les tags qui permettent de déclarer uneversion sous un tag release par exemple.

Pour comprendre l'exécution du programme dans le navigateur du client nous utilisons FireBugqui permet de faire du mode pas à pas, de savoir quels services sont requêtés, quel est l'état de lapile d'exécution ou encore parcourir le DOM.

Concernant l'administration système j'utilise une machine virtuelle Ubuntu qui naturalise laconnexion par ssh, le paramétrage des services etc.

Au sein de l'UNC nous utilisons par ailleurs un portail de gestion des demandes et de suivi debogues nommé Jira ainsi qu'un moteur de wiki aux fonctionnalités avancées, Con�uence qui permetde valoriser l'expérience acquise dans l'équipe et de centraliser l'information.

4.6 Organisation du travail

Ce travail s'est organisé en 3 phases

Architecture Il s'agît dans cette première phase de comprendre et éclaircir le fonctionnement del'application existante pour pouvoir continuer le développement. Un document est produit pourl'IRD allant dans ce sens.

Donnée Il faut expliquer la donnée, sa provenance, sa pertinence, les moyens par lesquels on yaccède, l'endroit de stockage etc. Là encore un document est produit.

Compilation Construction du système global regroupant les deux éléments précédents.




4.7 Planning prévisionnel

Voici le diagramme de Gantt du planning prévisionnel établi au mois d'Avril.




5 Résultats obtenus

5.1 Résultats de mon travail

Mon travail s'est concrétisé par 3 éléments.

La production de deux rapports sur l'architecture et sur les données pour l'IRD et la Communautédu Paci�que Sud (voir en annexe).

La mise en place d'un entrepôt de donnée interopérable consultable à cette adresse.

1 http://gersa.univ-nc.nc:7080/geoserver/

Et par la release de l'outil d'aide à la décision.

Le système d'information sera présenté au client lors de la prochaine mission à Vanuatu qui auralieu mi-octobre.

http ://gersa.univ-nc.nc/http ://grimm.univ-nc.nc/geoportail/vanuatu

Voici un aperçu de la page d'accueil de la plateforme.

Ici le portail thématique en utilisation.


http://gersa.univ-nc.nc/

http://grimm.univ-nc.nc/geoportail/#vanuatu



Ce prototype sera aussi une vitrine à présenter à d'autres pays insulaires dans le cadre de leurdéveloppement.

5.2 Di�cultés rencontrées

Quelques di�cultés à noter.

L'apprentissage du JavaScript et de son paradigme d'héritage par prototype qui sont très permissifpour un � habitué �des langages orientés objets classiques de types Java/C++. Un apprentissagetrop centré sur le langage et qui aurait du à mon sens être plus orienté sur les API et librairies quisimpli�ent énormément le travail.

5.3 Planning réel

Le planning réel assez proche du planning initial si ce n'est la modi�cation des tâches de déve-loppement, le module Comin et le meta moteur de recherche ayant laissé place à la sécurisation ducode et à l'optimisation du chargement sur l'Ifrecor.

5.4 Limites éventuelles

La grande limite restera le manque de contacts client avec le Vanuatu, la connaissance du besoinest primordiale dans un tel projet, la communication avec la personne utilisatrice également.

La recherche de données n'est pas une tâche aisée non plus. La sélection ne peut être faite quepar des personnes dont c'est le métier, il faut donc fouiller sans savoir à priori ce que l'on cherche




pour espérer trouver des couches pertinentes à proposer dans un prototype comme celui-ci.

5.5 Exploitabilité pour l'organisme

Le prototype sera présenté au Land Department et au Fishery Department sous peu lors d'unemission terrain. Il permettra d'exposer le principe général d'interopérabilité appliqué à leur zoned'étude, et donc valoriser cet axe de travail, véritable avenir du SIG dans le monde.

5.6 Suites à donner

Les suites à donner dépendront beaucoup des éléments récupérés lors de la mission terrain quisera faite courant Octobre pour faire évoluer le produit à la convenance du client.

Concernant le cycle de vie des données, il faudra transférer la base de donnée localisée pour lemoment sur une machine virtuelle de l'université sur un serveur dédié (virtuel ou non) localisé àl'IRD ou mieux directement au Fishery Department basé à Port Vila 17.

Une autre piste que je n'ai pas eu le temps d'explorer concerne le load balancing entre les serveursapache et tomcat. On peut ainsi répartir au mieux la charge présente entre les deux services selonleur occupation. (étude du mods jk dans la con�guration d'apache)

Il faudra également continuer d'alimenter le serveur avec des données pertinentes récupérées dansles missions passées et à venir.

5.7 Suggestions à l'organisme

Ma suggestion concerne la dé�nition du sujet, et les premières semaines du stage. L'imbricationdes projets et les termes métiers ne permettent pas à un non initié de rentrer rapidement dans ladynamique, cela s'arrange avec l'utilisation de con�uence et des tutoriaux, c'est une bonne chose.

17. Capitale du Vanuatu




6 Bilan

6.1 Apport à l'entreprise

Mon stage a permis d'avancer ce projet initié il y a des années pour l'emmener à un état quasi-�nal et présentable au client. Je tâcherai de prendre des nouvelles après la mission pour avoir unfeedback des principaux intéréssés, c'est essentiel.

6.2 Apport de l'entreprise

Apprentissage de nouveaux langages et concepts. Découverte de certains aspects métiers géogra-phique tels que les normes d'échanges et les projections. L'écoute est très bonne dans cette équipe,les réunions sont productives et chacun peut y apporter ses idées, c'est valorisant.

6.3 Apport de l'école

L'école apporte une formation générale qui permet de s'adapter à un projet assez particulierréalisé par deux organismes avec une équipe pluridisciplinaires et à vocation environnemental ce quiest très spéci�que. Je pense que l'adaptation des connaissances acquises à l'école est possible sur unetrès large gamme de métiers et projets.

6.4 Retour d'expérience

Ce fût très enrichissant, je pense continuer dans des domaines connexes et apprécie les interfacesinformatique/géographie et informatique/environnement plus largement. Des pistes de recherchepour des futurs emplois . . .

6.5 Si c'était à refaire

Sans hésiter.




A Annexes

A.1 Documents rédigés

A.1.1 Document sur l'architecture

Voici quelques extraits de ce document

Vue des couches

La couche Interface contient les fenêtres et objets graphiques utilisés dans l'application. Ponc-tuellement des accès direct au Domaine sont faits pour un traitement d'a�chage particulier. (Pourl'a�chage des informations sur les stations par exemple).

La couche Application contient la logique applicative du logiciel. On assure dans celle-ci lacohérence des traitements. (Par exemple le retrait logique d'une couche lors de son retrait graphique).

La couche Domaine qui restreint certains aspects pour représenter le domaine de l'application.

Remarque Dans l'état actuel de l'application, le domaine est fortement couplé aux deux autrescouches. Il faudrait envisager à terme d'externaliser les traitements spéci�ques. (Par exemple enplaçant la dé�nition des a�chages spéci�ques dans un �chier xml).

Présentation des briques logicielles utilisées




Dé�nition des briques logicielles

JavaScript est un langage de programmation de scripts principalement utilisé dans les pages webinteractives. C'est un langage orienté objets à prototype.

JQuery est un framework Javascript libre qui porte sur l'interaction entre JavaScript (comprenantl'AJAX) et HTML, et a pour but de simpli�er des commandes communes de Javascript.

MapFish est un framework logiciel permettant l'interconnexion entre di�érentes bibliothèquesparmi lesquelles OpenLayers et ExtJs.

OpenLayers est une bibliothèque JavaScript permettant d'intégrer des cartes dynamiques à uneapplication Web.

ExtJs est une bibliothèque JavaScript permettant de construire des applications Web in-teractives.

GeoServer est un serveur Open Source écrit en Java permettant le partage et l'édition dedonnées géospatiales.

GeoNetwork est un moteur opensource qui permet de partager des informations géogra-phiques thématiques entre organisations.

PostGis est un plugin PostgreSQL pour la création de bases de données utilisées par des SIG 18.

Justi�cations Application client léger web 2

Utilisation de bibliothèques standards (extJs, OpenLayers) permettantes de donner une navigua-tion �uide de type client lourd.

18. SIG : Système d'information géographique


http://jquery.com/

http://trac.mapfish.org/trac/mapfish

http://openlayers.org/

http://extjs.com/

http://geoserver.org/display/GEOS/Welcome

http://geonetwork-opensource.org/



Repose sur une architecture client/serveur.

Permet de maintenir l'application en un seul endroit.

Permet d'attaquer plusieurs serveurs distants de manière interopérable.

Evite une installation de logiciel tiers au client.

L'utilisation de briques logicielles Open Source est également à mettre en avant. Ces briques sonttrès largement utilisées et ont d'importantes communautés. Elles sont et seront supportées à longterme.

Interfaces et Interopérabilité Les communications entre couche client et couche serveur res-pectent des standards OGC. Ils normalisent la manière d'échanger de l'information géographique.On a donc une application qui respecte le concept très puissant de l'interopérabilité.

Concrètement notre application peut attaquer plusieurs serveurs distants et sans échanger d'autresinformations qu'un identi�cateur de la norme et la requête des données.

Sous-systèmes et paquetages Présentation de l'arborescence projet Voici une vue de l'arbores-cence du projet.

Le coeur (core) de l'application se situe dans le dossier /gersa/scripts.

� feature-popup.js Gestion de toutes les popups visibles� ifrecor-app.js Point d'entrée de l'application. Instanciation des élèments (liste des serveurs, descouches, des panneaux) et mise à disposition des données publiques.

� ifrecor-layout.js Dé�nit le layout de l'application� ifrecor-login.js Panel utilisé pour l'authenti�cation. Disjoint de feature-popup.js car module àpart entière.

� ifrecor-ol.js Gestion des couches de données et du fond de carte.




Diagramme objet JavaScript est un langage orienté objet par prototype ce qui signi�e que l'hé-ritage est possible en termes de classes mais aussi d'objets. Par convenance, nous faisons apparaîtreles classes utilisées pour l'instanciation de certains objets.

A.1.2 Document sur les données

Voici quelques extraits du document

Objectif L'objectif est la réalisation d'un outil d'aide à la décision qui permet le croisement d'infor-mations géographiques. Concrètement il s'agît d'a�cher la carte de Efate, l'île principale de Vanuatuen terme de démographie et de pouvoir y superposer des couches de données.

Les couches de données seront stockées sur serveurs distants et les protocoles d'échanges respec-teront les normes de l'OGC 2 pour permettre l'interopérabilité.

2. OGC : Open Geospatial Consortium




Standards et spéci�cations Open Geospatial Consortium L'OGC est un consortium mondial quidé�nit des standards ouverts des contenus, échanges et services dans les domaines de l'informationgeographique. La motivation principale étant de répondre aux problèmes d'intéropérabilité. Il a ainsidé�nit un ensemble de recommandations parmis lesquelles WMS et WFS que nous utilisons.

Recommandation WMS Présentation Web Map Service ou WMS permet de produire des cartesde données géoréférencées à partir de di�érents serveurs de données. Cela permet de mettre en placeun réseau de serveurs cartographiques à partir desquels des clients peuvent construire des cartesinteractives.

Un service WMS sert à retourner une image visualisable sur un écran d'ordinateur. Le serveurproduit des cartes aux formats image comme le JPEG, le PNG ou le GIF, ou sous forme d'élémentsvecteurs comme le SVG. Le WMS s'oppose au WFS qui traite les données elles-mêmes.

Fonctionnement Voici quelques élèments de la spéci�cation.

Les trois opérations disponibles sont celles-ci.� GetCapabilities retourne les méta-données qui décrivent le contenu du service et les para-mètres acceptés,

� GetMap retourne une image d'une carte dont les paramètres géospatiaux et dimensionnelssont correctement représentés,

� GetFeatureInfo retourne des informations sur un objet représenté sur la carte.Le service WMS peut être intérrogé par un navigateur internet. Lorsqu'on envoie la requête,

certaines informations sont à dé�nir.� Les couches à tracer parmis celles disponibles,� Le style des couches,� Le système de référence à utiliser,� La taille de l'image produite,� L'étendue de la carte souhaitée.Construction de la requête Une URL WMS se présente sous la forme suivante

1 http://hote.domaine/chemin?{nom=valeur&}

Où nom=valeur correspond à une liste de paramètres parmis ceux-ci.� VERSION� REQUEST� OUTPUTFORMAT correspond au format de sortie de l'image (exemple : image/png).� BBOX pour l'étendue de la carte.� WIDTH pour la largeur de l'image.� HEIGHT pour la hauteur de l'image.� LAYERS est la liste des couches désirées.� SRS est le système de projection utilisée.� SERVICE nom du service OGC (WMS donc)� STYLES liste des styles utilisés pour chacune des LAYERS� FORMAT le format de la réponse

Voici un exemple d'url :

1 http://grimm.univ-nc.nc/geoserver/wms?bbox=581011.6375,8523419.35,590535.9875,8536963.65&styles=2 &Format=application/openlayers&request=GetMap&version=1.1.1&layers=Wallis:axe_route&width=4373 &height=550&srs=EPSG:32701




Recommandation WFS Présentation Le Web Feature Service ou WFS permet au moyen d'uneurl formatée d'interroger des serveurs cartographiques a�n de manipuler des objets géographiques(lignes, points, polygones. . .).

Fonctionnement WFS propose des interfaces pour la description des manipulations de donnéessur des objets géographiques en utilisant le protocole internet HTTP. On peut ainsi,

� Créer des nouveaux objets,� E�acer des objets,� Mettre à jour des objets,� Prendre ou rechercher des objets sur la base de contraintes spatiales.

La spéci�cation WFS dé�nit 5 opérations pour envoyer des requêtes au serveur et obtenur desinformations :

� GetCapabilitiespermet de connaître les capacités du serveur (quelles opérations sont suppor-tées et quels objets sont fournis).

� DescribeFeatureType permet de retourner la structure de chaque entité susceptible d'êtrefournie par le serveru.

� GetFeature permet de livrer des objets (géométrie et/ou attributs) en GML.� LockFeature permet de bloquer des objets lors d'une transaction.� Transaction permet de modi�er l'objet(création,mise à jour, e�acer).Le mécanisme d'échanges de données GML de l'OGC est utilisé comme base pour les spéci�cations

WFS. De cette façon, des données géographiques et leur schéma correspondant peuvent être codéset transférés en XML.

Construction de la requête Les paramètres données dans l'URL sont parmis ceux-ci� NAME : nom de la couche à interroger,� BBOX : Etendue des données,� VERSION : version du protocole� SERVICE : Type de service à utiliser (WFS)� SRS : Projection utilisée (EPSG 4326 = WGS 84)Voici un exemple d'URL

1 http: //localhost/cgi-bin/mapserv?map=wms/exemple.map&NAME=Europe&SERVICE=WFS&VERSION=1.0.0&2 REQUEST=GetFeature&SRS=EPSG%3A4326&BBOX=-15.82,32.69,33.39,71.36

Données Les données présentées ci-dessous sont celles récupérées sur le logiciel VanRis qui estremplacé par la nouvelle application, à cela on ajoutera des cartes du modèle USLE qui tourneactuellement sur Efate.




A.2 Liste des couches de données

Nom de la couche Provenance Présence des tables attributaires Metadonn ées

Bu�er_Island_rectangle VanRisBu�er_Islands_region VanRis

MI_Airports_font_point VanRisMI_Anchorages_font_point VanRis

MI_Beach_Landings_font_point VanRisMI_Boreholes_point VanRisMI_Coastline_point VanRis

MI_Coastline_polyline VanRisMI_Coastline_region VanRisMI_Coastline_text VanRis

MI_Conservation_Areas_ellipse VanRisMI_Conservation_Areas_region VanRis

MI_Contours_polyline VanRisMI_Earthquake_Epicentres_point VanRis

MI_Health_font_point VanRisMI_Health_none VanRis

MI_Islands_Filled_region VanRisMI_Language_Areas_region VanRisMI_Language_Areas_text VanRis

MI_Logging_Concessions_region VanRisMI_Marine_Zones_polyline VanRis

MI_Mineral_Exploration_region VanRisMI_Navigation_Aids_font_point VanRis

MI_Overview_region VanRisMI_Place_point VanRisMI_Rainfall_point VanRisMI_Rivers_point VanRis

MI_Rivers_polyline VanRisMI_Rivers_region VanRisMI_Rivers_text VanRisMI_Rmu_region VanRisMI_Roads_point VanRis

MI_Roads_polyline VanRisMI_Schools_font_point VanRis

MI_Schools_none VanRisMI_Tenure_region VanRis

MI_Volcanic_Hazards_rectangle VanRisMI_Wharves_font_point VanRis

K USLE IRD oui ouiC USLE IRD oui ouiR USLE IRD oui ouils USLE IRD non oui

dem USLE IRD non ouiFormosat Formosat

Description des couches Voici pour chaque couche un aperçu du rendu sous ArcMap et una�chage de la table attributaire.




Couches récupérées sur VanRis La première couche sera utilisée comme fond de carte pourtoutes les suivantes.

Bu�er_Islands_region

Bu�er_Island_rectangle




A.3 Description du produit

A.3.1 Aide en ligne - Fonctionalités

Ajouter des couches

Naviguer sur la carte




Contrôles et outils




A.3.2 Captures d'écran

En cliquant sur � Ajouter des données �un panneau de sélection des entrepôts apparaît parmilesquel l'entrepôt de notre projet.

Lorsqu'on double clic sur une couche, celle-ci s'ajoute sur la carte.

On peut répéter l'opération sur toutes les couches de la zone, déplacer les couches dans l'arborescencepour modi�er le plan d'a�chage de celles-ci et modi�er l'opacité.

A.4 Exemples de code

Voici quelques exemples choisis sur des aspects techniques et métiers.




A.4.1 Amélioration des performances de l'application

minify, opti serveur YUISlow, protection du code

A.4.2 Intégration des données dans GeoServer

Ci-dessous la procédure de stockage des shape�les 19 dans l'outil PostGIS agrégé à PostgreSQL.

Connexion à la base

1 psql -U user -h host -d dbname

Utilisation de shp2pgsql pour convertir le shape�le en �chier sql

1 shp2pgsql -s 45555 file.shp > file.sql

L'option -s permet d'ajouter le SRID qui correspond au mode de projection utilisé pour cette par-tie du globe. La projection cartographique est le processus qui consiste à transformer et à représentersur une surface bidimensionnelle (plane) des points situés sur la surface sphérique tridimensionnellede la terre. Ce processus fait appel à une méthode directe de projection géométrique ou à uneméthode de transformation calculée mathématiquement.

On obtient par ce processus autant de �chiers sql que de shape�les initiaux, par exemple pour leprojet.

Une fois les �chiers convertis il reste à les insérer dans la base en lisant le �chier.

1 psql -d nom_de_la_base -f file.sql

Il reste ensuite à réaliser l'import dans Geoserver. Sur notre serveur Geoserver est deployé sur leport 7080.

1 http://gersa.univ-nc.nc:7080/geoserver/welcome.do

19. Le shape�le, ou � �chier de formes �est un format de �chier issu du monde des Systèmes d'Informations Géo-graphiques



Puis par le panneau de con�guration on réalise l'import des données existantes dans la base.

A.4.3 Internationalisation par Javascript

L'internationalisation de la page d'accueil du projet a été réalisé avec la librairie JQuery et desa fonction toggle() qui permet d'inverser l'état :display d'un élément du DOM.

1 <html>2 <head>3 ..4 5 <script src="http://www.google.com/jsapi"></script>6 <script>7 //Load jquery8 google.load("jquery", "1.3.2");9 </script>

10 <script type="text/javascript">11 // Lorsque la page est chargée12 $(document).ready(function(){13

14 // Automate d’affichage/disparition en fonction de la langue15 $("#flagFR,#flagEN").click(function() {16 $(".fr,.en").toggle();17 });18

19 });20 </script>21 </head>22 ..23 <body>24 25 <div id="flag">26 <a href="#"><div id="flagFR" class="en"></div></a>27 <a href="#"><div id="flagEN" class="fr"></div></a>28 </div>29

30 31 <div id="title">32 <span class="fr">Système d’information environnemental pour le Vanuatu</span>33 <span class="en">Vanuatu environmental information system</span>34 </div>35


36 ..37 </body38 </html>

Et le css qui dé�nit la langue par défaut lors du chargement de la page

1 .fr {2 display: none;3 }4

5 .en {6 /*display: none;*/7 }

Le résultat est visible à l'adresse suivante

http ://gersa.univ-nc.nc

A.4.4 Connexion et gestion des droits d'accès

Dé�nition des rôles, dans tomcat-users.xml

1 <?xml version=’1.0’ encoding=’utf-8’?>2 <tomcat-users>3 <role rolename="power_user"/>4 <role rolename="normal_user"/>5 <user username="puser" password="puser" roles="power_user, xxx"/>6 <user username="nuser" password="nuser" roles="normal_user, xxx"/>7 </tomcat-users>

Paramétrage d'un service

1 <service serviceId="wms" serviceDescription="IVS restreint"2 serviceEndPoint="http://prod.swisstopogeodata.ch/wms-ivs/?" >3 <roles>4 <role>power_user</role>5 <role>normal_user</role>6 </roles>7 </service>

Ici on ne dé�nit aucune restriction mais authenti�cation, cryptage et journalisation des requêtesdans un �chier de log.

1 <?xml version="1.0" encoding="UTF-8"?>2 <OWSPolicy service="WMS" xmlns="http://www.deegree.org/security">3 <Security></Security>4 <Requests>5 <GetMap>6 </GetMap>7 <GetFeatureInfo>8 </GetFeatureInfo>9 <GetCapabilities>

10 </GetCapabilities>11 </Requests>12 </OWSPolicy>

Voici une restriction générique indépendamment du rôle


http://gersa.univ-nc.nc



1 <GetMap>2 <PreConditions>3 <Parameter name="bbox">4 <Value>-93,25,-66,53</Value>5 </Parameter>6 </PreConditions>7 <PostConditions>8 </PostConditions>9 </GetMap>

Restriction dépendant du rôle

1 <GetMap>2 <PreConditions>3 <Parameter name="bbox">4 <Role name="role1">5 <Any />6 </Role>7 <Role name="default">8 <Value>-93,25,-66,53</Value>9 </Role>

10 </Parameter>11 </PreConditions>12 </GetMap>

