Partage et Visualisation des données géologiques et minières du projet WAXI

Transcription

1 Université de Toulouse MASTER 2 GEOMATIQUE Parcours Professionnel : «Science de l Information Géoréférencée pour la Maîtrise de l environnement et l Aménagement des territoires» (SIGMA) RAPPORT DE STAGE Partage et Visualisation des données géologiques et minières du projet WAXI De Boyer Guillaume Maître de stage : Mark Jessell Tuteur-enseignant : Laurent Jégou Septembre 2011

2

3 SOMMAIRE Résumé...2 Abstract...2 Remerciements...3 INTRODUCTION CONTEXTE DU STAGE 1 - Géoscience Environnement Toulouse (GET) Institut pour la Recherche et le Développement (IRD) Projet WAXI...7 A. Infrastructure de Données Spatiales I EXPRESSION INITIALE DES BESOINS 1 - Vision du projet Exigences fonctionnelles...11 II PROTOTYPE 1 - Environnement de Travail Solutions techniques SERVEUR Solutions techniques CLIENT Réalisation de l'application...24 III DISCUSSIONS 1 - A propos de la gestion de ce projet A propos du code A propos des outils...30 B. Visualisation de données I EXPRESSION INITIALE DES BESOINS 1 - Vision du projet Méthodologie...33 II PROTOTYPE 1 - Solution technique Réalisation de l'application...43 III DISCUSSIONS CONCLUSION BIBLIOGRAPHIE/WEBOGRAPHIE Annexes 1

4 Résumé L'année 2011 signe la consécration de deux tendances sur internet : les portails de partage de données portés par le mouvement de l'opendata et la Visualisation de données portée par le «datajournalisme». Au delà des médias, il est impératif de saisir dès aujourd hui l'importance stratégique de ces orientations pour la science et la recherche afin d'améliorer la collaboration scientifique. Le but du projet Waxi, qui porte ce stage, est de s'assurer que les universités et les services géologiques ouest africains deviennent des fournisseurs de données autonomes. Comment allier ces deux tendances à la géologie et au secteur minier? Comment les intégrer à ce projet? Ce rapport tente d'apporter une méthode et des réponses techniques à ces problématiques. Nous avons d'abord pris en main la création d'un catalogue de données en développant une application de partage des données du projet Waxi. Pour ce faire, nous avons bâti notre propre solution. Puis nous avons appliqué le même principe à la visualisation de données en partant d'une application déjà en ligne. Cette approche nous permet aujourd'hui de maîtriser en partie la mise en place de ce type d'outils. De plus, nous sommes désormais armés d'un modèle HTML CSS JavaScript, qui servira de base à de futures réalisations. Abstract In 2011, two trends have emerged on the Internet : the data sharing portals, as demonstrated by the Opendata movement, and the Data Visualization supported by the datajournalism. From now, it's really important to understand the strategic importance of these dynamics for science and research to improve scientific collaboration. The goal of the Waxi project, which supports this internship, is to ensure that universities and geological surveys of West Africa become independent data providers. This report attempts to provide a method and technical solutions to this problem. We first learned to handle the catalog creation process by developing an application for sharing the data of the Waxi project. For that, we built our own solution. Then we applied the same principle to the data visualization, following the example of an application already online. This approach enables us now to master some of the tools dedicated to the building of online data visualization applications. In addition, we are now ready with an HTML CSS JavaScript template for future applications. 2

5 Remerciements Je remercie tout d'abord mon maître de stage, Mark Jessell, qui m'a accueilli par deux fois au GET (Géoscience Environnement Toulouse), qui m'a ouvert les portes de la recherche géologique, qui a fait en sorte que je mette pour de bon les pieds dans Linux et qui a toujours été de bon conseil. Je tiens également à remercier Lenka Baratoux qui a gentiment pris le relais quand Mark était en mission. Je souhaite aussi remercier Laurent Jégou, mon tuteur pédagogique, pour son aide quand j'en ai eu besoin. Je remercie toute l'équipe pédagogique du master SIGMA pour cette année de formation. Je tiens à remercier Jérémie Ory et Thibaud Langer pour les moments partagés cette année. Enfin je remercie Marine Desprez pour son soutien tout au long de l'année. 3

6 INTRODUCTION Six mois de stage ont passé et une idée des chemins qu emprunte la géomatique sur internet se dessine peu à peu. Deux expressions suffisent à illustrer certaines tendances : Ouverture des données (Open data) et Visualisation de données. Il en existe d'autres bien sur, mais dans le cadre de ce stage, ces deux nous ont déjà largement occupés. Le mouvement de l'open data a réellement explosé avec l'ouverture en 2009 d'une partie des données publiques américaines. En France ce mouvement a fait des émules, et faute d'ouverture nationale, certaines villes ouvrent leurs données au public de leur propre chef. Le point commun de ces initiatives est qu'elles nécessitent la mise en place de portails internet pour partager l'information. Dans le domaine de la géomatique, nous connaissons déjà les outils nécessaires à la création de telles applications et en octobre 2010, la transposition de INSPIRE 1 dans le droit français a ajouté un cadre légal et une méthode au partage des données environnementales. En plus des outils que nous connaissons déjà, certaines sociétés innovent. C'est le cas de OpenGeo par exemple, qui, avec sa Suite ou GeoNode, part sur de très bonnes bases. Du côté de la visualisation de données, internet a offert un nouveau souffle à cette discipline jusqu'alors cloisonnée à des logiciels spécialisés. La presse en ligne l'a bien compris et the NewYork Times et the Guardian rivalisent d'inventivité pour être les plus visibles sur internet. En France, le site OWNI profite aussi de ce mouvement. Grâce au triptyque thématicien, graphiste et développeur, il réussit à s'imposer comme une référence de cette nouvelle génération des sites d'information. Les cartographes d'aujourd'hui ont tout intérêt à prendre le pas de ce mouvement, et à faire leurs armes avec les outils nécessaires à une transposition de la carte aux écrans. Development Seed, une start up américaine, profite de ce phénomène en imaginant avec leurs propres outils, des visualisations de données originales pour des organismes publics comme la Banque Mondiale où l'unicef. Le prochain Philippe Rekacewicz 2 aura de très bonnes connaissances en programmation et son atlas sera une application pour tablette tactile. Ce stage s inscrit donc dans ces deux orientations. Pour la première, il est question ici du portail internet et du système qui le maintient plus que de l'ouverture des 1 Acronyme anglais pour Infrastructure for Spatial Information in Europe. La directive Inspire impose aux autorités publiques, de rendre leurs données géographiques environnementales accessibles au public en les publiant sur Internet et de les partager entre elles. 2 Diplômé de géographie à la Sorbonne en 1988, Philippe Rekacewicz est géographe, journaliste et cartographe permanent du mensuel Le Monde Diplomatique. 4

7 données, les droits de partage étant limités. Pour la seconde, il s'agit, dans le cadre des laboratoires de recherche, d'un tout nouveau domaine. Un grand nombre d'outils existe mais le choix ainsi que leur agrégation en solution complète est complexe. Novices en la matière, nous nous sommes inspirés de OpenGeo et Developement Seed. Convaincus par ces tendances, et par la philosophie open source, comment se positionner dans ce credo si ce n'est en s'inspirant des acteurs qui exploitent au mieux les outils libres. Nous commencerons par présenter le contexte de ce stage, le laboratoire Géoscience Environnement Toulouse (GET) qui l'a accueilli, l'institut pour la Recherche et le Développement (IRD) qui l'a financé, et enfin le projet WAXI auquel ce stage est affilié. Puis dans une première partie nous traiterons de la mise en place d'une infrastructure de données spatiales pour partager les données du projet WAXI. Enfin nous explorerons les méthodes et outils pour créer une visualisation de données à composante cartographique et géologique sur internet. 5

8 CONTEXTE DU STAGE Ce stage s'est déroulé principalement en télétravail avec des réunions mensuelles sur l'avancée du projet, les difficultés rencontrées et les orientations à donner à la suite du travail. Par ailleurs, nous étions en contact permanent par mail ou directement via Google chat avec l'encadrant. Nous allons présenter ici le cadre formel de ce stage. 1 Géoscience Environnement Toulouse (GET) Le GET est un laboratoire de recherche fondamentale et appliquée de plus de 165 permanents (environ 250 personnes avec les étudiants, post doctorants, personnels sous contrat à durée déterminée, etc.). Ses domaines de compétences sont ceux des Géosciences et des Sciences de l Environnement bâtis autours de chercheurs de 5 statuts différents : chercheurs du CNRS, chercheurs de l IRD, enseignants chercheurs de l Université Paul Sabatier (Toulouse III), physiciens des Observatoires (CNAP), chercheurs du CNES. Parmi ses grandes thématiques de recherche, citons : les géoressources et les géomatériaux, les surfaces continentales et les changements globaux, les interactions entre contaminants métalliques/écosystèmes, les interactions fluides minéraux /organismes vivants en contexte naturel, les ressources en eau et leur vulnérabilités. 2 Institut pour la Recherche et le Développement (IRD) L'institut de Recherche pour le développement est un établissement public français à caractère scientifique et technologique qui intervient depuis plus de 60 ans dans les pays du Sud. Il est placé sous la double tutelle des ministères chargés de la Recherche et de la Coopération. 6

9 Ses activités de recherche, d'expertise, de valorisation et de formation ont pour objectif de contribuer au développement économique, social et culturel des pays du Sud. Elles se déclinent autour de 6 priorités : lutte contre la pauvreté, migrations, maladies émergentes, changements climatiques et aléas naturels, accès à l'eau, écosystèmes. L'IRD a aussi pour mission de mobiliser les universités et les grands organismes de recherche français et européens sur les priorités de la recherche pour le développement. 3 Projet WAXI Le projet WAXI (West African Exploration Initiative) est un programme de recherche et de formation mené par neuf institutions partenaires, pour mettre l'accent sur le potentiel minéral du craton 1 du Léo Man, une aire géologique au sud de l'afrique de l'ouest. Cette initiative, qui a débuté en novembre 2006, est principalement financée par l'industrie minière internationale et le gouvernement australien, via un consortium AMIRA international. AMIRA International est une association industrielle dédiée à soutenir la recherche collaborative dans l'industrie minière. L'objectif global du projet WAXI est d'accroître le potentiel d'exploration du craton du Léo Man à travers un programme de recherche et de collecte de données, et d'augmenter la capacité des institutions locales à entreprendre cette forme de travail. Les activités de renforcement des capacités sont totalement souscrites par l'ausaid (Agence australienne pour le développement international). L'initiative couvre l'ensemble de l'aire géologique et ses abords immédiats, et comprend les pays suivants : Burkina Faso, Guinée, Guinée Bissau, Côte d'ivoire, Liberia, Ghana, Gambie, Mali, Mauritanie, Sénégal, Niger, Sierra Leone et Togo. Les principales motivations pour entreprendre cette initiative sont d'aider les sociétés d'exploration en concentrant leurs activités dans les domaines de la prospective et 1 Un craton est un élément de lithosphère continentale possédant une identité géologique, notamment en termes de nature des roches et de structuration des unités géologiques qui le composent 7

10 d'aider les services géologiques locaux ainsi que les universités de la région dans leur rôle de fournisseur de données et d'informations. L'objectif des outils développés au cours de ce stage est de soutenir techniquement les activités de recherche et de formation du projet WAXI. 8

11 A. Infrastructure de Données Spatiales 9

12 I EXPRESSION INITIALE DES BESOINS Dans le cadre du projet WAXI, le GET souhaite réaliser une Infrastructure de Données Spatiales (IDS). L objectif de la future IDS est de permettre à un public spécialiste de l'information géologique de consulter et sélectionner les couches du projet et de les télécharger en respectant les normes en vigueur d'échange de l information géographique. Cet outil s'inscrit donc dans une logique de partage des données du projet WAXI. Le but du présent chapitre est de définir et analyser les besoins et caractéristiques de la future IDS. 1 Vision du projet 1.1 Définition Une Infrastructure de Données Spatiales regroupe des technologies et des dispositions institutionnelles pour faciliter la mise à disposition et l accès à l information géographique. Une IDS fournit à ses usagers des services de données géographiques. Ces services permettent de : rechercher (catalogue), visualiser (portail), combiner des données et des services géographiques interopérables entre eux, pour des utilisations multiples. 1.2 Principaux composants techniques théoriques Techniquement parlant, ceci s'articule autour de : dépôts de contenu ; catalogues de données géographiques pour assurer : l accès aux données, l interrogation des données et des services, des services de légende ; Services géographiques comme : 10

13 WMS 1, WFS 2 ; application côté utilisateur (navigateur, SIG). Les enjeux de ses composants sont d'une part d'adopter des standards existants afin d assurer l interopérabilité entre les différents composants et d'autre part, de s appuyer sur un modèle de données commun pour échanger à travers le réseau des données interopérables. 1.3 Norme INSPIRE La directive INSPIRE, élaborée par la Direction générale de l'environnement de la Commission européenne, vise à établir en Europe une infrastructure de données géographiques pour assurer l interopérabilité entre bases de données et faciliter la diffusion, la disponibilité, l'utilisation et la réutilisation de l information géographique en Europe. La mise en œuvre d une IDS respectant la norme INSPIRE s appuie sur le respect de règles : des métadonnées standardisées (norme ISO19115 et 19119), des spécifications de données et des services de données géographiques, des technologies et services de réseau, des accords sur le partage, l accès et l utilisation, des mécanismes de coordination et de surveillance. 2 Exigences fonctionnelles Le portail de visualisation et le catalogue doivent regrouper toutes les fonctionnalités nécessaires à l'affichage, la recherche, l'interrogation, la sélection, la visualisation, le téléchargement et l'accès aux métadonnées. 2.1 Affichage La première exigence essentielle est d'offrir aux chercheurs un outil clair, précis, simple et agréable à utiliser. Pour faciliter la prise en main de l'interface, celle ci doit 1 Le Web Map Service ou WMS permet de produire des cartes de données géoréférencées à partir de différents serveurs de données. 2 Le service WFS permet, au moyen d'une URL formatée, d'interroger des serveurs cartographiques afin de manipuler des objets géographiques. 11

14 se rapprocher des standards des logiciels SIG de plus en plus utilisés. On compte notamment dans ces standards la présence d'une barre d'outils en haut de l'interface, une échelle et des coordonnées en bas, et les différentes couches disponibles à droite ou à gauche. Illustration 1: Exemple d'interface type "SIG" Prenons l'illustration 1 comme exemple. Son interface est simple d'utilisation pour un utilisateur SIG car il y trouve de suite l'emplacement de ses outils. Le panneau central est la fenêtre de visualisation cartographique. Les outils de déplacement sont accessible en haut à droite bien qu'une navigation entièrement à la souris (zoom à la molette) soit possible. L'outil «information» permet de consulter les informations attributaires des objets sélectionnés dans une boite de dialogue adaptée. En bas à droite nous retrouvons une échelle. Dans le panneau de gauche sont regroupées toutes les informations relatives aux couches. Chacune des couches du projet appartient à un groupe thématique qui permet de l'identifier plus facilement. Un menu contextuel permet d'avoir une description de chacune des couches et de contrôler rapidement leur affichage (opacité). Ce menu contextuel fournit également un «espace de stockage» supplémentaire pour les outils qui pourrait alimenter ensuite l'application. 2.2 Catalogue En parallèle de la visualisation cartographique, l'utilisateur doit pouvoir avoir accès à un catalogue des couches disponibles avec la possibilité de filtrer celles ci sur un mot clé ou une emprise géographique. Pour chaque couche, l'utilisateur doit pouvoir avoir accès aux informations décrivant la couche, une vue des métadonnées, un lien de téléchargement direct et enfin des possibilités de visualisations spécifiques. 12

15 2.3 Téléchargement L'application doit pouvoir offrir à l'utilisateur identifié la possibilité de télécharger les couches au format shapefile. De plus, l'utilisateur doit pouvoir avoir la possibilité de sélectionner plusieurs couches et de toutes les télécharger en une seule fois. 13

16 II PROTOTYPE Après une présentation formelle de l'environnement de travail, nous présentons les solutions techniques mises en place côté serveur puis côté client. 1 Environnement de Travail 1.1 Environnement matériel Le prototype a été réalisé à domicile, sur une machine personnelle dont la configuration est : CPU AMD Phenom 2 X4 cadensé à 3.4 GHz, 4 Go de RAM, 1 To d'espace disque, Ubuntu puis (Windows 7 éventuellement) ; Puis il a été installé sur un serveur virtuel du GET : 200 Go d'espace disque, Debian 5, Tunnel SSH disponible depuis mi juillet. 1.2 Environnement logiciel Les différentes applications utilisées pour la création du prototype sont : Un simple éditeur de texte (gedit) et parfois Éclipse ou Aptana Studio 3 pour leurs outils d'autocomplétion, Le terminal et PgAdmin3 pour gérer la base de données PostGIS, Quantum GIS 1.7 et le plugin export SLD pour créer le style des couches, Firefox (de la version 3.6 à la version 6) et Chromium (version 12) pour les tests, Firebug et le débugger de Chromium pour le débogage. 2 Solutions techniques SERVEUR Le serveur est décomposé en plusieurs parties (illustration 2) : le système d'exploitation (non illustré), 14

17 la base de données, le serveur cartographique GeoServer, le serveur HTTP Apache. Illustration 2: Organisation côté serveur 2.1 Système d'exploitation Debian Le système d'exploitation est le niveau zéro des briques logicielles. Pour un serveur web, nous avons en théorie le choix entre Windows et Linux. L'application devant être libre et open source, nous avons choisi une distribution Linux (qui est aussi la norme pour les serveurs web). Or, à la différence de Windows, il existe de nombreuses distributions du système d'exploitation open source. Les premiers travaux sur cette application se déroulaient sur une distribution RedHat, le serveur était fourni avec cette distribution par le GET. Très délicate au début, la mise en place d'un serveur Linux devient plus facile après quelques mois passés sur les distributions Ubuntu et Fedora. Entre temps, nous avons changé de serveur pour une machine virtuelle sous Debian. Passer de Ubuntu à Debian est relativement simple vu que la première distribution est basée sur la seconde. L'installation du système s'est donc déroulée sans problème, tous les logiciels étant présents dans les paquets. Nous avons tous les droits d'administration de cette machine virtuelle et personne d'autre n'intervient dessus. Toute la configuration est à notre charge. 15

18 2.2 Base de données PostGIS a) Origines des données Toutes les données du projet sont à la base au format shapefile. Elles sont classées dans des répertoires selon l'organisation de l'illustration 3. Illustration 3: Organisation originale des données Il n'existe aucun programme d'harmonisation des données, ce qui rend le modèle de données de chaque couche unique. C'est un point délicat et long à gérer en géologie. Actuellement, le BRGM se lance d'ailleurs dans un référentiel géologique pour la France, une tache complexe, qui demande un énorme effort d'abstraction et qui prendra sûrement plusieurs années. Ici l'objectif du stage n'était pas d'harmoniser les données du projet. Cependant, le système de référence de toutes les couches étant par défaut le WGS84, le système géodésique mondial, les tâches d'intégration ont été simplifiées car aucune reprojection n'a été nécessaire. b) Système de Gestion de Base de Données (SGBD) Lors de la mise en place d'une base de données spatiales open source, le choix se porte le plus souvent sur le tandem PostgreSQL/PostGIS. 16

19 PostgreSQL est un système de gestion de base de données sous licence BSD 1 reconnu pour son comportement stable, proche de son concurrent propriétaire Oracle. L'extension PostGIS permet le traitement d'objets spatiaux dans les serveurs PostgreSQL, autorisant le stockage en base de données pour les SIG. c) Modèle de Base de données Lors d'une installation de PostgreSQL/PostGIS sur Linux, il est conseillé de créer un modèle de base de données PostGIS (créé à l'installation sur Windows). La création de la base du projet ne se limite alors plus qu'à la création d'un clone de ce modèle alimenté ensuite avec les couches du projet. Cependant, pour faciliter la gestion dans GeoServer et garder le premier niveau d'organisation des couches (illustration 3), nous avons organisé les tables en schéma logique (illustration 2). Le schéma public (schéma par défaut à la création d'une base de données) reçoit les tables spatiales. Avec PgAdmin3, Quantum GIS, ou directement avec la commande shp2pgsql, il est possible d'importer les couches shapefiles dans la base en renseignant leur système de référence, le schéma et le nom de la table d'accueil. Nous avons conservé la syntaxe des couches pour le nom des tables. Par exemple, le shapefile wafr_admin.shp deviendra la table wafr_admin. 2.3 Serveur Cartographique GeoServer GeoServer permet aux utilisateurs de partager et modifier des données géographiques sur internet. A la manière d'apache pour HTML, GeoServer vise à faire la même chose pour la donnée spatiale. Il gère nativement le SLD (Styled Layer Descriptor) pour la symbologie des objects et sa notion d'«espace de travail» (workspace dans l'iilustration 2) a facilité la programmation de l'arbre des couches pour la partie cliente. Enfin la dernière version stable de GeoServer permet d'appeler des cartes WMS provenant de serveurs distants. Ceci répondait parfaitement au problème de gestion de données externes, les couches du BRGM par exemple, que nous voulions intégrer à l'application. a) Mise en place GeoServer est une application web écrite en JAVA. Ceci nécessite la mise en place d'un serveur capable de compiler et exécuter cette application. C'est le cas de 1 La licence BSD (Berkeley software distribution license) est une licence libre utilisée pour la distribution de logiciels. Elle permet de réutiliser tout ou une partie du logiciel sans restriction, qu'il soit intégré dans un logiciel libre ou propriétaire. 17

20 Tomcat, de la fondation Apache. Le problème est que, la version JAVA installée par défaut sur une distribution Linux (OpenJDK), ralentit le fonctionnement de GeoServer. Il faut donc installer et activer la version propriétaire de JAVA. Ensuite, il suffit de coller l'archive GeoServer.war dans le répertoire des applications web de Tomcat et de se rendre dans un navigateur à l'adresse localhost:8080/geoserver pour accéder à l'interface d'administration de GeoServer. b) Entrepôt et Espaces de travail Grâce aux «espaces de travail» de GeoServer, nous avons créé l'arborescence des couches affichées dans l'application. Il était donc nécessaire d'ajouter un espace de travail pour chaque nœud de l'arbre des couches. Il fut ensuite nécessaire d'associer un entrepôt à chaque espace de travail. Chaque entrepôt est configuré de telle sorte que le schéma associé de la base de données soit lié à l'espace de travail qui porte son nom. Par exemple, dans l'illustration 2, l'espace de travail «africa», pointe vers l'entrepôt «africa» qui pointe lui même vers le schéma logique du même nom. c) Les styles SLD Les données géospatiales n'ont pas de composantes visuelles intrinsèques. Pour les voir, un style doit leur être appliqué. Cela signifie qu'il est nécessaire de spécifier leur couleur, leur épaisseur ou d'autres attributs graphiques. Dans GeoServer, ce style est généré en utilisant un langage de balise basé sur XML appelé SLD (Styled Layer Descriptor). Il y a deux types de style dans notre configuration de GeoServer : Les styles uniques à une couche, Les styles communs à plusieurs couches. Les styles uniques sont utilisés pour les couches des formations géologiques. Comme il n'y a pas réellement de standards pour les couleurs des formations (seulement une orientation donnée pas leur âge ou leur lithologie), chacune d'elles doit avoir un fichier SLD spécifique. Ceux ci sont générés à partir d'une extension présente dans QGIS qui exporte la symbologie en SLD. A l'inverse, pour la plupart des couches ponctuelles, un seul style générique a été créé. d) Services web GeoServer est un des serveurs cartographiques les plus abouti pour la gestion des services web. Bien que l'application réalisée ici propose de visualiser et télécharger les couches, d'autres applications SIG, comme Quantum GIS, offre aussi la 18

21 possibilité de récupérer directement les données sur le serveur cartographique via le WMS (raster) où le WFS pour télécharger directement les couches en vecteur. e) Sécurité Une sécurité a été mise en place au niveau de GeoServer pour contrôler les connexions. L'utilisateur identifié via l'application a des droits limités sur GeoServer, ce qui limite toute modification des couches. Ceci interdit aussi l'accès au serveur cartographique par un autre client via les services WMS ou WFS. 2.4 Serveur HTTP Apache Le choix du serveur HTTP s'est porté logiquement sur le plus populaire d'entre eux : APACHE. Il est relativement simple à configurer. De plus, il existe une très grosse communauté d'utilisateurs sur internet permettant de résoudre les problèmes de configuration spécifique très rapidement. a) Proxy Pour que Apache et GeoServer dialoguent ensemble, un minimum de configuration est nécessaire. GeoServer via Tomcat fonctionne sur le port 8080 et Apache sur le port 80. Nous avons donc configuré un proxy (illustration 2) dans Apache qui redirige les adresses vers GeoServer sur le port 8080 : ProxyRequests Off <Proxy *> Order deny,allow Allow from all </Proxy> ProxyPass /GeoServer ProxyPassReverse /GeoServerhttp://localhost:8080/GeoServer ProxyPreserveHost On b) Sécurité Toutes les données n'étant pas accessible au public, il était indispensable de protéger l'accès au serveur. Nous ne pouvons accéder à ce prototype qu'une fois identifié. Un fichier htaccess 1 empêche toute autre connexion. 1 Les fichiers.htaccess sont des fichiers de configuration des serveurs web Apache. Ils servent à modifier les droits d'accès, créer des redirections ou écrire des messages d'erreur personnalisés. 19

22 3 Solutions techniques CLIENT Toute la partie programmation de l'application se situe côté client. L'application s'appuie sur HTML, CSS et JavaScript. Ce dernier est le langage de base des différentes bibliothèques utilisées. Le fichier index.html appelle tous les fichiers nécessaires et se charge dans le navigateur du client (illustration 4). Illustration 4: Organisation de l'application côté client 3.1 Bibliothèques JavaScript Nous présentons ici les différentes bibliothèques JavaScript utilisées pour l'application. Bien que leur licence varie de l'une à l'autre, elles sont toutes opensources. 20

23 a) Sencha ExtJS3 La bibliothèque ExtJS3 1, sous licence GNU GPL 2, permet de construire des applications web interactives. Construite au départ comme une extension de la bibliothèque Javascript YUI de Yahoo, elle peut désormais être utilisée avec les bibliothèques Prototype, JQuery ou simplement toute seule. ExtJS apporte un certain nombre de composants visuels de grande qualité comme des champs de formulaires avancés, des arbres, des tableaux, des menus et barres d'outils, des onglets et des boîtes de dialogue. b) OpenLayers OpenLayers 3 est une bibliothèque sous licence BSD. Elle constitue une bibliothèque de fonctions JavaScript assurant un ensemble de fonctionnalités orienté vers la mise en place d'applications clientes Web cartographiques fluides. OpenLayers permet d'afficher des fonds cartographiques tuilés ainsi que des marqueurs provenant d'une grande variété de sources de données. Une partie de cette bibliothèque permet aussi de gérer l'ergonomie proposée à l'utilisateur, mais ce n'est pas directement son rôle. GeoExt 4 c) GeoExt est une bibliothèque Javascript sous licence BSD, basée sur ExtJS et OpenLayers. Elle est le fruit des travaux de Camptocamp 5 sur la composante cliente de MapFish, des travaux de OpenGeo et de réflexions communes. L'objectif principal de GeoExt est de fournir une bibliothèque facile à utiliser pour la construction d'interface graphique pour des applications de Web SIG. d) Gxp La bibliothèque Gxp 6 est un ensemble de composants et de classes de données sous licence GNU GPL. Construite sur la base de GeoExt et OpenLayers, cette bibliothèque étend les fonctionnalités de ExtJS3. On peut considérer celle ci comme La licence GPL (General Public Licence) met en œuvre la notion de copyleft. Comme le copyright, le copyleft définit et encadre les droits des utilisateurs de façon contraignante. Le mécanisme est identique, mais les objectifs différent : le copyright garantit exclusivement les droits de l'auteur, le copyleft s'attarde tout particulièrement aux droits des utilisateurs, et vise à préserver la liberté d'utiliser, d'étudier, de modifier et de diffuser le logiciel et ses versions dérivées Camptocamp est un éditeur de composants logiciels libres dans les domaines des solutions géospatiales