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

24 une extension de GeoExt. Elle permet de créer une interface de consultation cartographique avec un arbre des couches en quelques lignes de codes seulement. Elle est notamment utilisée dans la suite Opengeo. 3.2 Thème graphique a) Feuilles de style CSS Les feuilles de style utilisées sont les styles par défaut de ExtJS, de GeoExt et de Gxp. Aucune modification n'a été apportée, à l'exception de l ajout de référence aux icônes pour les boutons créés. b) Icônes Les icônes utilisées pour le thème du menu font partie du pack GeoSilk, un ensemble d'icônes conçu pour les applications de OpenGeo sur la base d'un autre ensemble d'icône nommé Silk. Ces deux packs sont tous les deux sous licence Creative Commons Métadonnées Les métadonnées au format ISO19115 ont été générées avant le début de ce stage. Nous cherchions donc à savoir comment les afficher et les exploiter dans l'application. Après avoir testé GeoNetwork 2 nous avons écarté cette solution car nous la trouvions sur dimensionnée pour notre projet. Un autre outil, GeoNode 3, répondait au problème d'une visualisation simple des métadonnées mais, face à l'absence de possibilité en termes de modification, nous l'avons aussi écarté. a) Problème rencontré L'idée originale était de réussir à lire ces métadonnées avec le DOM (Document Object Model) 4 et les outils présents dans ExtJS. Une fois ces informations passées à cette bibliothèque, il ne restait plus qu'à les classer, les filtrer et les afficher, tache relativement simple avec ExtJS. 1 Les licences Creative Commons constituent un ensemble de licences régissant les conditions de réutilisation et/ou de distribution d'œuvres. 2 GeoNetwork est un outil de catalogage développé par la FAO pour référencer les données géoréférencées. 3 GeoNode est une plate-forme open-source qui facilite la création, l'échange et l'usage collaboratif de l'information géographique. 4 Le Document Object Model (ou DOM) décrit une interface permettant à des programmes informatiques et à des scripts d'accéder ou de mettre à jour le contenu, la structure ou le style de documents XML. 22

25 Or, il existe deux types de document XML, les simples que nous pouvons parcourir à l'aide du DOM : <xml> <famille> <père>papa</père> <mère>maman</mère> <enfants></enfants> </famille> </xml> Et les complexes, qui utilisent une grammaire comme celle définie par la norme ISO19115, le format des métadonnées : <gmd:metadatastandardname> <gco:characterstring>iso19115</gco:characterstring> </gmd:metadatastandardname> Ceux ci ne sont pas accessibles via le DOM et donc ExtJS. Il nous a donc fallu trouver une astuce pour les afficher. b) Utilisation des fichiers XSL Toutes les métadonnées sont stockées dans le dossier «metadata» (illustration 4) sous la forme «nom_couche.xml». À partir d'une installation de GeoNetwork, nous avons récupéré un fichier de forme XSL (extensible Stylesheet Language) 1 que nous avons simplifié pour l'afficher ensuite dans la page. Pour qu'un fichier XML s'affiche selon un style défini dans un XSL, il faut que ce dernier soit chargé dans le document XML avec un appel de ce type : <?xml version="1.0" encoding="iso "?> <?xml-stylesheet type="text/xsl" href="famille.xsl"?> Or nous ne pouvions pas ajouter ces lignes à toutes les métadonnées. La manipulation se fait donc à l'aide de JavaScript qui ajoute dynamiquement l'appel au fichier XSL aux métadonnées avant de les afficher. 1 Une feuille de style XSL est un fichier qui décrit comment doivent être affichés les documents XML basés sur un même schéma (ici celui défini par la norme ISO19115). 23

26 4 Réalisation de l'application L'application comprend deux volets, un volet carte interactive et un volet catalogue. 4.1 Carte interactive Illustration 5: Interface du volet carte interactive Comme présenté dans l'illustration 5, le volet carte offre les fonctionnalités classiques de visualisation d'un outil SIG. La couche de base est OpenStreetMap 1. L'utilisation de la bibliothèque Gxp facilite la création d'interface de ce type puisqu'il suffit d appeler la classe viewer (illustration 6) de cette bibliothèque avec les paramètres souhaités pour avoir un résultat comme celui ci. Par défaut, la liste des couches est écrite «en dur» (c'est à dire que les couches sont définies une par une dans la page html). Dans notre cas ceci n'était pas envisageable vu le nombre de couches mises à disposition. Une fonction JavaScript stocke donc les résultats d'une requête WMS GetCapabilities 2 dans un tableau qui est ensuite chargé à l'initialisation de l'application. De la même manière, cette 1 OpenStreetMap est un projet destiné à réaliser une carte du monde, sous licence dite libre. 2 Retourne les métadonnées qui décrivent le contenu du service et les paramètres acceptés. 24

27 fonction récupère (à l'aide d'une classe GeoExt) l'espace de travail GeoServer auquel appartient chaque couche pour gérer les nœuds de l'arbre des couches. Illustration 6: Classes JavaScript appelées pour le volet carte interactive 4.2 Catalogue Ce volet donne un aperçu des informations relatives à chaque couche. Nous trouvons dans le tableau toutes les informations renvoyées par la requête WMS GetCapabilities. Si nous étendons une ligne du tableau, les métadonnées apparaissent. 25

28 Illustration 7: Interface du volet catalogue À droite, un bouton permet le téléchargement de la couche (en shapefile) et un autre offre une visualisation rapide, l'équivalent d'une miniature de la couche. En haut la barre de menu permet de filtrer les couches affichées dans le tableau textuellement ou via un filtre sur une emprise géographique (illustration 8). 26

29 Illustration 8: Filtre sur une emprise géographique En sélectionnant plusieurs couches, l'utilisateur a aussi la possibilité de récupérer une archive des couches sélectionnées au format shapefile. Contrairement au volet précédent, le catalogue est construit essentiellement à partir de ExtJS. Nous avons d'un côté la classe GridPanel nécessaire comme son nom l'indique à la construction d'un panneau grille. De l'autre la classe Store, la classe ExtJS qui permet de stocker des données (illustration 9). 27

30 Illustration 9: Classes JavaScript mobilisées pour le volet catalogue 28

31 III DISCUSSIONS 1 A propos de la gestion de ce projet Le développement de cette application est passé par de nombreuses phases que nous n'avons pas pu intégrer au cycle de vie standard d'un projet. Tout d'abord, les besoins ont été exprimé au fur et à mesure du stage. Ensuite, le manque de compétences de notre part au départ et l'évolution logicielle entre le début et la fin de ce travail rendait difficile la planification du projet. Nous nous sommes cependant appuyés sur quelques repères nous permettant de planifier certaines tâches. Nous avons donc tenté de suivre les principes du Manifeste Agile 1 pour s'adapter à ces contraintes. Illustration 10: Gestion de projet Agile Pour les tests utilisateur, le commanditaire de cette application étant aussi le responsable de ce stage, ils se sont déroulés au fur et à mesure du développement de l'application. Une démonstration a aussi été proposée aux acteurs du projet WAXI et nous avons eu de très bons retours de la part des chercheurs et universités ouestafricaines, notamment pour le catalogue de données. 1 Le Manifeste Agile est un texte rédigé par 17 experts reconnus pour leurs apports respectifs au développement d'applications informatiques sous la forme de plusieurs méthodes dont les plus connues sont Extreme Programming et Scrum. Ces experts estimaient que le traditionnel cycle de développement en cascade ne correspondait plus aux nouveaux besoins applicatifs 29

32 2 A propos du code Ce prototype représente un gros effort d'apprentissage du JavaScript et des bibliothèques que nous avons utilisées. Il répond aux besoins exprimés d'une manière originale. Cependant de nombreuses améliorations pourraient être apportées. S'agissant d'une première réelle expérience de développement JavaScript, nous avons aujourd'hui un peu plus de recul pour juger notre travail. Si au début de ce stage, nous avions eu cette expérience, nous serions parti directement sur une programmation objet pour tous les outils créés. Ce n'est pas le cas ici, notamment pour l'outil filtre géographique qui devrait être une classe à part. Le code pourrait aussi être allégé, notamment au niveau du chargement de l'arbre. Si les couches se chargent dynamiquement au bon endroit, les nœuds de l arbre sont écrits en «dur dans le code» de la classe LayerTree (illustration 6) que nous avons modifié. Il faudrait faire en sorte que chaque espace de travail GeoServer deviennent un nœud de l'arbre automatiquement. 3 A propos des outils Les outils utilisés et mis en place répondent parfaitement au besoins du commanditaire. Nous avons une base de données spatiales centralisée accessible via Internet, un serveur cartographique délivrant les services WMS et WFS comme spécifié par la directive INSPIRE et un portail pour consulter et télécharger les données et les métadonnées. Le seul point noir se situe au niveau des métadonnées. Après Mdweb 1 qui est au point mort, l'utilisation seule de GeoNetwork ne semble plus d'actualité aux bénéfices de nouvelles applications qui l'utilisent comme brique logicielle d'une solution complète. GeoNode est un bon exemple de ces nouvelles applications. Il permet dans une interface simple de partager de la données, leur métadonnée et de créer des cartes. Il offre surtout des perspectives intéressantes, qui manquent aujourd'hui aux catalogues cités : une dimension participative. Les fournisseurs de contenu grand public sur internet fonctionnent parce qu'une communauté d'utilisateurs note et donne son avis sur le contenu. Un article est propulsé lorsqu'un certain nombre de personne le partage sur les réseaux sociaux. Pourquoi ne pas appliquer ce principe au portail de données, qui sont indéniablement des fournisseurs de contenu, en y introduisant une dimension sociale. Nous ne sommes pas dupe et ne voyons pas l'intérêt de partager une couche sur Facebook ou Twitter. Mais imaginons un instant 1 MDweb est un outil libre de catalogage et de localisation de ressources (données, documents et services), accessible sur la toile. 30

33 une application capable de partager des données à un groupe précis sur Linkedin. Celle ci pourrait offrir l'interface nécessaire à l'ouverture aux membres de ce groupe de discussions sur l'intérêt et les possibilités offertes par ces données partagées. Il est difficile d'estimer le nombre d'utilisateurs intéressés par une application comme la nôtre. Il est donc difficile d'estimer l'apport d'une dimension sociale dans notre cas. Les pistes développées ici semblent néanmoins de bon axes de recherche pour le futur des catalogues de données. 31

34 B. Visualisation de données 32

35 I EXPRESSION INITIALE DES BESOINS 1 Vision du projet L'idée initiale était de créer, à l'aide d'une table spécifique dans la base de données, un lien entre chaque couche et une série de possibilités visuelles (graphes, diagrammes). Pour une couche donnée, l'application devait offrir une liste de graphes, avec pour chacun d'eux, un nombre fini de possibilités. Or nous avions du mal à définir un type d'utilisateur intéressé par ces fonctionnalités. Cela aurait été trop complexe pour les néophytes et dans le même temps trop limité pour les spécialistes de ce type d'information, habitués à leurs outils «desktop» plus performants. Les chercheurs ont acquis une méthode et la maîtrise de certains outils. Il est naturel pour eux de télécharger une couche et de travailler avec. Créer un outil de visualisation de données dédié à la recherche sur internet demanderait d'intégrer beaucoup trop de paramètres pour rendre l'outil réalisable. Nous sommes donc partie sur une autre voie. Comme tous les domaines présents sur internet, la géologie n'échappe pas aux règles de la visibilité. A la différence d'une IDS, dont le rôle est de faciliter l accès aux données aux chercheurs et experts, le nouvel objectif de notre application est de travailler sur la visibilité des données de ce projet sur internet en s'ouvrant à un public plus large. Ceci nécessite de changer de point vue. L'IDS présentée ici a été pensée par les géologues du projet pour ces mêmes géologues. Il existe sûrement un intérêt scientifique à afficher dans un environnement soigné de l'information de manière simple et compréhensible par le plus grand nombre. Mais pour les chercheurs, il s'agit plus d'un gadget, d'un outil accessoire de vulgarisation scientifique. C'est pourtant à partir de cet effort de vulgarisation que nous produirons de la visibilité. Le but n'est pas d'échanger des données mais une idée, une histoire scientifique. Cette partie du travail vise donc à définir un cadre de création pour des visualisations géologiques open sources sur internet. Positionnés dans ce projet en tant que développeur, et un peu comme graphiste, nous aborderons principalement cette problématique du point de vue des techniques à mettre en place. 2 Méthodologie A la grande différence des catalogues qui inventorient, la visualisation de données synthétise. Réaliser une visualisation de données, c'est raconter une histoire. Pourtant nous n'avons pas vraiment étudié le problème sous cet angle, laissant 33

36 l'histoire de côté afin de nous concentrer sur les outils et les techniques disponibles sujet de ce stage. Nous allons préciser ici les étapes de ce travail. 2.1 Obtenir la donnée Par rapport au catalogue mis en avant dans la première partie, il est impossible ici de travailler sur toutes les couches. Nous avons donc commencé par sélectionner une couche, pertinente en termes de visualisation : les gisements miniers d'afrique de l'ouest référencés par le programme SIGAfrique coordonné par le BRGM. Celle ci recense 336 gisements pour 40 minerais différents. La table de cette couche est organisée ainsi : Champs Id Name Country Commodity Potential Unit Class Status Type Morphology Commentaires Identifiant Nom du gisement Pays du gisement Code du minerai exploité Potentiel numérique du gisement Unité du potentiel, en tonne sinon en carra pour le diamant Classement du gisement de A à C Type de l'exploitation Type de sol Morphologie de l'exploitation 34

37 2.2 Fondamentaux a) Que cherchons nous à représenter? Nous cherchons à mettre en avant pour chacune des visualisations une thématique géologique. Pour notre prototype il s'agit du potentiel et du type des gisements ouestafricains. b) Quel public visons nous? Le public visé est pour le moment les géologues ainsi que ceux qui ne sont pas experts de ce type d'information. Il est donc nécessaire d'allier précision et simplicité. Ceci ne s'inscrit cependant pas dans une logique de production pour une mise à disposition du plus grand nombre mais comme un travail préparatoire. c) Dans quel but? Le but principal est de rendre l'information géologique, par nature assez indigeste, consommable par le plus grand nombre. Seulement ici nous chercherons à explorer les outils, étudier ce qui se fait et en extraire les possibilités techniques et graphiques pour ce genre de projets en partant d'une couche de données simple. 2.3 Choisir les outils Cherchant des exemples de visualisation de données orientée vers là cartographie, nous avons pris comme référence les travaux de Developement Seed. Cette entreprise américaine réalise des applications open source pour des agences gouvernementales sur des projets d'aide au développement ou d'engagement humanitaire. Nous sommes donc parti d'une de leurs réalisations au titre explicite, Violence Against Journalists in Afghanistant 1 (Illustration 10). 1 Accessible en ligne à 35

38 Illustration 11: L'application de visualisation réalisée par Development Seed Bien que n'ayant aucun rapport thématique avec notre projet, l'angle d'approche, l'interface et le traitement de la donnée conviennent parfaitement à notre travail. Après avoir étudié son fonctionnement, nous nous en sommes servis comme base. Nous présenterons en détail les outils et leur utilisation dans la partie prototype. 2.4 Explorer les possibilités Le but n'est pas d'afficher une carte avec infobulle, bien que cette solution convienne à certains projets. Il s'agit d'associer à une carte d'autres formes de visualisation, notamment les diagrammes et graphiques présentés ici, la plupart n'étant pas encore exploités sur internet. Bien qu'absents du prototype, les diagrammes et graphiques complexes décris ici le sont à titre indicatif pour illustrer les attentes de ce projet et la suite des recherches sur les méthodes et outils pour les réaliser. a) Diagrammes classiques Il s'agit des diagrammes régulièrement utilisés (en colonne, en barre, par secteur, ligne, nuage de points, etc.). De nombreux outils permettent de les réaliser sans trop de difficulté et ils se prêtent à tout type d'analyse. La difficulté est de soigner le résultat et d'intégrer de l'interactivité. 36

39 b) Symboles structuraux et diagrammes d'orientation Nous entrons ici réellement dans la thématique du projet avec ses difficultés de représentation sur internet. En géologie, le pendage sert à définir la géométrie de l'orientation d un plan, d une surface. Il existe plusieurs manières de le représenter. Mais avant il est nécessaire d'expliquer sa mesure. Illustration 12: Mesure du pendage (Source :V. Merrien Soukatchoff, Milieux discontinus, T141, École des Mines de Nancy) La mesure consiste à repérer l'azimut (ligne horizontale) et la ligne de plus grande pente (qui lui est perpendiculaire) et à noter les deux angles. La représentation classique, celle que l'on voit sur les cartes géologiques, est un symbole ponctuel orienté représentant l azimut ou le pendage. Mais il existe d'autre manière de faire comme représenter ces objets selon l'abaque de Wulff. 37

40 Illustration 13: Pendage sur Abaque de Wulff (Source :V. Merrien Soukatchoff, Milieux discontinus, T141, École des Mines de Nancy) Si nous appliquons une projection stéréographique à une faille, nous obtenons un arc. Le pôle de cet arc est situé sur la normale au plan. Il est donc situé sur la trace de l'abaque faisant un angle de 90 par rapport à l'arc. Par exemple, si nous déterminons qu'un objet a un pendage de ρ par rapport à l'horizontale, le pôle se trouve sur la trace du plan faisant un angle de ρ+90. Illustration 14: Diagramme de Schimdt (Source :V. Merrien Soukatchoff, Milieux discontinus, T141, École des Mines de Nancy) 38

41 En regroupant plusieurs objets sur un même diagramme, nous obtenons un diagramme de Schimdt (illustration 13) à partir duquel il est possible d'extraire différents profils par rapport aux nuages de points. c) Diagrammes triangulaires Le but de ces diagrammes est de comparer trois données complémentaires pour visualiser leurs relations. Celui ci se lit de la manière suivante : Soit un diagramme ternaire pour trois éléments (ou composés) A, B et C. Chaque sommet correspond à un élément. La composition correspondante à un point quelconque du diagramme se détermine ainsi : pour l'élément A, on trace la parallèle au côté opposé au sommet A, on détermine l'intersection de cette droite avec le côté portant la mention «%A», la valeur est celle indiquée par l'échelle de ce côté. Illustration 15: Diagramme triangulaire (Source :Wikiversité, Introduction à la science des matériaux, Diagrammes binaires) Dans l'exemple ci contre, le point rouge correspond donc à 20 % de A, 20 % de B et 60 % de C. Le défi avec ces représentations est de déterminer les outils nécessaires à leur transcription en visualisation sur internet. La suite de nos recherches, le temps restant sur ce projet, se concentrera sur ce travail. 39

42 II PROTOTYPE Ce prototype n'est à l'heure actuelle pas entièrement terminé. Pour sa partie cliente (l'essentiel de l'application), le travail est accompli mais il reste beaucoup de choses à faire sur le traitement du fond de carte notamment pour optimiser cette visualisation. 1 Solution technique Comme pour le catalogue, toute la partie programmation de l'application se situe côté client. L'application s'appuie donc sur HTML, CSS et JavaScript (illustration 15). Illustration 16: Organisation de l'application côté client Mis à part OpenLayers, la différence avec le catalogue tient dans les bibliothèques JavaScript utilisées. 1.1 Bibliothèques JavaScript Le catalogue nous a permis de prendre en main JavaScript, et particulièrement la bibliothèque ExtJS. En abordant cette nouvelle application, nous sommes donc partis sur la même base en pensant que ExtJS répondrait à nos besoins, sa dernière version, Ext4, proposant tout un choix de graphiques et diagrammes. 40

43 Mais associer cartographie et diagramme nécessite d'utiliser GeoExt. Or cette bibliothèque n'est pas compatible avec la dernière version. Malgré de nombreux essais, nous n'avons pas réussi à obtenir un résultat concluant. La solution est venue de Development Seed avec JQuery. a) JQuery Le but de cette bibliothèque sous licence GNU GPL est de simplifier les commandes communes de JavaScript. Il intègre notamment le parcours et la modification du DOM, la gestion d événements et la manipulation des feuilles de style CSS. Par rapport à ExtJS utilisée pour le catalogue, cette bibliothèque est plus légère à utiliser, et ne nous enferme pas dans un style prédéfini. Pour ce projet, où l'interface devait répondre à certaines exigences de design, JQuery permet d'animer plus finement une interface créée à la base avec des feuilles de style CSS. Ceci nécessite de penser en amont l'interface de «A à Z», mais le résultat est plus soigné que ExtJS. b) Tablesorter 1 Cette extension de JQuery permet de trier un tableau HTML côté client sans avoir à repasser par le serveur. c) Wax 2 Il s'agit d'une bibliothèque développée par MapBox pour Development Seed sous licence MIT 3 pour faciliter l'utilisation de bibliothèques cartographiques comme Modest Maps 4. Wax fournit notamment des fonctionnalités intéressantes pour afficher une information sur un objet survolé dans un cadre CSS précédemment créé. Cet outil a été développé pour une utilisation avec TileStream, l'outil de MapBox de partage de tuiles (mbtiles). Dans notre cas, nous nous en sommes servi pour afficher les informations au passage sur les ponctuels générés par OpenLayers La licence MIT est une licence de logiciel libre et Open Source. Elle donne à toute personne recevant le logiciel le droit illimité de l'utiliser, le copier, le modifier, le fusionner, le publier, le distribuer, le vendre et de changer sa licence. La seule obligation est de mettre le nom des auteurs avec la notice de copyright. 4 Modest Maps est une bibliothèque d'affichage de carte interactive. 41

44 1.2 Données La première étape a été d'extraire la couche des gisements ouest africains de la base de données et de la «nettoyer» des éléments inutiles à l'affichage (champs hérités de l'organisation de la table PostGIS, champs redondants, formatage homogène des informations numériques, etc.) pour gagner en poids et donc en performance dans le navigateur. Nous avons ensuite exporter cette couche au format GeoJSON 1. Ce format est plus léger que le GML anciennement utilisé. Le fichier est directement présent dans l'installation. Nous pouvons charger toute la donnée et travailler avec dans le navigateur sans surcharger ce dernier. Tout se passe côté client. 1.3 Thème graphique Le thème graphique de l'application (CSS et police de caractère) a été récupéré du projet de Development Seed et arrangé pour convenir à nos besoins. L'application originale fonctionnait sur la base de Modest Maps. Nous l'avons transformé pour qu'elle fonctionne avec OpenLayers. Il a donc été nécessaire de modifier le fichier CSS pour que celui ci s'adapte à OpenLayers. 1.4 Graphiques Avant de nous lancer dans la création de diagrammes complexes (cf I.2.4 Explorer les possibilités), nous avons intégré des graphiques à l'application pour juger de leur faisabilité en JavaScript. Il existe quelques bibliothèques qui permettent de créer des graphiques. Citons comme exemple Highcharts, ExtJS4, Google Charts ou encore Flot. Nous avions aussi la possibilité d'utiliser graphaël, extension de Raphaël.js dédiée aux graphiques. Ce dernier a l'intérêt d'être ouvert à la création de graphiques personnalisés, répondant ainsi plus à nos besoins. Cependant, pour le prototype, nous avons choisi de garder le modèle proposé par Development Seed : Google Image Charts 2. L'outil Google Image Charts permet de générer dynamiquement des graphiques (illustration 16) à partir d'une simple requête URL. Il suffit de faire passer les paramètres désirés en répondant aux spécifications de l'outil pour récupérer une image du graphique. Certes celle ci n'est pas interactive. Mais nous voulions arriver à 1 Le GeoJSON est un format open-source pour encoder de l'information géographique. Basé sur le format JSON (Javascript Object Notation) il ajoute à ce dernier la possibilité de stocker les informations relatives à de la donnée spatiale (géométrie et système de projection)

45 un résultat convaincant le plus rapidement possible. Cette solution semble en tout cas la plus simple à mettre en place. Illustration 17: Exemple de graphiques réalisés avec Google Image Charts (Source : FR/apis/chart/image/) Il ne reste plus qu'à intégrer l'image récupérée au bon endroit. Pour le prototype, le graphique apparaît au survol des objets dans le cadre des informations de l'objet. 2 Réalisation de l'application Cette application laisse une place très importante à la carte puisque elle occupe les 2/3 de l'espace. Profitant de CSS3, les ombres et les effets de transparence mettent en relief les différents éléments (illustration 17). Le fond de carte est le fond par défaut d'openlayers. Le bandeau horizontal transparent noir en haut affiche le titre. À droite de ce bandeau, un bouton permet d'afficher un cadre avec les informations sur la donnée utilisée et l'interface (illustration 18) Au survol des gisements représentés par les symboles ponctuels oranges, le cadre à droite apparaît. Il présente les informations de l'objet, dont un graphique créé avec Google Image Charts. Une valeur (de 1 à 3) est attribuée aux classes des gisements (A, B, C). Le diagramme évolue simplement en fonction de cette valeur. il s'agit juste ici de tester un outil. Le bandeau horizontal blanc sous la carte regroupe une liste de gisement. La donnée en compte 40, nous en avons sélectionné 9 pour l'exemple. Cette liste se trouve dans le dossier «data» et est formaté en JSON (illustration 15). Lorsqu'un minerai est sélectionné, les gisements sur la carte sont filtrés sur ce minerai et un tableau affiche la liste des gisements et toutes les informations relatives à chacun. 43

46 Illustration 18: Prototype de l'application de visualisation de données Illustration 19: Cadre à propos des données 44

47 III DISCUSSIONS Ce prototype est une bonne base de travail. Il s'agit pour le moment plus d'un modèle que d'une application complète. Il pourra être perfectionné et réutilisé pour de nouvelles réalisations. L'avantage de cette interface est qu'elle laisse une grande place à la carte et à son design. Or, faute de temps, le fond de carte ainsi que la symbologie n'ont pas été étudiés mais le seront très prochainement. Ce genre de cartographie offrent des possibilités encore peu explorées pour les cartes de synthèse. Sur le papier, penser la carte signifie penser l échelle et les différents niveaux de lecture à cette échelle donnée (illustration 19). Il s'agit de jouer sur les degrés de perception, sur l'importance des messages transmis en fonction de la symbologie adoptée. Le travail du cartographe consiste à jouer avec les moyens graphiques pour s'extraire du plan de la carte en mettant en évidence dans le premier plan et sur un même niveau perceptif les thèmes importants. Illustration 20: Les plans de lecture (réalisée à partir de JP.Darteyre, Sémiologie, École Nationale des Sciences Géographiques, 2008) Sur internet, penser la carte, c'est penser les différents niveaux de lecture à toutes les échelles disponibles. Le zoom change chaque niveau de lecture et le message à faire passer. Les outils existent pour travailler finement la carte à chaque échelle. Ayant eu l'opportunité de le tester, l'outil Tilemill 1 de MapBox 2 par exemple, permet de préparer des fonds de carte très soignés, exportables en tuiles, exploitables par OpenLayers. Quant au SVG, il permet de créer une symbologie fine des objets 1 TileMill est un logiciel open-source pour produire des cartes facilement intégrables en ligne. Il s'appuie sur Mapnik, le moteur de rendu cartographique utilisé par OpenStreetMap. Il emprunte une partie de sa logique à celle des graphistes web, le système pour personnaliser les styles des cartes s'approchant des CSS. 45

48 vecteurs. La bibliothèque JavaScript Raphaël déjà évoquée, permettrait aussi de jouer sur l'animation de ponctuel, de les faire passer d'une forme à une autre, de les faire vibrer, luire, etc. Il s'agit d'autant de pistes de design à explorer. Après le fond et la carte, toutes les possibilités s'offrent à nous sur la manière d'afficher les informations relatives aux objets. Les graphiques complexes par exemple, que nous voulons créer, laissent une grande place à l'imagination quant à leur réalisation et leur intégration dans ce type d'application. Nous avons utilisé pour ce prototype un outil simple à mettre en place. Il en existe d'autres qui rendraient les diagrammes interactifs. Raphael de nouveau permettrait de lier graphiquement les objets de la carte à des visualisations graphiques. Avec ces outils open sources, Internet propulse les cartographes dans la création d'interface utilisateur. L'utilisation de la bibliothèque Gxp facilite la création d'interface de ce type puisqu'il suffit d appeler la classe viewer (illustration 6) de cette bibliothèque avec les paramètres souhaités pour avoir un résultat comme celui ci. 2 MapBox est un service de Development Seed qui fournit une suite d'outils open-source et des services pour créer et utiliser des cartes personnalisées sur internet. 46

49 CONCLUSION Durant ces six mois de stage, nous avons créé deux applications qui résument chacune d'elle une vision des perspectives de l'information géographique sur internet. D'une part un catalogue s'appuyant sur une infrastructure de données spatiales pour que les chercheurs du projet Waxi puissent partager leurs données. D'autre part un modèle HTML CSS JavaScript pour réaliser des visualisations de données pour un plus large public. Ces travaux s'inspirent chacun de solutions opensources développées par des entreprises en pointes de ce domaine :OpenGeo pour la première et Developement Seed pour la seconde. Nous aurions pu simplement installer des applications clés en main mais nous avons eu la chance d'évoluer dans un cadre propice à la formation. Dès le départ, l'objectif était d'apprendre et de maîtriser ces technologies et non d'installer les solutions existantes. Ceci est peut être paradoxal au vu du contexte, le télétravail n'étant pas le meilleur environnement pour demander de l'aide. Pourtant, toujours confronté à nous même, nous avons acquis une grande autonomie dans la réalisation de ce type de projet, couvrant toutes les étapes, de la conception, à leur mise en ligne en passant par le développement. Techniquement, l'auto formation créé certainement des lacunes dans les enseignements qu'elle peut apporter, mais elle pousse aussi à la débrouillardise, l'autonomie et la ténacité, surtout en programmation. Nous avions les compétences de base en développement JavaScript. Mais maîtriser une bibliothèque est une autre histoire. La formation SIGMA gagnerait a enseigner ce point, essentiel à la création d'application cartographique cliente. Pour la première partie, même si de nouvelles pistes sont envisageables, nous avons respecté les exigences de départs. Les droits d'accès à l'application ne devraient pas tarder à être distribués à tous les acteurs du projet Waxi. Nous devrions donc avoir très bientôt de nombreux retours pour développer une nouvelle version. Quant à la seconde application, ne partant de rien, nous considérons ce travail comme une étude technique préparatoire à la création de solutions. Le modèle développé montre le chemin d'une certaine idée de la visualisation de données. Il faudra par la suite créer des outils open sources capables de générer des visuels spécifiques à la géologie. Les deux aspects de la géomatique abordés au cours de ce stage sont pour nous une valeur sûre, au moins pour les cinq prochaines années. Pour les catalogues, cela dépend de l'ouverture des données publiques et donc des décisions politiques qui coordonnent cette initiative. Nous avons vu aux États Unis une coupe nette du budget alloué au portail data.gov lancé en 2008 et nous attendons toujours en France le travail du groupe Etalab chargé de mettre en ligne un data.gouv.fr. De cette 47

50 entreprise dépend en partie le second point de ce rapport car l'ouverture des données publiques stimulerait l innovation dans le domaine de la visualisation de données et donc notre rôle dans ce type de solution. 48

51 BIBLIOGRAPHIE/WEBOGRAPHIE Ressources bibliographiques D.Roche, Simple comme Ubuntu v 10.10, A la découverte de Linux, Framabook, V.Lozano. Unix, Pour aller plus loin avec la ligne de commande, Framabook, T.Templier & A.Gougeon, JavaScript pour le Web 2.0, JavaScript et la programmation orientée objet, pp , Ed. Eyrolles, F.Merrien & M.Leobet, La Directive Inspire pour les néophytes, 2eme édition, H.Doeleman & J.García, Mastering Advanced GeoNetwork, FOSS4G 2010 Barcelone. V. Merrien Soukatchoff, Milieux discontinus, T141, École des Mines de Nancy. T. Nemoto & K.Kimura, Development of Web GIS System for Sharing and Visualising Geologic Data, JP.Darteyre, Sémiologie, École Nationale des Sciences Géographiques, Ressources internet Forums SIG généralistes : & Aide technique webmapping : Tutoriels JavaScript : Forum OpenGeo et Gxp : Site de Bryan McBride (modification GeoExplorer) : Geonode : Tutoriels (Debian) sur Apache, PostgreSQL, Tomcat, etc. : PostGis : GeoServer : Bibliothèques JavaScript : JQuery : ExtJS : OpenLayers : GeoExt : Gxp : Wax : 49

52 TABLE DES MATIÈRES Résumé...2 Abstract...2 Remerciements...3 INTRODUCTION... 4 CONTEXTE DU STAGE Géoscience Environnement Toulouse (GET) Institut pour la Recherche et le Développement (IRD) Projet WAXI...7 A. Infrastructure de Données Spatiales...9 I EXPRESSION INITIALE DES BESOINS Vision du projet Définition Principaux composants techniques théoriques Norme INSPIRE Exigences fonctionnelles Affichage Catalogue Téléchargement II PROTOTYPE Environnement de Travail Environnement matériel Environnement logiciel Solutions techniques SERVEUR Système d'exploitation Debian Base de données PostGIS...16 a) Origines des données...16 b) Système de Gestion de Base de Données (SGBD)...16 c) Modèle de Base de données Serveur Cartographique GeoServer...17 a) Mise en place b) Entrepôt et Espaces de travail...18 c) Les styles SLD d) Services web e) Sécurité Serveur HTTP Apache...19 a) Proxy

53 b) Sécurité Solutions techniques CLIENT Bibliothèques JavaScript...20 a) Sencha ExtJS b) OpenLayers c) GeoExt d) Gxp Thème graphique...22 a) Feuilles de style CSS b) Icônes Métadonnées a) Problème rencontré...22 b) Utilisation des fichiers XSL Réalisation de l'application Carte interactive Catalogue III DISCUSSIONS A propos de la gestion de ce projet A propos du code A propos des outils...30 B. Visualisation de données...32 I EXPRESSION INITIALE DES BESOINS Vision du projet Méthodologie Obtenir la donnée Fondamentaux a) Que cherchons nous à représenter?...35 b) Quel public visons nous?...35 c) Dans quel but? Choisir les outils Explorer les possibilités...36 a) Diagrammes classiques...36 b) Symboles structuraux et diagrammes d'orientation...37 c) Diagrammes triangulaires...39 II PROTOTYPE Solution technique Bibliothèques JavaScript...40 a) JQuery b) Tablesorter c) Wax

54 1.2 Données Thème graphique Graphiques Réalisation de l'application...43 III DISCUSSIONS CONCLUSION BIBLIOGRAPHIE/WEBOGRAPHIE...49 Ressources bibliographiques...49 Ressources internet Annexes

55 INDEX DES ILLUSTRATIONS Illustration 1: Exemple d'interface type "SIG"...13 Illustration 2: Organisation côté serveur...16 Illustration 3: Organisation originale des données...17 Illustration 4: Organisation de l'application côté client...21 Illustration 5: Interface du volet carte interactive...25 Illustration 6: Classes JavaScript appelées pour le volet carte interactive...26 Illustration 7: Interface du volet catalogue...27 Illustration 8: Filtre sur une emprise géographique...28 Illustration 9: Classes JavaScript mobilisées pour le volet catalogue...29 Illustration 10: Gestion de projet Agile...30 Illustration 11: L'application de visualisation réalisée par Development Seed...37 Illustration 12: Mesure du pendage...38 Illustration 13: Pendage sur Abaque de Wulff...39 Illustration 14: Diagramme de Schimdt...39 Illustration 15: Diagramme triangulaire...40 Illustration 16: Organisation de l'application côté client...41 Illustration 17: Exemple de graphiques réalisés avec Google Image Charts...44 Illustration 18: Prototype de l'application de visualisation de données...45 Illustration 19: Cadre à propos des données...45 Illustration 20: Les plans de lecture...46 Toutes les illustrations non annotées sont de l'auteur et ont été réalisées avec Inkscape. Les icônes utilisées proviennent de l'ensemble Faenza disponible sous licence GNU/GPL à l'adresse suivante : Icons