Rapport TFE Hoarau3_save17h15_261009_corrige
Transcription
Rapport TFE Hoarau3_save17h15_261009_corrige
Stage de Travaux de Fin d’Etudes Cycle des Ingénieurs diplômés de l’ENSG - 3ème année Master CarthaGéo Suivi à long terme du site hydrothermal Lucky Strike (Dorsale Nord Atlantique) Opérations de terrain et mise en valeur des données Charlotte HOARAU 9 Novembre 2009 Rapport non confidentiel - Page 2 - Jury Président du Jury : Michel KASSER, directeur de l’ENSG Commanditaire : IPGP Institut de Physique du Globe de Paris 4, place Jussieu 75005 Paris France Encadrement : Javier ESCARTIN, IPGP, maître de stage Emmanuel FRITSCH, département Cartographie et Analyse de l’information Géographique (DCAIG), ENSG, rapporteur principal Joël BOULIER, laboratoire Géographie-Cités, Université Paris I Panthéon Sorbonne, rapporteur principal Responsable du cycle ingénieur : Serge BOTTON, direction des études, ENSG Responsable du Master CarthaGéo : Antonine RIBARDIERE, laboratoire PRODIG, Université Paris I Panthéon - Sorbonne Tuteur du Master CarthaGéo : Francis DHEE, département Cartographie et Analyse de l’information Géographique (DCAIG), ENSG Tuteur du stage pluridisciplinaire : Michel LANSMAN, direction des études, ENSG © ENSG Stage de Travaux de Fin d’Etudes : du 05 Mai au 30 Septembre 2009 Internet Diffusion Web : Intranet Polytechnicum Intranet ENSG Type de document : Rapport de stage TFE de 3ème année du cycle ITGCE Nombre de pages : 109 dont 38 d’annexes Système hôte : Microsoft Office Word 2003 Modifications : EDITION REVISION DATE PAGES MODIFIEES 1 0 07/08/09 Création - Page 3 - Glossaire Adélie Logiciel développé par Ifremer, implémenté sous la forme d’une extension d’ArcMap, et permettant le traitement des navigations des plongées sousmarines. Ajax Asynchronous Javasript and XML Ensemble de fonctions javascript destinées à améliorer la fluidité de la consultation des pages Internet. ArcGIS – ArcView - ArcCatalog - ArcMap Logiciel SIG développé par l’entreprise ESRI. ArcGIS désigne la gamme de produits, ArcVIEW est le type de license utilisé durant le stage. ArcMap et ArcCatalog sont les deux logiciels de la gamme ArcGIS utilisés durant le stage, le premier permet le traitement et la cartographie des données et le second leur gestion. BEA Bureau d’Enquêtes et d’Analyses pour la sécurité de l’aviation civile CSS Cascading Style Sheets ENSG Ecole Nationale des Sciences Géographiques ESRI Environmental Systems Research Institute Entreprise mulinationale de conception et de développement de logiciels SIG et de cartographie HTML Hyper Text Markup Language Ifremer Institut Français de Recherche pour l'Exploitation de la MER IPGP Institut de Physique du Globe de Paris IGN Institut Géographique National JPP Jauge de pression MCD Modèle Conceptuel de Données - Page 4 - MPD Modèle Physique de Données OBS Ocean Bottom Sismometer OGC Open Geospatial Consortium Organisation internationale regroupant 361 agences gouvernementales, entreprises ou universités ayant pour objectif d’améliorer l’interopérabilité dans le domaine de la publication de l’information spatiale par la définition et la promotion de protocoles standardisés d’échange de données géographiques géoréférencées. PHP Hypertext Preprocessor SADT Structured Analysis and Design Technique Méthode de description graphique d’un système complexe décomposant un processus en étape et sous-étapes successives et représentant la « matière d’œuvre » en entrée, « la valeur ajoutée » en sortie, les « contraintes » de contrôle du processus et les « moyens » de réalisation. SIG Système d’information géographique Les SIG sont des logiciels destinés à analyser, archiver, acquérir, abstraire et afficher les données géographiques WFS / WMS Web Feature Service / Xeb Map Service Protocoles standards d’échange de données raster et vectorielle, décrits dans l’OpenGIS par l’OGC W3C Word Wide Web Consorcium Organisme de standardisation du contenu des pages Internet visant à améliorer l’interopérabilité et l’accessibilité des données sur Internet ainsi que le design des pages - Page 5 - - Page 6 - Sommaire Sommaire Jury Glossaire Sommaire Résumé Abstract Liste des Annexes Liste des Figures Remerciements Introduction 3 4 7 11 11 12 13 15 17 I. 19 Contexte et Enjeux Scientifiques A. B. C. Présentation de L’Institut de Physique du Globe Présentation de l’équipe de GéoSciences Marines Présentation du projet MoMAR 19 19 20 Réalisation d’une interface de partage de données 21 II. A. Inventaire des données mises en lignes 1. Les sources de données 21 a) b) La Géodatabase ArcGIS Les Campagnes en mer i. Données acquises par les capteurs des engins et du PourquoiPas ii. Données issues des rapports de plongées c) Les données créées durant le stage i. Métadonnées sur les campagnes du projet MoMAR ii. Données images et métadonnées associées iii. Gestion et sécurité du site créé 2. Modèle Conceptuel de données a) Sécurité des données i. Protection contre les tentatives de piratage ii. Restrictions d’accès au site Internet b) Données géographiques et temporelles c) Les plongées, nœud de liaison entre les données 3. 21 Implémentation de la base de données - Page 7 - 21 23 23 23 24 24 24 24 25 26 26 26 27 27 28 Sommaire B. 28 Analyse fonctionnelle 1. 2. Organisation du site Internet Inventaire des fonctions nécessaires a) Exploration des données des campagnes MoMAR i. Sélection des données ii. Navigation iii. Affichage des données b) Reconstitution de plongées virtuelles i. Sélection des données ii. Visualisation virtuelle des plongées iii. Navigation temporelle c) Fonctionnalités générales 3. Interfaces graphiques a) b) C. 31 33 Cartographie Interactive Plongées virtuelles 35 Architecture a) b) 2. 35 Client-Serveur et Serveur cartographique WMS Organisation physique des fichiers Solutions techniques Langages de programmation i. Html et CSS ii. Javascript iii. PHP et SQL b) Technologies Explorées i. OpenLayers ii. GéoServer c) Bibliothèques supplémentaires i. Prototype ii. Scriptaculous iii. FancyZoom iv. JpGraph v. FPdf Gestion de projet a) b) c) 35 36 38 a) 3. 29 29 29 29 30 30 30 30 30 31 Réalisation 1. 28 29 38 38 38 39 39 39 41 42 42 43 44 44 44 45 Processus de mise en ligne Déroulement du stage Perspectives de développement - Page 8 - 45 46 49 Sommaire III. 50 BathyLuck09’ A. Navigation des engins submersibles 1. 2. Logiciels et Formation Préparation des plongées 3. Données et Traitements a) b) c) B. 50 51 Élaboration des trajectoires des plongées Cartographie de travail Lien avec l’équipe de pilotage des engins a) b) c) Données brutes Reconstitution de la navigation réelle Données finales C. 59 60 60 61 Rapports Alamer Cartographie de synthèse 64 Gestion des données 1. 2. 53 53 57 58 Cartographie exploratoire et Aide à la décision Synthèse des opérations a) b) 51 52 52 53 Opératrice SIG 1. 2. 50 Politique de sauvegarde Intégration des données 64 65 i. Base de données administrateur ii. Base de données Utilisateur sous ArcGIS iii. Base de données PostGresSQL 65 66 66 67 69 Conclusion Bibliographie 69 70 Rapports Imprimés Sites Internet consultés Programmation et Webmapping Entraide informatique Entraide Géomatique Frameworks en JavaScript Frameworks en PHP Systèmes de Gestion de Bases de Données Géosciences Marines 70 70 70 70 70 71 71 Le Projet MoMAR WHOI – Woods Hole Oceanographic Institute MGDS – Marine GéoSciences Data System 71 71 71 71 Base de données 72 Annexes - Page 9 - - Page 10 - Résumé Le caractère pluridisciplinaire des Géosciences marines implique un besoin de standardisation, d’harmonisation et de partage des données océanographiques. C’est là tout l’enjeu du stage effectué à l’IPGP du 5 mai au 1er octobre 2009 avec Javier Escartin. Deux missions ont été réalisées afin de mener à bien l’ « Etude à long terme du Site Hydrothermal LuckyStrike » : d’une part, la banque de donnée mise en place par J. Renard au cours de son stage TFE de l’ENSG a été enrichie lors de la campagne Bathyluck09 ; d’autre part, l’ensemble des données disponibles sur la zone MoMAR ont été mise en ligne sur Internet. Les acteurs du projet MoMAR peuvent ainsi consulter les données et métadonnées via un espace de cartographie interactive et reconstituer les plongées virtuellement. Abstract Marine Geosciences are definitively multidisciplinary; that’s why standardisation, harmonisation and sharing data is needed in this knowledge domain. This was the stake of the internship performed with Javier Escartin at IPGP between the 5th of May and the 1st of October of 2009. Two missions have been done in order to conduct the « Long-Term Study of the LuckyStrike Vent Site »: on the one hand, the database set up by J. Renard during his end study internship had been completed during the Bathyluck09 cruise ; on the other hand, all the available data about the MoMAR area have been put online on the Internet. Members of the MoMAR project can now visualise data and metadata thanks to an interactive map and replay virtual dives. - Page 11 - Liste des Annexes Annexe 1 - Engins submersibles 72 Annexe 2 - Modèle physique de données 73 Annexe 3 - Serveur cartographique grâce à GeoServer 76 Donnée de départ : 1. Formatage des données pour GéoServer 2. Stockage des données dans GéoServer 3. Configuration du service WMS dans GéoServer 4. Vérification Tutoriel sur le site de Geoserver Info sur les CoverageStores Info sur les Coverages Couches WMS en place 76 76 77 77 77 78 78 78 78 Annexe 4 : Carnet de bord 79 Annexe 5 – Cruise Report - Navigation Victor Navigation 89 89 Positioning systems 89 89 89 89 Estimated Navigation BUC – Base Ultra Courte Two complementary systems Data processing 89 Raw Data Methodology Output Data 89 91 91 Chronological summary Sampling dives Survey Dives 92 92 99 104 AUV Navigation Data and Positioning systems 104 PHINS – Estimated navigation GAPS – Global Acoustic Positioning System 104 104 Data processing 104 Raw Data Methodology Output Data 104 104 105 Chronological summary 105 - Page 12 - Liste des Figures Figure 1 - Fonctionnement général de la banque de données 21 Figure 2 –Modèle conceptuel et Organisation physique de la BD utilisateur 22 Figure 3 - Extrait du rapport de la plongée 361 de la campagne MoMAR08 23 Figure 4 – Modèle Conceptuel des Données mises en lignes 25 Figure 5 - Interface de cartographie interactive réalisée durant le stage 32 Figure 6 - Organisation du module de reconstitution des plongées 33 Figure 7 - Export du module vidéo sous forme de fiche synthétique 34 Figure 8 - Architecture du site Internet réalisé 36 Figure 9 - Organisation physique des fichiers du site Internet 37 Figue 10 - Zone de cartographie intéractive du site dédié au projet MoMAR 41 Figure 11 – Barre de défilement dans le temps 43 Figure 12 – Menus déroulants de paramétrage de la zone cartographique 43 Figure 13 – Modèle SADT du processus de mise en ligne 45 Figure 14 – Diagramme de GANTT initial 46 Figure 15 – Diagramme de PERT initial 46 Figure 16 – Diagramme de GANTT intermédiaire 47 Figure 17 – Diagramme de PERT intermédiaire 47 Figure 18 – Diagramme de GANTT final 48 Figure 19 – Diagramme de PERT final 48 Figure 20 - Interface d’import des données du Victor 6000et du Nautile, Ifremer 50 Figure 21 - Interface du logiciel Alamer, Ifremer 50 Figure 22 - Carte de préparation d’une plongée MMR réalisée avec Victor6000 52 Figure 28 – Outils de filtrage proposés par Adélie SIG 55 Figure 29 – Outils de lissage proposés par Adélie SIG 56 Figure 30 – Trajectoire de l’AUV lors d’une descente ; 56 Figure 31 – Synthèse des plongées de cartographie 57 Figure 32 – Synthèse des plongées de cartographie 58 Figure 33 – Exploration par CTD 59 Figure 34 – Interfaces de sélection des images et de rédaction du rapport 60 Figure 35 – Répartition de l’instrumentation sismique et de pression 61 - Page 13 - - Page 14 - Remerciements Je tiens en tout premier lieu à remercier Javier Escartin pour la confiance qu’il m’a témoignée tout au long de ce stage passionnant, pour sa disponibilité et pour sa bonne humeur au quotidien. Merci également à Laurent Pouilloux, toujours disponible et motivé, pour l’aide technique et la multitude de conseils avisés qu’il m’a apportés durant la phase de développement Web. Je pense ensuite bien sûr à toute l’équipe de GéoSciences marines de l’IPGP, en particulier à Mathilde et Adélie avec qui ce fut un réel plaisir de travailler. Je voudrais également remercier toute l’équipe embarquée sur le PourquoiPas, équipe au sens large englobant aussi bien le personnel scientifique, l’équipe technique en charge des engins et l’équipage, sans qui cette merveilleuse aventure n’aurait pas pu avoir lieu. Je remercie aussi l’équipe pédagogique et administrative de l’ENSG et du Master CarthaGéo, qui m’a suivie de près ou de loin durant le stage, de m’avoir soutenue techniquement et de m’avoir permis de participer à la campagne océanographique Bathyluck09 malgré les nombreux rebondissements et changement de calendrier. En particulier, je pense à Marie-Françoise Alberty qui a su être réactive dans l’urgence malgré les délais minimalistes imposés par la force des choses. Enfin, un grand merci à tous ceux qui m’ont suivi durant mon périple au milieu de l’Atlantique, notamment Damien et toute ma famille. - Page 15 - - Page 16 - Introduction Introduction Ce stage de fin d’étude s’est déroulé dans les locaux de l’IPGP à Jussieu sous l’encadrement de Javier Escartin, chercheur en GéoSciences Marines, du 5 mai au 1er octobre 2009. L’objectif principal était de permettre l’étude à long terme du site hydrothermal LuckyStrike situé sur la dorsale Médio Atlantique. La compréhension d’un site hydrothermal et volcanique tel que LuckyStrike est réalisée par des études pluridisciplinaires et étalées dans le temps. Dans ce contexte, il est indispensable de concevoir une politique globale et coordonnée d’investigation scientifique. Une telle stratégie passe inévitablement par la mise en commun des données et des résultats obtenus lors des différentes campagnes océanographiques, premier pas de la collaboration scientifique. Le stage s’est donc divisé en deux missions parallèles: la mise en place d’un espace de consultation des données et des métadonnées sur Internet, et l’enrichissement de la base de connaissances acquises par des études passées et formalisées par Jérémy Renard lors de son stage TFE durant l’été 2008. Une attention toute particulière a été apportée à l’importance du volume de données à manipuler et à la nécessité d’opter pour des compromis efficaces entre la place de stockage disponible et l’efficacité des dispositifs de consultation des données mis en place. Le présent document s’organise autour des deux missions principales : après avoir brièvement décrit l’organisme d’accueil et les enjeux scientifiques engendrés par l’étude des dorsales océaniques, le processus de réalisation d’une interface Internet de partage des données est détaillé depuis l’analyse des besoins, jusqu’à la mise en œuvre en passant par les choix techniques réalisés. Dans un deuxième temps, les différentes contributions lors de la campagne océanographique Bathyluck09’ montrent comment la base de connaissance a été enrichie durant le stage. - Page 17 - Introduction - Page 18 - l. Contexte et Enjeux Scientifiques I. Contexte et Enjeux Scientifiques A. Présentation de L’Institut de Physique du Globe Créé en 1921, l’IPGP est un des grands établissements d’enseignement supérieur et de recherche français actuels. Son principal domaine d’investigation est celui des GéoSciences telles que la géophysique, la géochimie ou la géologie. L’institut explore donc toutes les composantes de l’étude de la Terre solide et réalise ainsi l’observation des phénomènes naturels par des mesures à terre, en mer ou dans des laboratoires expérimentaux grâce à environ 480 chercheurs, ingénieurs, techniciens, doctorants, étudiants et personnels administratifs regroupés en 14 équipes de recherches. L’IPGP est impliqué dans tous les enjeux scientifiques déterminants de notre temps. D’un côté, il prend part aux grandes interrogations concernant la formation de la Terre ou les interactions entre la Terre solide et les enveloppes fluides. D’autre part, il a d’importantes responsabilités dans l’étude des risques naturels : le risque volcanique par la surveillance des trois grands volcans actifs français, le risque sismique par la participation au réseau mondial de stations sismologiques GéoScope et le risque magnétique par la participation au réseau mondial d’observatoires magnétiques Intramagnet. Enfin, il participe au programme sur le stockage du CO² ainsi qu’à l’élaboration de missions spatiales. B. Présentation de l’équipe de GéoSciences Marines Appelée la « Planète Bleue », notre Terre est recouverte en majorité d’eau (70%). La plupart des phénomènes tectoniques, volcaniques et sismiques a donc lieu dans les océans. Ceux-ci apparaissent donc à la fois comme une source de vie indispensable à l’homme et à la biosphère et comme le théâtre des plus importants bouleversements que subit notre planète. C’est ce qui a motivé l’intégration d’une équipe de GéoSciences Marines à l’IPGP afin d’observer l’ensemble des phénomènes naturels sous l’œil de la spécificité marine. L’équipe de GéoSciences Marines est donc une équipe de recherche intrinsèquement pluridisciplinaire qui aborde l’ensemble des composantes des géosciences dans un environnement marin : géophysique, volcanisme, tectonique, sismicité, fluides et flux de chaleurs, biologie… Pour cela, il lui faut concevoir une instrumentation adaptée aux contraintes marines et sous marines et affréter des navires scientifiques pour mener à bien des campagnes en mer. Une quarantaine de scientifiques s’attèle donc ici à percer les secrets des profondeurs en relevant chaque jour des défis scientifiques et technologiques. - Page 19 - l. Contexte et Enjeux Scientifiques C. Présentation du projet MoMAR Le projet MoMAR est un projet scientifique international qui a pour principal objectif le suivi des systèmes hydrothermaux de la dorsale Médio-Atlantique et des écosystèmes qui leur sont associés. Jusqu’à présent, quatre grands sites présents à différentes profondeurs et au sein de contextes géologiques différents ont été identifiés sur la zone MoMAR qui s’étend sur 250 kilomètres de dorsale océanique. Le projet donne lieu à des travaux de recherches pluridisciplinaires d’une grande variété dans des domaines tels que le volcanisme (étude de l’activité et flux volcaniques), la tectonique, la sismicité, l’hydrothermalisme (étude de la composition et de la température des fluides sortant des sites hydrothermaux), la microbiologie. La zone MoMAR étant à proximité de l’archipel des Açores, son accessibilité par bateau a jusqu’à présent été mise à profit par de nombreuses campagnes de cartographie des sites et d’études géophysiques de mesures et d’échantillonnages ponctuels. Cependant, l’installation d’un observatoire permanent au fond de l’océan est actuellement un des objectifs du projet MoMAR qui améliorera la compréhension totale du processus hydrothermal par un suivi simultané, en continu et en semi-temps réel de toutes ses composantes. Les enjeux technologiques liés au projet MoMAR sont de taille puisque l’exploration des fonds marins engendre à peu près autant de contraintes que l’exploration spatiale. D’une part, le développement de capteurs adaptés et d’engins submersibles performants est le résultat de révolutions technologiques directement liées aux géosciences marines. D’autre part, l’autonomie énergétique, la transmission des données en milieu aquatique, la robustesse des instruments dans des conditions extrêmes de température et de corrosion sont autant d’obstacles à surmonter lors de la mise en place d’un observatoire scientifique en fond de mer. Le succès du projet MoMAR dépendra donc de l’implication mais surtout de la collaboration des différentes équipes étudiant cette zone. Cette collaboration passe à la fois par la coordination des programmes scientifiques, la planification de campagnes océanographiques communes, le partage des découvertes technologiques et l’échange des informations scientifiques et des données collectées. Le projet s’inscrit donc dans plusieurs programmes scientifiques au niveau européen comme un des nœuds du futur réseau d’observatoires ESONET par exemple, mais aussi au niveau international dans le cadre du programme InterRidge qui coordonne les recherches internationales et interdisciplinaires sur les dorsales océaniques. De ce point de vue, le stage réalisé avec Javier Escartin, Coordinateur du comité MoMAR pour le programme international InterRidge et chef de plusieurs missions sur la zone MoMAR, par la participation à une campagne internationale mais aussi par la mise à disposition de données et de métadonnées sur les campagnes réalisées est une étape importante dans la réalisation du projet MoMAR. - Page 20 - ll. Réalisation d’une interface Web de partage des données II. Réalisation d’une interface Web de partage de données A. Inventaire des données mises en lignes 1. a) Les sources de données La Géodatabase ArcGIS Cette base de données géographique a été mise en place par Jérémy RENARD durant son stage TFE de l’ENSG durant l’été 2008. La mise en place de cette base de données est le résultat d’un travail d’investigation et de regroupement des données et métadonnées ainsi que d’une harmonisation des données afin d’obtenir un ensemble cohérent. Ce processus est décrit dans le rapport de stage de Jérémy RENARD. La banque de données ainsi mise en place est divisée en deux bases différentes (Cf figure 1) : une base administrateur qui contient les fichiers de données bruts et sert de sauvegarde des données, et une base utilisateur sous forme de géodatabase ArcGIS regroupant l’ensemble des données géographiques collectées. Cette organisation suggère l’intervention indispensable d’un opérateur SIG pour formater et intégrer les données dans la base utilisateur. Ce sera mon rôle lors de la campagne BathyLuck’09. Figure 1 - Fonctionnement général de la banque de données Cette banque de données contient des données hétérogènes du point de vue de la source, des traitements effectués et du type de géométrie mais présente des métadonnées et une structure attributaire harmonisées classées par zone d’étude puis par thématique. Elle constitue une des sources majeures des données mises en ligne. - Page 21 - ll. Réalisation d’une interface Web de partage des données Les éléments de la banque de données mis en ligne sont listés ci-dessous par type de géométrie: Données vectorielles ponctuelles: Sites d’études et points de repères (« markers ») Instruments scientifiques (Capteurs de température, Sismomètres, Jauges de pression, Colonisateur de micro-biologie, Benchmarks, …) Echantillons prélevés (Roches, Fluides, Biologie, …) Données vectorielles linéaires : Trajectoires des engins submersibles Courbes de niveau sous-marines (isobathes) Données magnétisme. raster de bathymétrie, de Sonar, de gravimétrie et de La figure 2 ci-dessous présente le modèle conceptuel et l’organisation physique de la banque de données mise en place par Jérémy Renard. Figure 2 –Modèle conceptuel et Organisation physique de la base de données utilisateur - Page 22 - ll. Réalisation d’une interface Web de partage des données b) Les Campagnes en mer Lors des campagnes océanographiques, une quantité importante de données est collectée, non seulement par les chercheurs dans leurs domaines respectifs mais également par les engins sous-marins et leurs capteurs et enfin par le navire qui dispose lui aussi de capteurs. i. Données acquises par les capteurs des engins et du PourquoiPas Les données enregistrées lors des plongées sous-marines sont exploitées selon un processus décrit au paragraphe « III.A. Navigation des engins submersibles ». Afin de mettre en valeur les données vidéos, les informations suivantes ont été extraites des données traitées avec Adélie par Jérémy RENARD durant la campagne MoMAR’08 : Les caractéristiques générales des plongées (notamment les heures de début, de fin, d’arrivée au fond et de départ du fond) La position, l’orientation et la vitesse de l’engin submersible L’orientation et le zoom de la caméra de prise de vue Les données issues des éventuels capteurs ajoutés à l’engin ii. Données issues des rapports de plongées D’autre part, lors des plongées, les personnes responsables de quart ou les personnes embarquées dans les engins sous-marins notent le déroulement des opérations scientifiques. Ces commentaires sont ensuite mutualisés grâce à un autre logiciel édité par Ifremer, Alamer. Ce logiciel propose aux chercheurs une aide à la rédaction de rapports de plongée et de campagne. Les rapports des plongées de la campagne MoMAR’08 ont été exploités afin de rendre compte du déroulement des plongées et des évènements scientifiquement intéressants. La figure 3 ci-dessous présente un extrait d’un rapport de plongée. Figure 3 - Extrait du rapport de la plongée 361 de la campagne MoMAR08 Les informations utilisées dans ces rapports de plongée concernent essentiellement le type et la chronologie des opérations réalisées : c'est-à-dire le commentaire rédigé par le responsable de la manipulation et la date complète (jour et heure). - Page 23 - ll. Réalisation d’une interface Web de partage des données c) Les données créées durant le stage Certaines données ont enfin été créées ou recherchées lors du stage afin d’enrichir le lot des données disponibles et pour les besoins de la réalisation du site Internet. i. Métadonnées sur les campagnes du projet MoMAR D’une part, des métadonnées ont été récoltées concernant les campagnes présentes dans la base de données administrateur réalisée par Jérémy RENARD. Ces métadonnées concernent principalement les engins submersibles, les navires et les dates précises de début et de fin des campagnes. C’est une amélioration notable de la géodatabase ArcGIS qui constituait la base de données utilisateurs. En effet, cette géodatabase contenant uniquement des données géographiques, les métadonnées se retrouvaient dispersées dans chaque fichier. On retrouvait par exemple des informations sur le navire ou sur la campagne dans des fichiers regroupant un type d’instrument scientifique, informations qui n’étaient visiblement pas propres à chaque instrument puisqu’elles apparaissaient de manière totalement identique pour un grand nombre d’éléments de la base. La collecte des métadonnées a donc permis de séparer les données selon un modèle conceptuel de données présenté dans le paragraphe suivant. ii. Données images et métadonnées associées D’autre part, des données images ont été créées pour mettre en valeur les vidéos ainsi que les métadonnées associées suivantes : Nom de l’image Chemin d’accès au fichier Caméra de prise de vue Source du fichier (DVD original ou mp4 compressé) Numéro de plongée Le processus de génération des vignettes à partir de vidéos sera décrit au paragraphe « II.C.3.a) Processus de mise en ligne ». iii. Gestion et sécurité du site créé Enfin, des données ont été saisies afin d’assurer la gestion et la sécurité du site Internet réalisé. Il s’agit des informations concernant chaque page Internet, les utilisateurs potentiels de cet espace de partage, les types d’utilisateurs et leur droit d’accès aux différentes pages. Plusieurs mécanismes de sécurité et de gestion de l’accès au site et au serveur ont ainsi pu être mis en place. Ils sont décrits au paragraphe « II. A. 2. a) Sécurité des données ». - Page 24 - ll. Réalisation d’une interface Web de partage des données 2. Modèle Conceptuel de données Le modèle conceptuel de données (MCD) suivant représente l’ensemble des données utiles à la mise en ligne du site Internet, ce sont des données scientifiques, de gestion ou bien des métadonnées. Ce MCD a été conçu dans le langage UML afin de faciliter sa compréhension par une grande majorité des personnes formées à la gestion des bases de données, selon le modèle objet. Figure 4 – Modèle Conceptuel des Données mises en lignes Il présente 18 classes et deux parties différentes, l’une dédiée aux données issues du projet MoMAR et l’autre contenant les données nécessaires à la gestion du site Internet. Les classes comportant une dimension temporelle ont été mises en valeur par la couleur verte. - Page 25 - ll. Réalisation d’une interface Web de partage des données a) Sécurité des données i. Protection contre les tentatives de piratage Deux mécanismes ont été mis en place en PHP pour protéger le site ainsi que le serveur mis à disposition par l’IPGP des éventuelles tentatives de piratage extérieures. Ils ne suffiront pas à protéger totalement le site contre de vrais pirates informatiques mais ils constituent deux protections élémentaires. D’une part, les URLs entrées par les internautes sont vérifiées afin d’éviter ce que l’on appelle parfois les injections SQL. En effet, une fonction PHP permet de « nettoyer » les URLs dans le but d’empêcher quiconque de lancer de manière simple un calcul important sur le serveur et ainsi de réduire l’accessibilité du site aux internautes « honnêtes ». D’autre part, une table de la base de données PostGres recense les pages du site à mettre en ligne. Cela permet d’attribuer un droit à chaque page en fonction du type d’utilisateur comme nous l’évoquions ci-dessus mais cela permet également de vérifier si la page demandée par l’internaute existe bien dans la base de données. C’est une deuxième façon de palier aux injections SQL. ii. Restrictions d’accès au site Internet Les données relatives au projet MoMAR présentent différents niveaux de confidentialités pour plusieurs raisons : certaines données sont soumises aux droits d’auteur, d’autres ne sont pas encore publiées et présentent donc une confidentialité scientifique, d’autres enfin peuvent aujourd’hui être mises à la disposition de tout un chacun. Afin de respecter ces contraintes d’accès aux données, trois types d’utilisateur ont été créés : Un type « administrateur » réservé au gestionnaire du site qui aura les droits de lecture et d’écriture sur l’ensemble des pages et données du site. Un type « MoMAR » réservé aux membres du projet MoMAR et des campagnes scientifiques qui aura le droit de lecture sur toutes les pages du site liées au projet MoMAR sauf la page cachée d’administration du site. Par cachée, on entend une page non accessible depuis les liens de l’ensemble des pages du site et dont il faut donc connaître l’URL précis pour y accéder. Un type « Public » qui sera le type par défaut et aura le droit de lecture sur certaines pages du site uniquement. D’autres types d’utilisateurs ont vocation à être ajoutés au fur et à mesure que le site Internet accueillera d’autres espaces de partage des données dédiés au différents laboratoires de l’IPGP. - Page 26 - ll. Réalisation d’une interface Web de partage des données b) Données géographiques et temporelles L’une des variables majeures de cet ensemble de données est le temps, qui permet de visualiser les plongées virtuelles ainsi que d’analyser les évolutions dans l’étude du site hydrothermal. Lors de la préparation des campagnes et des programmes de recherche scientifique, la chronologie est capitale ; elle permet de réaliser des opérations cohérentes avec les recherches passées et de comparer différents résultats dans le temps. Pour recréer une plongée temporelle, le déroulement des évènements a été recréé en reliant entre elles toutes les données repérables dans le temps, c’està-dire les images (issues des vidéos contenant une incrustation de l’heure), les informations concernant l’engin et la caméra, les commentaires scientifiques des personnes responsables et enfin, la position de l’engin grâce aux fichiers de navigation horodatés. C’est pour toutes ces raisons qu’une attention toute particulière est portée aux données temporelles lors de l’intégration des données dans la base. Plusieurs formats ont été utilisés afin de permettre plus de souplesse d’utilisation et de garantir la compatibilité de l’ensemble des données contenues dans la base : Le format « Time Stamp », proposé par PostGres, définit l’heure et la date. Il est possible également de préciser la zone horaire mais cette option n’a pas été exploitée étant donné que la zone MoMAR ne s’étend pas sur différents fuseaux horaires. Le format « epoch UNIX » représentant le nombre de secondes écoulées depuis le temps initial du système UNIX, c’est-à-dire le 1er Janvier 1970. Parfois la seule information de l’année était également suffisante. c) Les plongées, nœud de liaison entre les données La classe Plongée apparaît nettement comme une classe centrale du MCD. Ce sont les plongées qui relient une bonne partie des données entre elles. De même que pour les dimensions temporelle et géographique, les informations concernant les plongées ont donc été renseignées avec le plus grand soin, notamment l’identifiant servant de clé primaire à cette classe. En effet, lors d’une campagne, les plongées sont numérotées de deux façons : Par un numéro absolu correspondant au nombre de plongées effectuées par l’engin submersible concerné. Par un numéro relatif correspondant à la place de la plongée parmi celles de la campagne en cours. Le regroupement de ces deux identifiants et de l’engin ayant effectué la plongée aurait pu être utilisé comme identifiant unique mais, pour plus de clarté, un nouvel identifiant unique a été ajouté au moment de l’intégration des données dans la base. C’est celui-ci qu’il faudra veiller à utiliser dans les autres tables lors des futurs enrichissements de la base. - Page 27 - ll. Réalisation d’une interface Web de partage des données 3. Implémentation de la base de données Le Système de Gestion de Base de Données Relationnelle (SGBDR) choisi pour gérer l’ensemble des données mises en jeu est PostGreSQL. Développé depuis plus de 15 ans, ce logiciel libre bénéficie d’une importante communauté de développeurs et d’utilisateurs. Ainsi, les ressources sont nombreuses sur Internet : tutoriaux, forums d’entraide, documentation sur les fonctions et formats de données sont accessibles facilement à tous. La cartouche spatiale PostGIS a été ajoutée à PostGreSQL dans le but de gérer la dimension géographique des données. Cette extension propose des types de géométrie ainsi qu’un ensemble conséquent de fonctions liées à la géométrie des données telles que les calculs de distance ou de topologie, la gestion des systèmes de référence ou les calculs d’itinéraires sur des réseaux pour ne citer que les plus connues. L’interface Web d’administration phpPgAdmin proposée par PostGreSQL a été utilisée dans le cadre du stage pour créer les tables, les peupler, ajouter les contraintes relationnelles et attribuer différents droits selon l’utilisateur de la base de données mise en place. Le modèle physique de données (MPD) implémenté entièrement durant le stage est donné en Annexe 2. Il a été établi et retranscrit avec le plus grand soin afin d’optimiser la pérennité de la base en permettant à un éventuel futur administrateur de pouvoir facilement ajouter des données. Ce travail a permis de mettre en lumière certaines redondances dans les données stockées en comparaison avec le MCD, de les éliminer et ainsi d’optimiser la base de données en termes de taille et de lisibilité. B. Analyse fonctionnelle 1. Organisation du site Internet L’organisation envisagée pour le site Internet découle directement des différents objectifs de mise en ligne qui sont les suivants : La consultation et la cartographie des métadonnées de l’ensemble des campagnes concernant la zone MoMAR L’export de données brutes ou traitées collectées sur la zone MoMAR La reconstitution virtuelle des plongées grâce aux vidéos enregistrées Il a donc très vite été décidé de séparer les données concernant les campagnes et celles permettant la reconstitution des plongées. Deux interfaces graphiques différentes ont donc été conçues à cet effet : une interface de cartographie interactive et de téléchargement et une interface dédiée aux plongées virtuelles. Les zones d’export de données se trouveront dans chacune des deux interfaces et proposeront des données dans différents formats selon la consultation faite par l’internaute et ses droits d’accès. - Page 28 - ll. Réalisation d’une interface Web de partage des données 2. Inventaire des fonctions nécessaires L’inventaire ci-dessous est le fruit de nombreux entretiens avec Javier ESCARTIN et d’un rapide état de l’art dans le domaine de la mise en ligne de données océanographiques. Il retranscrit donc l’essentiel des besoins émis par un chercheur en GéoSciences marines, légèrement remodelés d’après les ressources existantes, reflet des habitudes des scientifiques dans ce domaine. Les fonctionnalités sont listées selon l’organisation du site décrite au paragraphe précédent puis selon leur importance relative. a) Exploration des données des campagnes MoMAR i. Sélection des données Selon la mission scientifique : c’est-à-dire la campagne et éventuellement les plongées ou l’équipe scientifique Chronologiquement Selon les différentes thématiques Sites d’étude (Sorties hydrothermales connues et Repères signalisés) Échantillons (de fluides, de roches, d’organismes biologiques) Instrumentation (Sismomètres, Capteurs de température, Jauges de pression, Colonisateurs microbiologiques, Courantomètres) et Mouillages Images saisies lors des opérations Données traitées (Bathymétrie, Gravimétrie, Sonar, Magnétométrie, …) ii. Navigation Déplacement dans la carte Zoom Progressif : vers une échelle plus grande ou plus petite Sur une emprise géographique : définie par des latitudes et longitudes maximales et minimales ou graphiquement sur la carte Sur zone : grâce à des zones d’étude prédéfinies Boîte à outils Calcul de distance Calcul de surface Coordonnées en un point iii. Affichage des données Gestion de la superposition et de l’ordre des couches Choix de la sémiologie - Page 29 - ll. Réalisation d’une interface Web de partage des données b) Reconstitution de plongées virtuelles i. Sélection des données Selon la plongée Selon le temps Selon la caméra (affichage des images issues d’une ou plusieurs caméras) Selon le type d’image (générées automatiquement à partir des vidéos ou capturées manuellement par les responsables des plongées) ii. Visualisation virtuelle des plongées plongées Visualisation synchronisée des images issues des vidéos de chaque caméra Visualisation des informations données par les capteurs du bateau et de l’engin submersible à l’instant de la prise de vue iii. Navigation temporelle Barre de navigation dans le temps Avance à la photo suivante Retour à la photo précédente Aller à une date (jour et heure) prédéfinie Retour au début de la plongée Avance en fin de plongée Avance rapide, Choix de la vitesse de défilement c) Fonctionnalités générales Export de données Choix du format (Excel, dbf, ShapeFile, pdf, txt, ASCII) Sélection des données à exporter Mise en page et personnalisation Import de données après une campagne Cet inventaire n’est bien entendu pas exhaustif dans le sens où de nouvelles fonctionnalités pourront se révéler nécessaires au cours de la phase de développement mais aussi une fois la mise en ligne réalisée grâce à un retour d’expérience des futurs utilisateurs. - Page 30 - ll. Réalisation d’une interface Web de partage des données 3. a) Interfaces graphiques Cartographie Interactive L’interface de cartographie interactive a été découpée en trois zones à la fois distinctes et complémentaires : Une zone de paramétrage de la carte et de sélection des données Une zone de cartographie, de visualisation des données Une zone dédiée à l’export des données La zone de paramétrage permet à l’utilisateur de sélectionner les données qu’il souhaite visualiser sous plusieurs critères : la date, la campagne océanographique, ou encore les différentes thématiques (profils de navigation des engins, sites d’étude, échantillons, instrumentation…). De plus, l’utilisateur peut définir l’emprise de la carte qu’il souhaite visualiser soit par des coordonnées géographiques soit par des zones d’intérêt prédéfinies. Cette zone de paramétrage a été placée à gauche afin d’attirer l’attention d’un utilisateur occidental qui envisage les informations de haut en bas mais également de gauche à droite. Elle a été réalisée sous forme de menus déroulants afin de pouvoir être visualisée entièrement si nécessaire ou partiellement si toutes les options de paramétrage ne sont pas nécessaires. La zone de cartographie présente les données sur des fonds cartographiques d’emprise et de précision différentes. Ces fonds sont le résultat de requêtes WMS afin d’améliorer la rapidité d’affichage. Ce processus est décrit dans les paragraphes « II. C. 1. a) Client-Serveur et Serveur cartographique WNS » et ‘II. C. 2. b) ii. GéoServer ». De plus, la zone de cartographie propose l’affichage de différents graticules afin de se repérer dans l’espace d’étude. L’utilisateur peut donc afficher ou pas ces graticules et choisir son fond de carte. La sémiologie a été établie en tenant compte des relations entre les différents thèmes mais d’autres choix pourraient être envisagés. Enfin, certains outils classiques ont été intégrés directement à la zone d’affichage cartographique : Des outils de déplacement et de zoom progressifs (grâce aux flèches et aux zooms avant et arrière) Des outils de déplacement et de zoom manuels (grâce à la main de déplacement et à la définition d’une zone à agrandir) Des outils de mesures de distance et de surface Des historiques de navigation L’affichage des échelles numérique et graphique courantes L’affichage des coordonnées géographiques du curseur de positionnement de la souris dans la carte - Page 31 - ll. Réalisation d’une interface Web de partage des données La zone dédiée à l’export propose des liens de téléchargement de données au format texte. Les exports sont triés par thématique et l’affichage des liens dépend du type d’utilisateur qui est connecté : les métadonnées sont téléchargeables par le grand public mais certaines données traitées ne sont accessibles que par des utilisateurs participants au projet MoMAR. Cette zone est celle qui présente le plus d’améliorations à apporter (Cf. « paragraphe II. C. 3. c) Perspective de développement »), notamment sur le choix du format d’export des données. La figure 5 ci-dessous présente l’interface de cartographie interactive et son organisation tripartite. Figure 5 - Interface de cartographie interactive réalisée durant le stage - Page 32 - ll. Réalisation d’une interface Web de partage des données b) Plongées virtuelles L’interface d’immersion dans une plongée a été conçue comme un multilecteur vidéo amélioré. Des informations viennent compléter les images dans l’esprit des dispositifs de réalité augmentée. L’interface est composée : D’un espace de visualisation synchronisée des images issues des caméras De plusieurs dispositifs de navigation temporelle D’éléments graphiques ou numériques complémentaires Figure 6 - Organisation du module de reconstitution des plongées Cette interface a été conçue pour une résolution d’écran minimale de 1024x768, résolution standard des écrans actuels. Elle sera ainsi adaptée à la plupart des ordinateurs récents et pourra être utilisée de la même façon que tous les lecteurs vidéo ou audio disponibles sur Internet. On pense par exemple aux lecteurs vidéos proposés par les sites YouTube ou Daylimotion ou encore aux lecteurs audios de tailles réduites proposés par les webradios. L’utilisateur devra dans un premier temps choisir une plongée grâce au menu déroulant situé en haut à droite de l’interface. Puis il pourra naviguer dans le temps entre le début et la fin de la plongée choisie grâce à la barre de défilement, aux boutons d’avancement ou de retour en arrière ou encore grâce à l’extrait du rapport Alamer. Enfin, il pourra exporter une fiche synthétique au format Pdf, un exemple est présenté ci-après. - Page 33 - ll. Réalisation d’une interface Web de partage des données Figure 7 - Export du module vidéo sous forme de fiche synthétique - Page 34 - ll. Réalisation d’une interface Web de partage des données C. Réalisation 1. a) Architecture Client-Serveur et Serveur cartographique WMS L’architecture adoptée présente plusieurs structures étudiées lors des cours de Webmapping de 2ème et 3ème année du cycle ingénieur de l’ENSG. Ce stage fut l’occasion de les mettre en œuvre et de les combiner au mieux. Il y a tout d’abord une architecture Client–Serveur classique dans laquelle les scripts déterminant le rendu graphique et le résultat des liens dynamiques de la page sont effectués du côté client tandis que les données sont stockées du côté serveur, de même que le moteur PHP effectuant les requêtes SQL permettant l’accès à la base de données. Ce mécanisme Client-Serveur est amélioré par l’utilisation de la technologie Ajax. Cette technologie permet de réduire les appels au serveur en effectuant des requêtes ciblées concernant des parties seulement de la page Internet affichée. La technologie Ajax est une des révolutions du Web 2.0 ; les mécanismes utilisés seront décrits dans le paragraphe « II. C. 2. c) Prototype » qui est dédié à la bibliothèque de fonctions javascript nommée Prototype qui propose entre autre une gamme de fonctions permettant la réalisation de requête Ajax adaptées aux navigateurs Internet classiques. Un serveur cartographique a également été mis en place pour optimiser l’affichage des données raster. Les données bathymétriques sont donc stockées par le serveur cartographique Géoserveur et mises à disposition sous la forme de couche WMS. Cette stratégie de mise à disposition de données sous forme de données standardisées est conforme aux normes de l’OGC. On peut donc espérer qu’elle soit pérenne dans le temps. De plus, la mise en place d’un serveur cartographique offre l’opportunité de proposer ces couches WMS à d’autres utilisateurs potentiels. Ce mécanisme pourrait s’avérer utile dans le futur si un tel service était mis en place pour le projet MoMAR. Enfin, un serveur cartographique externe (celui mis en place par Marine GeoScience Data System) a été utilisé par l’appel d’une des couches WMS disponible contenant des données bathymétriques multi-résolutions sur l’ensemble du globe. La figure 8 ci-après décrit schématiquement les liens existants entre le client, le serveur PHP, le serveur cartographique interne mis en place et un serveur cartographique externe. - Page 35 - ll. Réalisation d’une interface Web de partage des données Figure 8 - Architecture du site Internet réalisé b) Organisation physique des fichiers L’organisation physique des fichiers reflète l’architecture Client-Serveur décrite au paragraphe précédent par sa division en deux grands dossiers principaux : Le dossier « app » regroupant les fichiers concernant les requêtes effectuées sur le serveur en 3 parties : Un dossier « class » contenant les classes PHP supplémentaires utilisées pour la réalisation de ce site - Page 36 - ll. Réalisation d’une interface Web de partage des données Un dossier « inc » contenant les parties communes incluses dans l’ensemble des pages telles que le haut de page et la barre de menus, le bas de page, et les paramètres de connexion à la base de données ainsi que les requêtes SQL appelées par les requêtes Ajax Un dossier « pages » contenant l’ensemble des pages Internet proposées sur le site Internet Le dossier « public » regroupant selon leur type les scripts interprétés par le navigateur ainsi que les données chargées du côté client en 4 parties : Un dossier « css » contenant l’ensemble des fichiers gérant la mise en page, l’organisation graphique des éléments dans les pages Internet. Un dossier « javascript » contenant les scripts de calculs Un dossier « image » contenant à la fois les images utilisées pour la mise en page et celles constituant des informations relatives aux campagnes et aux plongées, notamment celles extraites des vidéos Un dossier « Data » contenant les données traitées disponibles en téléchargement Enfin, un fichier intitulé « index.php » gère l’ensemble de ces fichiers en incluant à chaque rafraîchissement les parties nécessaires à la page en cours de visualisation. Cette organisation m’a été suggérée par Laurent POUILLOUX, un des responsables du service informatique de l’IPGP. Elle est le résultat de l’expérience successive de plusieurs professionnels dans le domaine de la programmation web. Ainsi, le site Internet aura été réalisé dans les conditions réelles de développement d’un service de programmation Internet. Elle est résumée par la figure 9 ci-dessous : Figure 9 - Organisation physique des fichiers du site Internet - Page 37 - ll. Réalisation d’une interface Web de partage des données 2. Solutions techniques Le stage a été l’occasion de découvrir un grand nombre de solutions techniques nouvelles et de mettre en œuvre les connaissances acquises durant les trois années de formation du cycle ingénieur de l’ENSG. Les plus intéressantes seront décrites ici dans l’espoir de faire part de leur utilité aux futurs étudiants amenés à réaliser une application similaire et donc à être confrontés aux mêmes problématiques. Pour plus d’informations, ne pas hésiter à consulter la bibliographie qui détaille un grand nombre de sites Internet traitant de ces solutions techniques. Etant donné la durée de la phase de programmation, il était impossible de réaliser une étude technique complète de l’ensemble des solutions existantes pour la réalisation de ce site Internet. Les choix réalisés lors de la phase de réalisation sont donc le résultat d’un mélange des connaissances acquises auparavant et des solutions découvertes au fur et à mesure, notamment celles proposées par Laurent Pouilloux et Simon Gabolde que je remercie à cette occasion. Enfin, lorsque plusieurs solutions étaient disponibles pour des réalisations similaires, le choix s’est orienté en priorité vers des outils libres, opensource, non propriétaires et gratuits : OpenLayers a été privilégié à GoogleMaps, et jpgraph a été préféré à l’utilisation de la technologie flash par exemple. a) Langages de programmation i. Html et CSS Ces deux langages ont été utilisés pour la mise en page du site Internet et des différentes interfaces graphiques. Afin d’optimiser au mieux l’accessibilité du site dans le temps imparti, un effort a été porté sur l’ergonomie des interfaces et l’ébauche d’un design cohérent pour l’ensemble du site. Le langage Html a été utilisé pour définir l’organisation spatiale des éléments graphiques dans la page ; l’utilisation des éléments « DIV » de la typologie du W3C a été privilégiée par rapport à la construction d’éléments « table ». L’objectif premier étant la réalisation d’outils techniques fonctionnels, le design actuel du site est pour l’instant assez primaire. ii. Javascript Le langage Javascript a été utilisé pour réaliser l’ensemble des éléments dynamiques des pages du site Internet : la barre de défilement, le menu déroulant de choix d’une plongée ou les éléments de la zone de paramétrage (menus déroulants, cases à cocher, boutons radios…) par exemple. La technologie Ajax a été largement utilisée pour améliorer la navigation dans le site Internet, notamment la manipulation de la carte interactive. Cette technologie est en réalité un ensemble de fonctions Javascript décrites au paragraphe « II. C. 2. c) Prototype ». - Page 38 - ll. Réalisation d’une interface Web de partage des données iii. PH PHP P et SQL Le langage PHP a été utilisé pour faire appel à la base de données par le biais de requêtes SQL. Ces deux langages sont interprétés sur le serveur qui exécute des requêtes sur la base de données en conséquence. Le moteur PHP installé sur le serveur afin d’interpréter les scripts dans ce langage est un serveur de type Apache couplé aux fonctions spécifiques associées à PostGresSQL. Le langage SQL a été utilisé pour décrire les requêtes à effectuer sur la base de données PostGresSQL. Voici un exemple de requête effectuée sur la base : SELECT "id_img","chemin" FROM "image" WHERE "temps" <= 'temps_courant' + 30 AND “temps” >= ‘temps_courant’ -30 ORDER BY “temps” ASC LIMIT 1 b) Technologies Explorées i. OpenLayers Développé à l’origine par l’entreprise MetaCarta, OpenLayers est aujourd’hui un des projets de la fondation GeoSpatial Open Source (OSGeo). C’est un logiciel libre et gratuit implémenté sous la forme d’une bibliothèque javascript de cartographie dynamique sur Internet. Il offre de très nombreuses fonctions de visualisation, de manipulation et d’accès aux données géographiques dans les différents formats existants, notamment ceux préconisés par l’OGC tels que les protocoles WMS et WFS. OpenLayers a donc été utilisé comme client cartographique pour appeler et afficher les données décrites au paragraphe « II.A. Inventaire des données mises en lignes » : Les données raster visualisées dans OpenLayers grâce à des appels à des services WMS : Ceux mis en place grâce à GéoServer (Cf. paragraphe suivant) Celui proposé par le site Internet Marine GeoSciences Data System, la couche WMS connue sous le nom « Global Multi Resolution Topography ». Les données vectorielles stockées dans la base de données PostGreSQL var options = { displayProjection: new OpenLayers.Projection("EPSG:4326"), //Projection minScale:5000000, //échelle minimale maxScale:500, //échelle maximale controls:[new OpenLayers.Control.MouseDefaults()]}; map = new OpenLayers.Map('map',options); //Création d’1 carte OpenLayers //Appel de la couche WMS sur le server de Marine Geosciences var topo = new OpenLayers.Layer.MapServer( "MGDS Global Multi-Resolution Topography (GMRT)", "http://www.marine-geo.org/exe/mapserv?map_imagetype=jpeg&", {map: '/home/mgds/web/www.marine-geo.org/htdocs/services/ogc/wms.map', layers: 'topo'}); - Page 39 - ll. Réalisation d’une interface Web de partage des données //Appel d’une couche WMS sur le serveur GeoServer mis en place var bathy_momar = new OpenLayers.Layer.WMS( "Momar Bathymetry", "http://janus.ipgp.fr:8080/geoserver/wms", { width: '476', layers: 'topp:momar', styles: '', srs: 'EPSG:4326', height: '550', format: 'image/png' }, {singleTile: true, ratio: 1}); map.addLayers([bathy_momar, topo]); //Ajout des 2couches créées ci-dessus De plus, les outils proposés par OpenLayers utiles au projet informatique ont été ajoutés à la zone cartographique : Les outils classiques de zoom progressif et de déplacement par flèche directionnelle map.addControl(new OpenLayers.Control.PanZoomCustom()); Les outils de déplacement et de zoom manuel sur la carte var panel = new OpenLayers.Control.NavToolbar(); map.addControl(panel); Les outils d’échelles graphique et numérique map.addControl(new OpenLayers.Control.Scale('mapScale')); map.addControl(new OpenLayers.Control.ScaleLine()); L’outil de positionnement géographique du curseur de la souris map.addControl(new OpenLayers.Control.MousePosition( {div: document.getElementById('position'), numdigits:5})); L’outil d’historique de navigation var toolbar = new OpenLayers.Control.Panel( {div: document.getElementById("historic")}); map.addControl(toolbar); navHisto = new OpenLayers.Control.NavigationHistory(); map.addControl(navHisto); toolbar.addControls([navHisto.previous, navHisto.next]); Des outils de mesure de distance et de surface (améliorés par Marjorie Robert dans le cadre de son stage TFE) this.measure = new OpenLayers.Control.JMapMeasure(); map.addControl(this.measure); - Page 40 - ll. Réalisation d’une interface Web de partage des données L’ensemble de ces outils et de ces couches a été ajouté sur la carte ou à sa proximité pour former un ensemble cohérent de cartographie interactive : Figue 10 - Zone de cartographie intéractive du site dédié au projet MoMAR ii. GéoServer GéoServer est un logiciel libre développé en Java permettant le partage et l’édition de données géographiques sur Internet. C’est le projet de référence de l’OGC en termes de respect des normes et d’interopérabilité. L’utilisation de GéoServer est très agréable car l’ensemble du paramétrage des services Web se fait par le biais d’interfaces graphiques ludiques et relativement intuitives. De plus, des tutoriaux sont disponibles sur le site de GéoServer afin d’aider les nouveaux utilisateurs. On peut tout de même regretter l’opacité relative de ce système : tant que l’on est dans le cas classique d’utilisation de GéoServer, les manipulations à effectuer seront très clair et bien décrites dans les tutoriaux mais dès que les données ou l’utilisation désirée sortent un peu de l’ordinaire, il est difficile de déterminer d’où viennent les problèmes éventuels et quasiment impossibles de les résoudre. GéoServer a été utilisé en tant que serveur cartographique. Les données raster bathymétriques ont été stockées dans son espace de stockage des données et des services Web ont été paramétrés sous la forme de couches WMS. Ensuite, ces couches ont été appelées depuis OpenLayers comme décrit au paragraphe précédent. Une fiche technique présente en Annexe 3 décrit les étapes de mise en place d’un serveur cartographique avec GéoServer. - Page 41 - ll. Réalisation d’une interface Web de partage des données c) Bibliothèques supplémentaires i. Prototype Développée en Javascript, cette bibliothèque propose, entre autres choses, un ensemble de fonctions permettant la réalisation de requêtes Ajax adaptées à l’ensemble des navigateurs Internet. L’utilisation de requêtes Ajax est une des révolutions proposées par la deuxième génération du réseau Internet, le Web 2.0. Elle permet d’afficher dynamiquement des éléments variables sans recharger l’ensemble de la page en cours de visualisation, ce qui rend la navigation : Plus fluide, car l’appel d’une requête Ajax ne bloque pas l’exécution de la suite du script, Plus rapide, car le fait de modifier uniquement les éléments variables raccourcit le temps de chargement, Plus confortable, car, en ne rechargeant que des parties de la page, le navigateur n’a pas l’obligation de se repositionner en haut de page, ce qui est très agréable avec une page plus longue que la fenêtre dans laquelle on la visualise. La bibliothèque Prototype a donc été utilisée lorsqu’il fallait réaliser des appels fréquents à la base de données afin d’afficher des informations régulièrement actualisée, comme par exemple lors de l’immersion dans une plongée virtuelle. En voici un exemple de syntaxe : new Ajax.Request( 'index.php', { method: 'POST', //utilisation de la méthode POST evalJSON: 'force', //la réponse sera envoyée au format JSON parameters:{ //paramètres transmis par la requête Ajax id:id_com, ajax:activAjax, page:pageRequete, type:'commentaires_sql' }, onSuccess: Choix_Com, //fonction de callback en cas de succès onFailure: traiteErreur}); //fonction de callback en cas d’échec La bibliothèque propose également un panel d’interprétations des différents formats des réponses aux requêtes Ajax, comme par exemple, dans le cas d’une réponse au format JSON : var result = rep.responseJSON; - Page 42 - ll. Réalisation d’une interface Web de partage des données ii. Scriptaculous Scriptaculous est également un framework développé en Javascript. Il encapsule Prototype, ces deux bibliothèques sont donc totalement compatibles. Il propose un ensemble d’effets visuels adaptés aux éléments html, des outils permettant de déplacer les éléments de la page définis comme « déplaçables », ainsi que des contrôles Ajax par exemple. La bibliothèque a été utilisée à deux reprises : Pour la barre de défilement temporel dans l’interface de plongées virtuelles par la création d’un curseur « déplaçable » : new Draggable( 'curseur_tps', { constraint:'horizontal', handle:'curseur_tps' }); Figure 11 – Barre de défilement dans le temps Pour la création d’onglets à ouvrir et fermer dans la partie de paramétrage de la zone de cartographie interactive en ajoutant un effet visuel de glissement des corps des volets : new Effect.toggle(idDivSection,'blind'); Figure 12 – Menus déroulants de paramétrage de la zone cartographique - Page 43 - ll. Réalisation d’une interface Web de partage des données iii. FancyZoom Petite bibliothèque composée de seulement deux fichiers javascript, FancyZoom est un bon moyen de mettre en valeur les images affichées sur la page Internet. Utilisée comme un lien hypertexte, elle permet à l’utilisateur de voir chaque image concernée en taille réelle par un click sur cette image. Le mécanisme doit être activé au chargement de la page : <body id="body" onload="setupZoom();init_map();"> Puis chaque image concernée doit être implémentée ainsi: <a id="acam1" href="public/image/imgInit.jpg"> //image affichée par click <img id="cam1" src="public/image/imgInit.jpg" title="Image ROV Victor/> </a> Cette bibliothèque peut également être un bon outil d’optimisation. En effet, lorsqu’une page possède un grand nombre d’images, il est tout à fait possible d’afficher en taille réduite une image dégradée et donc plus légère et de faire apparaître l’image en résolution optimale lorsqu’on clique dessus. Cela accélèrera le chargement de la page en question. iv. JpGraph JpGraph est une bibliothèque de classes PHP permettant de générer des graphiques qui seront affichés aux formats image classiques (JPG, PNG…). Elle a été utilisée pour afficher les profils de navigation pour reconstituer les plongées. v. FPdf FPdf est une classe PHP qui permet d’exporter des fichiers au format PDF. Elle est exclusivement programmée en PHP et gère à la fois les éléments destinés à figurer dans le PDF et les entêtes définissant un PDF : $pdf=new FPDF('L','mm','A4'); $pdf->AddPage(); $pdf->SetTitle($dateheure); $pdf->SetLeftMargin(16); $pdf->SetTopMargin(8); $pdf->SetAutoPageBreak(false); $pdf->SetDisplayMode(75,'single'); Une fois le PDF ainsi créé, il ne reste plus qu’à ajouter les éléments et à définir leur graphisme et leur positionnement. //Numéro de la plongée $pdf->SetFont('Helvetica','B',48); $pdf->SetTextColor(0, 60, 140); $pdf->Cell(60,18,'Dive '.$numPl,0,0,'L'); FPdf a été utilisée pour la création de la fiche synthétique d’export du module vidéo de reconstitution des plongées (Cf. figure 7) - Page 44 - ll. Réalisation d’une interface Web de partage des données 3. a) Gestion de projet Processus de mise en ligne La description du processus de mise en ligne a été réalisée grâce au formalisme de la méthode d’analyse SADT. Chaque étape a donc été décomposée en une série de sous-étapes et chacune des sous-étapes a été décrite par sa « matière d’œuvre », sa « valeur ajoutée », ses « contraintes » et ses « moyens ». Figure 13 – Modèle SADT du processus de mise en ligne - Page 45 - ll. Réalisation d’une interface Web de partage des données b) Déroulement du stage Le déroulement du stage a inévitablement été marqué par les changements de calendrier de programmation des campagnes océanographiques d’Ifremer. La campagne BathyLuck09’ devait initialement avoir lieu durant le mois de juin. Cependant, le navire PourquoiPas a été réquisitionné par le BEA (Bureau d’Enquête et d’Analyse) pour mener les premières phases d’investigation sur l’accident du vol AF447 du 1er juin 2009 au large du Brésil. La campagne a donc été annulée, puis ajournée et enfin reportée au mois de Septembre. Le planning prévisionnel du stage a donc été modifié au fur et à mesure selon l’évolution de la programmation du calendrier du PourquoiPas. A l’origine, la campagne océanographique devait avoir lieu en début de stage puis, après l’enrichissement de la banque de données par les résultats de la campagne, une phase de développement du site Internet devait permettre la mise en ligne de la base de données. Les figures 14 et 15 suivantes présentent l’organisation initiale du stage sous la forme d’un diagramme de Pert et de Gantt. Figure 14 – Diagramme de GANTT initial Figure 15 – Diagramme de PERT initial - Page 46 - ll. Réalisation d’une interface Web de partage des données De retour en France après l’annulation de la campagne au début du mois de juin, un nouveau planning a été envisagé privilégiant le développement du site Internet dans l’incertitude de la programmation d’une nouvelle campagne avant la fin du stage. Les figures 16 et 17 présentent l’organisation intermédiaire envisagée à ce moment-là sous la forme d’un diagramme de Pert et de Gantt. Figure 16 – Diagramme de GANTT intermédiaire Figure 17 – Diagramme de PERT intermédiaire - Page 47 - ll. Réalisation d’une interface Web de partage des données La campagne Bathyluck09 a finalement été programmée au mois de Septembre et l’administration de l’ENSG a accepté de déplacer la soutenance finale du stage afin que je puisse y participer. La phase de programmation a donc duré trois mois comme prévu initialement. L’unique changement majeur est l’inversion dans le planning entre la phase d’acquisition de nouvelles données et la phase de développement informatique. Les figures 18 et 19 présentent le déroulement final et effectif du stage sous la forme d’un diagramme de Pert et de Gantt. Figure 18 – Diagramme de GANTT final Figure 19 – Diagramme de PERT final - Page 48 - ll. Réalisation d’une interface Web de partage des données c) Perspectives de développement La phase de développement du stage a donc duré environ trois mois. L’objectif principal était de développer un site fonctionnel répondant aux principaux besoins du projet MoMAR (Cf. paragraphe « II. B. 2. Inventaire des fonctions nécessaires »). Cet objectif a été largement atteint, le site Internet mis en ligne en atteste par lui-même. Cependant, certains aspects du site pourraient être améliorés et quelques fonctionnalités supplémentaires semblent utiles. La liste ci-dessous fait l’inventaire de tout cela : Ajout d’un export graphique de la zone de cartographie interactive sous forme d’une fiche synthétique (comme pour le module vidéo par exemple) Amélioration de la zone d’export du module cartographique : Choix du format Sélection des données sous plusieurs critères (facilement réalisable par des requêtes sur la base de données PostGres mise en place) Localisation de la position courante dans le graphique de navigation du module de plongée virtuelle Ajout de la navigation dans la fiche synthétique du module vidéo Ajout d’une plateforme de dépose des données après une campagne par un utilisateur plus ou moins expert en géomatique et/ou en développement Web Amélioration de l’affichage des données sur la cartographie interactive, notamment les données linéaires représentant les profils de navigation Amélioration du Design général du site Ajout d’interfaces d’aide ou de description des opérations ou des instruments pour rendre le site plus ludique et accessible au grand public - Page 49 - lll. Bathyluck’09 III. BathyLuck09’ A. Navigation des engins submersibles Trois engins submersibles étaient embarqués à bord du Pourquoi Pas lors de la campagne BathyLuck’09 : un ROV (Victor 6000), un AUV (AsterX) et un HOV (Nautile). Ces différents engins sous-marins sont décrits en Annexe 1. Durant la campagne, onze plongées ont été réalisées avec Victor et neuf avec AsterX. 1. Logiciels et Formation L’ensemble des opérations de préparation et de traitement des données de plongées ont été réalisées dans un environnement ArcGIS, grâce à un logiciel délivré par Ifremer nommé Adélie et contenant : plusieurs modules d’import des données spécifiques aux différents engins submersibles mis à disposition par Ifremer Figure 20 - Interface d’import des données issues du Victor 6000et du Nautile, Ifremer une extension d’ArcMap, visualisable sous la forme d’une barre d’outils dédiés au traitement des plongées sous-marines un module vidéo permettant de visualiser les vidéos des plongées simultanément aux trajectoires sous ArcMap. Figure 21 - Interface du logiciel Alamer, Ifremer Une formation a été organisée au centre Ifremer de Brest par Olivier SOUBIGOU sur le fonctionnement et les liens qui relient ces logiciels. Durant cette formation, Marie-Claire FABRI est également intervenue pour présenter un autre logiciel, Alamer, qui a été utilisé lors de la campagne pour réaliser des rapports de plongées (Cf. paragraphe « III.B.2. Rapport de plongée ») et qui est directement lié à l’ensemble des modules du logiciel Adélie. - Page 50 - lll. Bathyluck’09 2. Préparation des plongées Lors de campagnes océanographiques pluridisciplinaires telles que BathyLuck’09, deux types de plongées sont réalisées afin de répondre aux différents besoins de l’ensemble des scientifiques participant aux recherches : Des plongées de prélèvement où les objectifs sont regroupés autour de sites d’études connus et relativement bien localisés : il s’agit alors de déposer ou récupérer des instruments scientifiques (capteurs de température, capteurs de pression, colonisateurs microbiologiques…), de prélever des échantillons (fluide hydrothermal, faune, roches…) et de réaliser des mesures ponctuelles de température ou de vitesse de fluide par des captures vidéo. Des plongées de cartographie du fond océanique : il s’agit alors de parcourir une surface optimale afin d’acquérir des données bathymétriques, magnétiques et parfois des images qui permettront d’étudier les structures géophysiques de la zone couverte. a) Élaboration des trajectoires des plongées Durant la campagne Bathyluck09, toutes les plongées en mode prélèvement ont été effectuées avec le ROV Victor6000 et les plongées de cartographie ont été réalisées à la fois par le ROV Victor6000 pour 5 plongées et par AsterX pour l’ensemble de ces 9 plongées. La préparation de chaque plongée doit donc être adaptée aux opérations qui seront effectuées au fond et à l’engin submersible : Pour les plongées en mode prélèvement, un programme est établi par le chef de mission en tenant des objectifs scientifiques de la plongée. Ensuite, une liste des sites à visiter est réalisée par l’opératrice SIG et donnée à la fois à l’équipe en charge de conduire l’engin et à l’équipage en charge de la navigation du PourquoiPas et donc de suivre le ROV durant les opérations au fond. Pour les plongées de cartographie, une trajectoire est prévue en fonction des caractéristiques de l’engin submersible et de la durée prévue pour la plongée. Le type d’engin détermine l’altitude au dessus du fond de la mer et l’écartement des profils. L’élaboration de ce type de trajectoire est délicate car il faut trouver un compromis entre l’emprise de la zone à couvrir et les objectifs scientifiques. Le tableau ci-dessous détaille les caractéristiques des plongées de cartographie effectuées durant la campagne Bathyluck09 : Numéro de plongée Engin submersible Altitude Ecartement des profils Objectif scientifique 390, 391 Victor6000 8m 15 m Couverture OTUS 393, 394, 396 Victor6000 50 m 120 m Couverture bathymétrique De 1 à 9 AsterX 70 m 200 m Couverture bathymétrique - Page 51 - lll. Bathyluck’09 b) Cartographie de travail Pour chacune des plongées de cartographie, une carte a été réalisée afin d’aider les scientifiques en quart à suivre le déroulement des opérations et à noter les heures des moments clés de la plongée (chaque virage, les éventuels repositionnements effectués grâce aux différents systèmes de positionnement acoustique par l’équipe en charge de la navigation de l’engin, les problèmes techniques tels que les procédures d’évitement d’AsterX ou les pertes de signal acoustique…). La figure 22 présente un exemple de carte de travail : Figure 22 - Carte de préparation d’une plongée MMR réalisée avec Victor6000 c) Lien avec l’équipe de pilotage des engins Comme expliqué précédemment, pour les plongées de prélèvement, seule une liste de points géoréférencés est fournie aux pilotes. En ce qui concerne les plongées de cartographie réalisées avec Victor6000, la trajectoire est élaborée par l’opérateur SIG sous ArcMap grâce à l’extension Adélie et en collaboration avec le chef de mission. Une fois la trajectoire validée par l’ensemble des contraintes (durée, engin utilisé et objectif scientifique), elle est exportée au format Vemo+ grâce à l’extension Adélie afin d’être transmise à l’équipe de pilotage dans un format lisible par le logiciel de gestion des plongées qu’ils utilisent pour conduire l’engin. - Page 52 - lll. Bathyluck’09 Quant aux plongées effectuées avec AsterX, une zone d’étude est définie par l’opérateur SIG en collaboration avec le chef de mission grâce aux données présentes dans la base de données ArcGIS. Puis la trajectoire est définie par l’équipe de pilotage sur un logiciel spécifique de gestion des plongées AUV appelé Mimosa qui permet de programmer l’ensemble des ordres qui seront transmis à l’engin avant la mise à l’eau : description de la descente en cercle afin de réduire la dérive induite par les courants et non compensée tant que le capteur d’altitude est trop loin pour détecter le fond, description de la sortie du cercle de descente, des points d’intérêt à atteindre dans un ordre précis qui décrivent la trajectoire utile, … 3. a) Données et Traitements Données brutes Les données enregistrées par les différents engins sont transmises par l’équipe de pilotage à la fin de chaque plongée. Elles rassemblent les enregistrements des différents systèmes de navigation ainsi que des capteurs présents par défaut sur les engins. Les données du ROV sont transmises par l’équipe de pilotage sous la forme d’un CD ou d’un DVD selon la durée de la plongée. Ces données sont difficilement lisibles car elles sont livrées dans différents formats, notamment le format NMEA qui concerne les données de navigation. C’est pourquoi, elles seront importées par le module Adélie Import des données du Victor6000. Durant cette étape, les données sont regroupées par thématique et sous forme de fichiers dbf lisibles par ArcMap. Aucun module d’import n’est prévu pour l’instant pour les données de l’AUV. Ainsi, une petite démonstration s’est imposée de la part du responsable AUV afin de déterminer la signification et l’emplacement des données utiles dans le dossier contenant les données brutes et non triées. Ensuite, une fois les données de navigation repérées, un formatage a été réalisé afin de pouvoir les importer sous ArcMap pour les nettoyer grâce au module Adélie SIG. Tous ces éléments sont plus détaillés dans la partie dédiée à la navigation du rapport de campagne qui se trouve en Annexe 5. b) Reconstitution de la navigation réelle La reconstitution de la navigation est essentielle à la localisation des opérations scientifiques effectuées lors des plongées de prélèvements ainsi qu’au géoréférencement et au traitement des données bathymétriques. Le traitement des données de navigation est identique pour les deux engins utilisés lors de la campagne Bathyluck09, la seule différence provient des données utilisées. - Page 53 - lll. Bathyluck’09 Pour le Victor6000, ce sont les données de la BUC (Base Ultra Courte, système de positionnement acoustique du ROV par rapport au bateau) qui ont été exploitées au regard des données de la navigation estimée par la centrale inertielle du ROV à partir de la plongée 392. Avant cette plongée, le signal acoustique du bateau était trop bruité pour être exploité à cause d’un mauvais réglage de la fréquence d’émission. La navigation estimée étant par conséquent l’unique source de données exploitables, c’est elle qui a été utilisée pour reconstituer la navigation du ROV. Ce traitement a été effectué en dernier recours car la centrale inertielle du ROV intègre très mal la dérive due aux courants sous-marins, la navigation estimée est assez précise localement mais un biais est régulièrement introduit et accumulé au fur et à mesure entre chaque recalage du positionnement de la centrale inertielle par rapport à un nuage de points du signal acoustique de la BUC. Les figures 23, 24, 25 et 26 attestent de l’inexploitabilité des données avant la plongée 392 pour les deux types de plongée. La figure 27 présente un exemple de signal acoustique propre et exploitable pour reconstituer la navigation réelle de l’engin durant une plongée de cartographie. Figure 23 - Signal acoustique inexploitable durant une plongée de prélèvement Figure 24 - Signal acoustique inexploitable, Zone d’étude Figure 25 - Signal acoustique inexploitable sur une plongée de cartographie Figure 26 - Signal acoustique inexploitable, Zone d’étude - Page 54 - lll. Bathyluck’09 Figure 27 - Signal acoustique exploitable durant une plongée de cartographie Le principal traitement effectué pour reconstituer la navigation réelle est le filtrage des points aberrants. Pour effectuer ce traitement, des outils sont proposés par Adélie SIG afin de sélectionner les points selon trois critères : Le temps : les points en dehors d’une plage horaire sont alors sélectionnés afin d’éliminer les points enregistrés lors de la descente et de la remontée La vitesse maximale de l’engin : les points ayant nécessité un déplacement trop rapide sont alors éliminés mais ce traitement est à utiliser avec parcimonie car, sur l’exemple de la figure ci-dessus, il éliminerait certes les points aberrants beaucoup trop loin de la trajectoire réelle mais également les points suivants. La profondeur : les points visiblement trop profonds par rapport aux données bathymétriques sont éliminés. Figure 28 – Outils de filtrage proposés par Adélie SIG - Page 55 - lll. Bathyluck’09 Un filtrage manuel complète ensuite ces trois méthodes de filtrage automatique avant de reconstituer une trajectoire par une couche de linéaire à partir des points conservés grâce à un outil proposé lui aussi par Adélie SIG. La dernière méthode consiste à lisser la trajectoire obtenue. Pour ce faire, deux méthodes sont proposées par Adélie SIG : La moyenne glissante qui peut être effectuée avec entre 1 et 9 plus proches voisins. La gaussienne qui utilise elle aussi entre 1 et 9 plus proches voisins mais les pondère par la distance spatiale. Figure 29 – Outils de lissage proposés par Adélie SIG La méthode gaussienne a été privilégiée pour l’ensemble des traitements. Cependant, un nombre plus ou moins important de plus proches voisins a été utilisé selon l’engin : Pour les trajectoires du Victor6000, 9 points ont été considérés lors du lissage afin d’obtenir une trajectoire la plus lisse et réaliste possible. Pour les trajectoires d’AsterX, les données acoustiques de la GAPS étant beaucoup plus précises et propres que celle de la BUC du Victor6000, un lissage fort n’est pas nécessaire ; les trois plus proches voisins seulement ont été pris en compte. De plus, la descente et la remontée d’AsterX est effectuée en cercle pour des raisons techniques mais l’hélice formée à cette occasion est utile pour le calibrage du magnétomètre, il serait donc dommage de l’altérer par un lissage trop important. Figure 30 – Trajectoire de l’AUV lors d’une descente ; Sans lissage en haut, Après lissage en bas avec 3 points en vert et 9 points en violet - Page 56 - lll. Bathyluck’09 c) Données finales La trajectoire finale ainsi obtenue est au format ESRI sous forme de linéaires. Ce format est lisible par la plupart des SIG libres et Cependant, les chercheurs en géosciences marines ne sont pas ces logiciels. Aussi, chaque trajectoire a été exportée en format afin de pouvoir être lue par les personnes intéressées. d’un Shapefile du commerce. coutumiers de Excel et texte D’autre part, chaque trajectoire de plongée de cartographie a été l’objet d’un formatage spécifique afin d’être lisible par le logiciel Caraïbe de traitement des données bathymétriques qui était disponible sur le PourquoiPas. Ce formatage est un peu plus élaboré car il intègre des caractères de fin de ligne et de fin de document spécifique aux documents texte au format Unix. Il a donc été finalisé sous Mac par l’équipe de traitement des données bathymétriques. Toutes les plongées ont également fait l’objet d’une cartographie de synthèse. L’ensemble de ces cartes se trouve dans la partie Navigation du rapport de campagne et donc en Annexe 5 de ce rapport. La figure 31 présente la cartographie de synthèse des plongées dédiées à la prise de vue OTUS aux données bathymétriques. La figure 32 présente une carte regroupant les plongées de prélèvement. Figure 31 – Synthèse des plongées de cartographie - Page 57 - lll. Bathyluck’09 Figure 32 – Synthèse des plongées de cartographie B. Opératrice SIG Les membres de l’équipe scientifique des campagnes océaniques ne sont généralement pas familiers avec les logiciels de SIG. Ils manipulent bien entendu des données géoréférencées mais utilisent des logiciels adaptés au géosciences marines tel que GéomapApp édité par Marine GéoScience Data System et qui permettent surtout d’afficher les données et de les cataloguer. Cependant, toutes ces données ne sont pas toujours dans les mêmes systèmes de coordonnées ou parfois dans des formats hétérogènes ne permettant pas de les visualiser simultanément et d’effectuer des recoupements. Le rôle de l’opérateur SIG durant une campagne océanographique est donc de gérer la navigation des engins sous-marins comme il a été décrit au paragraphe précédent mais également de rassembler toutes les données géographiques concernant les opérations effectuées et de les regrouper de manière cohérente afin de pouvoir les manipuler pour répondre aux différents besoins des scientifiques. Ce travail ne pourrait de toute façon pas être réalisé par les autres scientifiques qui sont déjà bien occupés par leurs propres manipulations durant des campagnes où chaque instant est optimisé en terme de résultats scientifiques. - Page 58 - lll. Bathyluck’09 1. Cartographie exploratoire et Aide à la décision De nombreuses cartes ont été réalisées en tant qu’outil d’aide à la décision pour deux raisons différentes : Pour les opérations prévues préalablement par le programme scientifique, des cartes d’inventaires étaient nécessaires au repérage des instruments à récupérer par exemple ou à la programmation des plongées de prélèvement afin d’optimiser les temps de transit en analysant les positions relatives des différents sites hydrothermaux. D’autres opérations n’étaient géographique précise prédéfinie pas contraintes par une position Les CDT (condutivity, depth, temperature), mesures ponctuelles et exploratoires, qui sont effectuées dans le but de détecter d’éventuelles anomalies dans la colonne d’eau qui seraient le signe de la présence d’un site hydrothermal inconnu. Il est donc important de connaître les lieux déjà échantillonnés par le passé afin d’augmenter les chances de découverte scientifique. Figure 33 – Exploration par CTD Les dragues permettent d’échantillonner le plancher océanique afin de mieux comprendre sa structure géophysique. Cette étude est menée à l’échelle du segment LuckyStrike depuis plusieurs années ; il est donc nécessaire de connaître les dragues déjà effectuées afin d’enrichir les connaissances en pétrologie. - Page 59 - lll. Bathyluck’09 2. a) Synthèse des opérations Rapports Alamer La rédaction de rapports de plongée se fait après chaque plongée de prélèvement grâce au logiciel Alamer édité par Ifremer. Ce dispositif n’est pas nécessaire pour les plongées de cartographie qui ne présentent pas d’évènements particuliers. Les responsables des opérations effectuées sélectionnent des images clés représentatives des moments forts de la plongée et les commentent pour établir un rapport détaillé. Ils doivent également indiquer la localité de chaque opération. Figure 34 – Interfaces de sélection des images et de rédaction du rapport Le rôle de l’opérateur SIG dans la rédaction de ces rapports est de: Veiller au bon déroulement de la rédaction du rapport en expliquant le fonctionnement du logiciel Générer les coordonnées des opérations en synchronisant le rapport et les données de navigation finales Repérer les évènements de prélèvement, mesure, pose ou récupération d’instrument et remplir les fiches descriptives de ces opérations Vérifier la cohérence globale du rapport Exporter les rapports aux différents formats (html, csv, Shapefile) La rédaction de ces rapports est capitale pour conserver une trace précise des évènements des plongées. Elle constitue la mémoire de chaque campagne océanographique. Ce sont ces informations qui seront présentes dans le rapport de campagne et qui ont été utilisées lors de la réalisation du module vidéo du site Internet afin de permettre une navigation temporelle fluide dans la reconstitution des plongées. De plus, l’utilisation du logiciel Alamer implique l’intégration de ces rapports dans la base de données Biocéan regroupant l’ensemble des campagnes scientifiques effectuées sur des navires d’Ifremer. - Page 60 - lll. Bathyluck’09 b) Cartographie de synthèse Parallèlement à ce travail de compilation des opérations, un rapport de campagne a été rédigé par l’ensemble de l’équipe scientifique, détaillant toutes les thématiques abordées, leurs enjeux et leur méthodologie. Une partie de ce rapport se trouve en Annexe 5, elle détaille les plongées effectuées avec Victor6000 et AsterX. Plusieurs autres cartes ont également été réalisée spécialement pour le rapport de campagne afin d’avoir une vision dans l’espace des opérations réalisées. Les figures 35, 36 et 37 présentent des exemples de cartographies de synthèse inclues dans le rapport de campagne. Figure 35 – Répartition de l’instrumentation sismique et de pression - Page 61 - lll. Bathyluck’09 Figure 36 – Echantillonnage de roches pour l’étude volcanologique - Page 62 - lll. Bathyluck’09 Figure 37 – Répartition des capteurs de température sur le site hydrothermal MontSégur - Page 63 - lll. Bathyluck’09 C. Gestion des données La gestion des données est une des phases les plus importantes de tout projet scientifique et pluridisciplinaire. C’est un enjeu stratégique de la valorisation des opérations réalisées et des résultats obtenus. Dans ce sens, il semble déterminant d’impliquer dans la pérennité des données acquises dans le temps et d’adopter une démarche cohérente d’archivage des données permettant une consultation optimisée. 1. Politique de sauvegarde La politique de sauvegarde mise en place vise à réaliser une sauvegarde efficace et sécurisée. On entend par efficace, une sauvegarde qui permettra la diffusion et la consultation des données par les personnes concernées et par sécurisée une sauvegarde comprenant un nombre suffisant de copies des données pour assurer leur pérennité dans le temps en tenant compte notamment des risques liés au rapatriement par avion. Plusieurs paramètres sont donc à prendre en compte : La quantité des données en terme d’espace mémoire Le contenu des données La nature des données (brutes, traitées ou en cours de traitement) La destination des données (pour l’exploitation scientifique ainsi que pour le stockage des copies) A titre indicatif, le tableau résume les volumes de données des différents lots de données. Données Volume associé Vidéos de Victor6000 ≈ 2 Tb (au format DVD et compressé en mp4) Données bathymétriques en cours de traitement Données brutes Victor6000 et AsterX (Navigation, Capteurs, Bathymétrie, OTUS) 600 Gb 1Tb Données thématiques (Magnétisme, MapR, Pression, Navigation, Biologie, Chimie, GIS, Rapport de campagne) Données sismiques des OBS (Brutes et converties au format .sac) - Page 64 - 100 Gb 150 Gb lll. Bathyluck’09 Plusieurs stratégies ont été adaptées selon la sensibilité des lots de données : Les lots les plus sensibles et les plus volumineux (données vidéo, bathymétriques et brutes du Victor et d’AsterX) ont été sauvegardés en trois copies identiques. L’une des copies est restée à bord du PourquoiPas pour assurer sa sécurité physique durant le trajet de retour, le chef de mission a conservé une copie et la troisième copie a été confiée aux personnes en charge du post-traitement des données (le responsable des données vidéo et images d’une part et le responsable des données bathymétrique d’autre part). Les données thématiques étant issues et sauvegardées par les scientifiques spécialisés dans les différents thèmes, deux copies seulement ont été réalisées ; l’une est restée à bord du PourquoiPas et l’autre a été rapatriée par le chef de mission. Les données sismiques ont été rapatriées et sauvegardées par l’équipe en charge des instruments de mesures et de l’exploitation de ces mesures qui a quitté le PourquoiPas à la fin du premier leg (le 10 septembre). Cette politique de sauvegarde des données combine à la fois des modes de transports différents et séparés dans le temps pour le rapatriement, et des stockages géographiquement éloignés. De plus, une version complète est conservée par le chef de mission afin de permettre une exploitation pluridisciplinaire des données dans le futur. Enfin, les personnes en charge du post-traitement sont d’ores et déjà en possession d’un lot complet de données brutes ou en cours de traitement sur le thème qui leur est spécifique. 2. Intégration des données Comme on l’a vu au paragraphe précédent (« B. Opératrice SIG »), la présence d’un opérateur SIG est déterminante lors d’une campagne océanographique pour assurer au mieux l’harmonisation et l’interopérabilité des données acquises et produites. Ce processus s’inscrit dans la tendance actuelle de standardisation et de valorisation des données par l’établissement de métadonnées par exemple. Dans ce sens, la banque de données mise en place par Jérémy Renard constitue un premier pas dans la constitution d’un jeu de données cohérent qui a été enrichi au long de cette campagne. i. Base de données administrateur La base de données administrateur est une espace de stockage des données brutes acquises durant la campagne. De par sa conception, toute personne doit pouvoir l’enrichir, au delà de toute considération des compétences en géomatique. C’est en réalité plus une architecture de dossiers d’archivage classique permettant au chef de mission de stocker les données brutes en fonction de l’année de la campagne puis de la campagne et enfin de la thématique. - Page 65 - lll. Bathyluck’09 À chaque fin de mission, il importe donc que le chef de mission s’assure que toutes les informations nécessaires à la compréhension soient présentes dans la base de données peu importe le format utilisé. ii. Base de données données Utilisateur sous ArcGIS La gestion de la base de données Utilisateur sous ArcGIS nécessite quant à elle l’intervention d’une personne capable d’utiliser les logiciels de la gamme ArcGIS et ayant des connaissances solides en gestion de base de données géographiques. C’est le rôle de l’opérateur SIG : il lui faudra suivre le schéma conceptuel de données ainsi que la structure attributaire établis par Jérémy Renard, et harmoniser les données en termes de référence spatiale. Ainsi, les données seront toutes intégrées à la base ArcGIS au même format (Shapefile ou Raster selon la nature des données) et disponibles à la consultation sous ArcMap. iii. Base de données PostGresSQL La dernière étape consiste à peupler la base de données PostGresSQL avec les nouvelles données. C’est le dernier processus de la chaîne de mise à jour des données qui nécessite également de bonnes connaissances en géomatique et notamment la maîtrise du SGBDR PostGresSQL et de son extension spatiale PostGIS. Il faut pour cela exporter les données au format texte et les importer dans la base PostGresSQL grâce aux outils prévus pour cela dans le SGBDR. Lors de cette étape, il important de suivre à la lettre le schéma physique des données disponibles en Annexe 2. - Page 66 - Conclusion Conclusion Les Géosciences Marines sont aujourd’hui un défi scientifique d’une importance majeure, qui combine plusieurs domaines scientifiques : géophysique, géochimie, volcanisme, tectonique, sismicité, hydrothermalisme, biologie, microbiologie et la géomatique pour permettre d’exploiter et de partager les informations. En effet, les technologies employées pour l’exploration marine sont encore très récentes et les méthodes de positionnement pourraient être améliorées significativement. D’autre part, l’amélioration de l’acquisition de données sous-marines et surtout l’augmentation des volumes de données mis en jeu soulèvent les problématiques classiques de partage données (harmonisation, standardisation, établissement de métadonnées, consultation…). Ce stage a été l’occasion de mener l’étude à long terme du site hydrothermal LuckyStrike sous deux aspects différents : l’enrichissement de la base de connaissances existantes lors de la campagne océanographique BathyLuck09’ et la mise à disposition de données et de métadonnées harmonisées sur Internet. De nombreuses connaissances acquises au cours de la formation du cycle ingénieur de l’ENSG ont pu être directement appliquées dans le cadre d’un projet réel et complexe de part sa pluridisciplinarité. La participation à la campagne océanographique s’est révélée très enrichissante tant sur le plan scientifique et technologique qu’humain. lll. Bathyluck’09 - Page 68 - Bibliographie Bibliographie Rapports Imprimés ESCARTIN Javier. Rapport de la campagne MoMAR08. Paris, France. Avril 2009. 372 pages. Ce document synthétise l’ensemble des opérations scientifiques réalisées lors de la campagne MoMAR’08. Il m’a permis de me familiariser avec le déroulement d’une campagne en mer ainsi que de réaliser un inventaire détaillé des instruments à récupérer lors de la présente campagne BthyLuck’09. RENARD Jérémy. Rapport de projet de fin d’études ; Mise en place d’une banque de données SIG dans le cadre d’une étude pluridisciplinaire de la dorsale médioatlantique. Paris, France. 26 Septembre 2008. 128 pages. Ce rapport décrit les réalisations de Jérémy RENARD durant son stage de projet de fin d’études à l’ENSG qui s’est déroulé du 6 Mai au 25 Septembre 2008 à l’IPGP. Il m’a permis d’envisager les problématiques de mise en place de la base de données ArcGIS et les choix effectués en collaboration avec Javier ESCARTIN. De plus, ce document contient une description précise des missions de Jérémy RENARD lors de la campagne MoMAR’08 en tant qu’opérateur SIG. Il m’a donc donné une vision claire de mes responsabilités lors de la campagne de cette année. ESCARTIN Javier. Dossier de préparation de la campagne Bathyluck09. Paris, France. Ce dossier de préparation de campagne, rédigé à l’attention d’Ifremer, décrit les objectifs scientifiques de la campagne Bathyluck’09 ainsi qu’un planning prévisionnel, le personnel scientifique participant à la campagne et le matériel nécessaire aux opérations de mesures. Un rappel des consignes de sécurité y est fait. Ce document m’a bien entendu été très utile lors de la phase de préparation de la campagne afin de cartographier et prévoir le déroulement des opérations. Ifremer. Adélie: outils de post-traitement des données des engins sous-marins. Brest, France. Janvier 2009. 50 pages. Ifremer. Les logiciels Alamer v3.1, Outils de rédaction de Rapport de campagnes et de plongées. Brest, France. Janvier 2009. 45 pages. Ces deux manuels utilisateurs décrivent la marche à suivre pour utiliser les logiciels Adélie et Alamer édités par Ifremer. Ils m’ont été remis lors de ma formation à Brest et sont une ressource indispensable pour quiconque veut utiliser ces logiciels. - Page 69 - Bibliographie Direction des études de l’ENSG. Guide de stage TFE. Marnes-la-Vallée, France. Mars 2009. 8 pages. Ce guide m’a accompagné durant le stage afin de comprendre les objectifs du stage de 3ème année du cycle ingénieur de l’ENSG. Il précise les droits et les devoirs de l’élève ingénieur durant la dernière partie de sa formation. Sites Internet consultés Programmation et Webmapping Entraide informatique - www.commentcamarche.net/ - www.developpez.net/forums/ Entraide Géomatique - www.forumsig.org/ - georezo.net/forum/ Frameworks en JavaScript OpenLayers - www.openlayers.org - docs.openlayers.org/library/index.html - dev.openlayers.org/releases/OpenLayers-2.7/doc/apidocs/files/OpenLayersjs.html Scriptaculous - script.aculo.us/ - wiki.github.com/madrobby/scriptaculous Autres - www.leigeber.com/ - www.cabel.name/2008/02/fancyzoom-10.html Frameworks en PHP - enacit1.epfl.ch/php/jpgraph/docs/html/index.html - www.fpdf.org - Page 70 - Bibliographie Systèmes de Gestion de Bases de Données PostGreSQL - www.postgresql.org/ - www.postgresql.org/docs/8.3/interactive/index.html PostGIS - www.postgis.fr/ - www.postgis.fr/documentation/debian/postgis-1.1.2/html/index.html PHP - fr.php.net/manual/fr/ --> manuel PHP Géosciences Marines Le Projet MoMAR - www.momar.org WHOI – Woods Hole Oceanographic Institute - www.whoi.edu/ - 4dgeo.whoi.edu/jason/ MGDS – Marine GéoSciences Data System Base de données IPGP – ENSG, Jérémy RENARD. Base de données utilisateur du projet MoMAR, MoMAR-GIS. Aout 2008. - Page 71 - Annexes Annexes Annexe 1 - Engins submersibles 3. HOV : Human Occupied Vehicle Comme son nom l’indique, un HOV est un sous-marin permettant à des personnes de plonger à des profondeus importantes. Le Nautile d’Ifremer est un engin de ce type. Il permet à 3 personnes (le pilote, son co-pilote et un scientifique) d’effectuer des plongées de prélèvement d’environ huit heures sous l’eau. Il était présent à bord du PourquoiPas lors de la campagne Bathyluck09 mais n’a pas été utilisé afin de permettre à tous les scientifiques d’assister aux opérations. 4. ROV : Remote Operated Vehicle Victor6000 est un ROV. C’est un robot télécommandé par deux pilotes (un pour la trajectoire, un pour la manipulation des bras) depuis la surface. Il est relié au navire par un cable optique qui transmet des données et des images en temps réel. Il peut effectuer des plongées de prélèvement ou de cartographie selon les équipements qui sont installés lors de la mise à l’eau. Vitesse maximale au fond 1,5 noeuds Distance maximale parcourue en 1h 1,5 miles nautiques = 2778 mètres Autonomie Infinie (tant que le cable optique fonctionne) Système de positionnement BUC et navigation estimée 5. AUV : Autonomous Underwater Vehicules AsterX est un AUV. C’est un torpedo autonome dont la trajectoire est programmée avant chaque plongée. Elle est ensuite non modifiable. Il réalise des plongées de cartographie du fond et contient principalement un sondeur mutifaisceaux d’acquisition de données bathymétriques. Vitesse maximale au fond 3noeuds Distance maximale parcourue en 1h 3 miles nautiques = 5556 mètres Autonomie 9 heures Système de positionnement BUC, GAPS et navigation estimée - Page 72 - Annexes Annexe 2 - Modèle physique de données att_pl id_att cap gite assiette immersion altitude vitesse_x vitesse_y pan tilt cap_ccd ass_ccd zoom ouverture focus id_pl temps Integer Real Real Real Real Real Real Real Real Real Real Real Integer Integer Integer Integer Timestamp without time zone Integer campagne id_camp name date_deb date_fin chef annee id_vessel Integer Text Date Date Text Integer Integer dateheure droits_groups id_group id_page date droit groups id_group date_in nom gidnumber Integer Integer Date Character(8) Integer Date Character(32) Integer image id_image chemin cam dive heure src nom temps Integer Text Integer Integer Time without time zone Timestamp without time zone Text Text Integer instruments gid name cruise_pi pi date time latitude longitude depth cruise vessel recovery rec_cruise ship_lat ship_lon utmx utmy site type comments instrument the_geom Integer Character Character Character Character Character Numeric Numeric Numeric Character Character Character Character Numeric Numeric Numeric Numeric Character Character Character Character geometry pages id_page date_in libelle titre_page icone Integer Date Character(32) Character(64) Character(32) dateheure - Page 73 - varying(12) varying(12) varying(12) varying(12) varying(12) varying(12) varying(12) varying(12) varying(12) varying(30) varying(50) varying(100) varying(50) Annexes markers_benchmarks gid Integer objectid Integer name Character cruise_pi Character pi Character date Character time Character latitude Numeric longitude Numeric depth Numeric cruise Character vessel Character recovery Character rec_date Character rec_cruise Character dive Numeric type Character utmx Numeric utmy Numeric comments Character the_geom geometry report id_report dateheure localite latitude longitude prof cap dive commentaires temps varying(254) varying(12) varying(12) varying(15) varying(10) varying(20) varying(15) varying(20) varying(10) varying(20) varying(50) varying(100) Integer Timestamp without time zone Character(32) Text Text Integer Real Integer Text Integer vessel id_vessel name institute page_web Integer Text Text Text users id_user date_in login password name firstname Integer Date Character(32) Character(128) Character(50) Character(50) user_groups id_user id_group date_in Integer Integer Date vehicle id_vehicler name type institute Integer Text Text Text vent_sites gid name latitude longitude depth markers x_utm y_utm the_geom Integer Character varying(25) Numeric Numeric Numeric Character varying(50) Numeric Numeric Geometry navigation_tracks gid Integer cruise_pi Character varying(12) pi Character varying(12) date Character varying(254) time Character varying(254) latitude Numeric longitude Numeric depth Numeric dive Integer validitex Character varying(254) validitey Character varying(254) eqm integer phi Character varying(254) comments Character varying(100) Shape_leng Numeric g Character varying(254) utm_x Numeric utm_y Numeric id_pl Integer the_geom Geometry date_formatee Character varying(10) Timestamp without time dateheure zone temps Integer - Page 74 - Annexes plongee id_pl num_abs num_rel date_deb date_fin date_arr date_dep positionnement lat_min lat_max lon_min lon_max dx_aire dy_aire profondeur utm_nb utm_x0 utm_y0 hemisphere status commentaire id_camp responsable preliminary_navigation_file lat_moy lon_moy id_vehicle Integer Integer Integer Timestamp without Timestamp without Timestamp without Timestamp without Text Real Real Real Real Integer Integer Integer Integer Integer Integer Character (2) Text Text Integer Text Text Text Text Integer time time time time zone zone zone zone Deux tables ne sont pas décrites ici, les tables « geometry_columns » et « spatial_ref_sys ». Leur structure est donnée par PostGres lors de la création d’une base de données géographique. Elles définissent les types de géométrie et les références spatiales. - Page 75 - Annexes Annexe 3 - Fiche technique : Mise en place d’un serveur cartographique grâce au serveur GeoServer La méthode détaillée ci-dessous n’est pas unique. Cependant, elle fonctionne bien avec les outils disponibles au sein du laboratoire de GéoSciences Marines de l’IPGP. Elle sera donc utile en tant qu’outils d’administration du site Web mis en place. Donnée de départ : Le format standard d’échange des grilles bathymétriques est le format .grd. C’est donc de ce format que l’on va partir dans cette méthode. 1. Formatage des données pour GéoServer Plusieurs formats raster sont acceptés par GéoServer. Le format .tiff a été choisi pour cette méthode, il se décompose en trois fichiers : Un fichier au format .tiff qui contient une image (grille décrite par les trois canaux RVB de description de la couleur) ou une grille de données (valeur de la bathymétrie dans notre exemple). Une image sera affichée en couleur dont il faudra connaître la signification tandis qu’une grille de valeurs sera affichée en niveaux de gris. Ce fichier peut être généré par Matlab pour une image ou une grille de valeurs ou par le logiciel FlederMaus qui donnera une grille de valeur. Un fichier au format .tfw qui peut être généré avec MatLab et décrit l’emprise géographique ainsi que la résolution du fichier .tiff Un fichier au format .prj qui décrit le géoréférencement des fichiers précédent par le système de projection en autres. Le contenu de ce fichier est le même pour toutes les données rasters exprimées dans la même système de projection. Ainsi, si on ne sait pas comment le générer, il suffit de prendre un fichier d’une couche dans le même système de projection et de la renommer de façon adaptée. Dans le cadre du stage, toutes les couches sont géoréférencées en WGS84. Il ne sera donc pas difficile de trouver un fichier .prj pour s’en inpirer. Important : Les trois fichiers doivent porter le même nom et leur extension. Exemple : bathy_luckystrike.tif (ou bathy_luckystrike.tiff) bathy_luckystrike.tfw bathy_luckystrike.prj - Page 76 - Annexes 2. Stockage des données dans GéoServer Dans le dossier « data/sig/geoserver-1.7.4/data_dir/coverages » : Créer un dossier avec un nom clair. Par exemple pour notre cas d’école : bathy_luckystrike. Ajouter les 3 fichiers et c'est tout 3. Configuration du service WMS dans GéoServer Ouvrir l'interface geoserver « sig.ipgp.fr:8080/geoserver » Créer un CoverageStore en cliquant sur « New » dans l’espace « Config/Data/CoveragesStores » Dans le champ « Coverage Data Set Description »: laisser “A raster file accompanied by a spatial data file“ Dans le champ « Coverage Data Set ID » : mettre un nom clair Valider avec le bouton « New » La validation va vous diriger automatiquement vers l’étape suivante de création d’un Coverage. Créer un Coverage Si la redirection n’a pas eu lieu, aller à l'espace suivant : Config/Data/Coverages Cliquer sur « New » Dans le champ « Coverage Data Set ID » : choisir le CaverageStore que l'on vient de créer Dans la deuxième liste déroulante "Style, cliquer sur "raster" puis valider par le bouton ">>" ( "raster" apparaitra dans la liste de droite) Tenter de cliquer sur "Lookup SRS" Si la projection n'est pas reconnue, écrire dans le champ "SRS" : "EPSG:4326" (pour la projection WGS84, sinon adapter le code EPSG) Cliquer sur le bouton "Generate" pour chercher l'enveloppe du tiff Ajouter "EPSG:4326" dans les champs "Request CRSs" et "ResponseCRSs" Valider avec le bouton "Submit" Valider les configuration réalisées avec les boutons "APPLY" ET "SAVE" 4. Vérification Aller à l'espace suivant "Welcome/Demo/Map Preview" Une couche doit apparaitre avec le nom suivant "topp:nom_du_coverage" Visualiser l'exemple dans le visualisateur OpenLayers pour être sur Dans le dossier "data/sig/geoserver-1.7.4/data_dir/coverages", dossier "nom du CoverageStorage_nom du Coverage" a dû se créer Si ça n'a pas marché, autant tout recommencer ;) - Page 77 - un Annexes Tutoriel sur le site de Geoserver http://geoserver.org/display/GEOSDOC/User+Tutorial+Coverage Info sur les CoverageStores http://geoserver.org/display/GEOSDOC/5+CoverageStore+Configuration Info sur les Coverages http://geoserver.org/display/GEOSDOC/6+Coverage+Config Couches WMS en place bathy_regionale : regionale bathy_LS : LS40m bathy_Volcano : MOMAR08_5m_color bathy_momareto : LSmomareto - Page 78 - Annexes Annexe 4 : Carnet de bord Mardi 5 Mai 2009 Briefing avec Javier sur : La base de données, Les objectifs du stage Préparation de la campagne : Établissement de cartographie de travail Prévision d'itinéraires au préalable Mise à jour de la BD et WebMapping Les enjeux de la campagne Données à collectées / Véhicules utilisés Programme prévisionnel / Répartition du temps de travail Les concepts géophysiques de base Géomorphologie, Volcanisme, Sismicité, Hydrothermalisme Rencontre avec les autres membres du laboratoire Remplissage de la fiche d’accueil / Installation d'Internet Lecture du rapport TFE de Jérémy Renard Problème avec la licence ArcGIS => mail à Jérémy Renard Mercredi 6 Mai 2009 Essaies de résolution des problèmes de licences ArcGIS (Réinstallation du licence manager sans succès) Lecture de la fin du rapport TFE de Jérémy Renard Lecture du guide d'utilisation des logiciels d'Ifremer, Adélie et Alamer Adélie permet le traitement des données en sortie de campagne Possibilité de synchroniser les vidéos et le SIG avec Adélie Alamer permet d'établir des rapports de plongée et de campagne Jeudi 7 Mai 2009 Intégration de 4 points dans la BD (instruments Électromagnétiques) Étude de la BD mise en place par Jérémy Renard Structure / Différences entre la sauvegarde et la version en ligne Mail à ESRI support pour les problèmes de licence Briefing avec Javier Précisions sur les données Explications géophysiques Systèmes de navigation: BUC, LB, ACDP Logiciel d'intégration d'imagettes issues des films Installation de NotePad++ et de WinRar Page 79 - Lundi 11 Mai 2009 Intégration des données dans la base de données Administrateurs pour stockage de l'information Mail à ESRI précisant la configuration de l'installation et le problème à régler Installation de Avast antivirus Lecture du rapport de campagne de la campagne MoMAR08' Cartographie des éléments à récupérer durant la campagne de cet été Affichage des équipements non récupérés par une symbolisation ArcMap Confrontation avec le fichier récapitulatif en ligne et le rapport de campagne Chargement de données Victor dans Adélie sur l’ordinateur de M. Cannat Mardi 12 Mai 2009 Tentative de réparation d'ArcGIS avec le support technique de ESRI Installation de Adélie sur l'ordinateur fixe Problème de compatibilité avec ArcGIS9.2 Réflexion sur la partie webmapping du stage Préparation de l'entretient avec le service informatique de l'IPGP Chargement de données de plongée sur Adélie Lecture détaillée du manuel utilisateur du logiciel Adélie Discussion avec Javier sur les différences entre les différentes versions de BD Mercredi 13 Mai 2009 Réparation de Adélie SIG Rédaction d'une note concernant l'installation de Adélie avec ArcGIS9.2 Réparation de ArcGIS sur l'ordinateur portable destiné à la campagne Installation d'un nouvel antivirus sur l'ordinateur portable Nettoyage des disques durs sur l'ordinateur portable Réservation des billets de trains pour la formation à Brest Rédaction d'une demande d'ordre de mission pour la formation à Brest Jeudi 14 Mai 2009 Recherche des données de Revelle'08 utiles à notre campagne Création d'un fichier ShapeFile à partir des données avec les métadonnées préconisées par Jérémy pour conserver l'homogénéité de la BD Import des données de la campagne Revelle'08 dans la base de données administrateur et la base de données utilisateurs Étude technique WebMapping en prévision de l'entrevue avec le service informatique de l'IPGP Rédaction d'une demande d'émission d'ordre de mission Annexes Vendredi 15 Mai 2009 Mercredi 20 Mai 2009 Test sur Adélie: Import d'une plongée dans Adélie SIG Rédaction d'un mémo concernant la configuration du licence Manager ArcGIS Courte réunion avec le service informatique de l'IPGP Prévision d'une réunion la semaine prochaine avec une autre personne voulant faire du WebMapping Création du compte mail IPGP + Redirection vers le webmail de l'ENSG Conférence de Martin Sinha sur le « Reykjanes Ridge » Briefing avec Javier Formats des données issues des différents engins sous-marins 2 projets de mise en ligne: données sur Luckystrike et vidéos Étude technique des logiciels de webmapping en prévision de la prochaine réunion MapServer vs GeoServer PostGIS vs ShapeFiles Calcul approximatif de l'espace mémoire nécessaire à la mise en ligne Réunion pour la création du site Internet avec le service de tectonique Matériel nécessaire (ordinateurs, espace mémoire, logiciels) Choix d'un emplacement pour le serveur Stratégie et planning de développement Étude du code du le service tectonique / Réflexion sur les logiciels à installer Planification des premiers jours de la campagne avec Javier Définition des objectifs obligatoires et optionnels Rédaction d'une fiche prévisionnelle jour par jour Lundi 18 Mai 2009 WebMapping Mise en page générale de l'interface de visualisation des vidéos Programmation d'un curseur temporel en javascript Curseur déplaçable horizontalement seulement, replaçable en avant ou arrière Tableau présentant les informations principales Requêtes ajax/php/sql mais non testée car pas de serveur php installé Listing avec Javier des cartes à effectuer pour préparer la mission: À différente échelles 1 carte générale de la zone de fracture 1 carte avec LuckyStrike et la zone hors axe 1 carte avec seulement LuckyStrike Pour un même thème (échantillonnages) à différentes dates Listing avec Javier des éléments à faire figurer sur ces cartes Vendredi 22 Mai 2009 Intégration de plusieurs Incubateurs dans la base de données Cartographie des éléments à récupérer à l'échelle du segment LuckyStrike Tentative de tracés de plongées sur Adélie Étude des données contenues dans le disque dur Données de navigation Préparation de la campagne de l'année dernière Installation d'un server Web Installation physique dans la salle des machines de l'IPGP Installation de Linux sur la machine Installation des logiciels nécessaire à la phase de programmation Logiciel de prise du contrôle à distance d'un ordinateur Notepad++, barre d'aide au développement PostGres, PostGIS, Lamp, GeoServer Lundi 25 Mai 2009 Cartographie de préparation de la campagne 1 Carte générale du segment 2 Cartes du site LuckyStrike: les éléments à récupérer, les sites 4 Cartes détaillée du site LuckyStrike (Est, Ouest) Listing avec Javier des trajectoires à prévoir (Cf tableau récapitulatif) Prise en main de la fonctionnalité de tracé des trajectoires sur Adélie Mardi 26 Mai 2009 Mardi 19 Mai 2009 Réunion du laboratoire de GéoSciences Marines à Saint Maure Présentation des axes de recherches du laboratoire Déménagement de l'IPGP Bilan financier Page 80 - Réunion avec Mathilde Cannat, Javier Escartín et Adélie Delacour Stratégie de campagne: Priorité relative des différents objectifs Planning prévisionnel potentiel des plongées Tracé des trajectoires type pour l'AUV (1 par fichier ShapeFile + 1 Récapitulatif Excel + une carte) Préparation de fichiers simples visualisables sur GeoMapApp Problème de compatibilité avec les formats Raster non résolu Annexes Mercredi 27 Mai 2009 Lundi 8 Juin 2009 Entrevue avec Javier Amélioration géophysique des trajectoires prévues Explication des enjeux géophysiques du levé au sud du segment Correction des trajectoires Copie des données nécessaires à la formation au centre Ifremer Préparation du matériel informatique pour la formation Rédaction d'un compte rendu d'installation pour la fac Recherche de données test (CD de données brutes issues du submersible Victor) Remplissage d'une table de test dans la base de données PotGresSQL Début du code de visualisation des vidéos Adaptation des requêtes à la base de données créées Jeudi 28 Mai 2009 Formation au centre Ifremer de Brest avec Marie-Claire FABRI et Olivier SOUBIGOU sur les deux logiciels nécessaires à la gestion des plongées et de la navigation durant la campagne Vendredi 29 Mai 2009 Visite de Jérémy Renard Conseils pratiques avant le départ Installation de l'extension ET Geowizard pour ArcGIS Recherche de données relatives à la campagne en mer MoMAR08 Explication des derniers blocages techniques Préparation des fichiers AlaMer pour la campagne BathyLuck'09 Sauvegarde de toutes les données nécessaires à la campagne Mardi 9 Juin 2009 Mise en place de l'architecture du site avec Laurent POUILLOUX Structure des dossiers Connexion à la base de données Organisation de la page (parties constantes et variables) Création d'un projet SVN sur le site SVN de L'IPGP Installation d'éclipse d'un pluggin permettant la gestion de code en PHP Mercredi 10 Juin 2009 Départ pour les Açores Préparation pour la mission Annulation de la mission => Déception Installation et prise en main d'un nouveau navigateur Internet (Opéra) => Le site sera optimisé pour Mozilla Firefox et la compatibilité sera testée pour IE (version 7 et plus), Safari et Opéra Installation d''un pluggin permettant l'accès à un répertoire distant dans éclipse avec l'aide de Laurent POULLOUX Partage Samba à distance des dossiers Rapatriement du projet PHP dans Éclipse Programmation Amélioration graphique et ergonomique de la page Résolution de problème CSS Briefing ordre de mission avec Magalie Mercredi 3 Juin 2009 Jeudi 11 Juin Organisation du rapatriement de l'équipe scientifique Visite géologique du Volcan Do Caphelino sur l'île de Horta Analyse fonctionnelle : Listing des fonctions à réaliser Récupération des données numériques vidéo pour 1 plongée RDV avec le journaliste de Ushuaïa Création des menus de la page Internet Mardi 2 Juin 2009 Jeudi 4 Juin 2009 Retour en France Vendredi 12 Juin Vendredi 5 Juin 2009 Reformulation des objectifs de stage Nouveau planning Gantt + Diagramme de Pert Création de l'architecture de fichiers pour le site Internet Organisation générale du code Page 81 - Réalisation de cartes pour Javier Plongées réalisées en 2008, superposées au survey Otus Programmation Amélioration de la barre de défilement Annexes Lundi 15 Juin Barre des menus Actualisation du graphisme de l'onglet Actualisation du titre de la page dans les navigateurs Barre de défilement Résolution des problèmes de recalage du curseur Ajout d'une favicon (image personnalisée pour chaque page) Requête Ajax Recherche des informations à une date choisie Affichage des résultats de la requête Pb : Génération à partir du début des DVD -> Pas de synchronisation des 3 caméras Solution abandonnée : générer 1image toutes les secondes et en sélectionner 1 chaques 30 sec. Pb2 : Fichiers .dim générés incomplets : plusieurs colonnes restent vides Solution finale: Générer les vignettes (choix des format et pas) avec Mplayer et l’aide de Rafa Nettoyage du code + Ajout de commentaires Réalisation d'images pour les boutons de l'interface sous Illustrator Recherche sur la limitation de la dimension d'une fenêtre Internet Vendredi 19 Juin Mardi 16 Juin Correction des cartes Otus faites la semaines dernière (Système de projection!) Programmation Amélioration de la compatibilité des formats de date JS et PostgreSQL Boutons « Avance » et « Recule » commencés mais non fonctionnels Pb : la requête est lancée après le replacement du curseur donc celui-ci reste là où il est et les infos concernent la photos suivantes la plus proche donc l'heure ne coïncide pas... Création et remplissage d'une table contenant les plongées et les informations les concernant données par Adélie Mercredi 17 Juin Organisation graphique de la page (Élimination des restes de CSS dans le HTML + Positionnement en relatif) Exploitation de la table des plongées Liste déroulante contenant les plongées disponibles par une requête PHP Initialisation de la page de présentation des vidéos Jeudi 18 Juin Ouverture des images en taille réelle Installation et adaptation de la classe Javascript FancyZoom Briefing avec Laurent POUILLOUX Utilisation du SVN Génération de vignettes à partir d'une vidéo de Victor Plusieurs tentatives de pas 2min -> 1DVD = 2,5Mb 30sec -> 1DVD = 10Mb Page 82 - Réflexion avec Rafa sur la génération des vignettes avec MPlayer Intégration des images réalisée dans l'interface de visualisation des vidéos Activation / Désactivation des boutons selon si une plongée a été choisie ou pas Amélioration de l'initialisation de la page en fonction du choix d'une plongée Affichage en cas de réponse nulle lors d'une requête SQL Création d'un tableau adapté aux données à afficher Création de sous-menus pour l'onglet du projet MoMAR Tentative d'insertion d'une carte Google Maps avec un client OpenLayers Lundi 22 Juin Affichage d'une carte Google Maps avec un client OpenLayers Réglage du centrage, du zoom et du type de carte (satellite) Ajout d'un espace d'authentification et d'images pour changer la langue Traduction de la page d'accueil du projet MoMAR en français et espagnol Codage des liens dynamiques pour le changement de langue Test avec Javier sur MPlayer pour lancer les scripts et générer les vignettes Mardi 23 Juin Création avec Javier d'un script sur MatLab pour générer les vignettes Préparation d'un fichier d'initialisation des variables du script Création d'un table renseignant les campagnes dans la BD PostgreSQL Mercredi 24 Juin Recherche des paramètres d'initialisation pour les vidéos sans incrustations Préparations des fichiers d'initialisation pour MatLab Test du script pour la première image de chaque vidéo : vérification de l'heure de début des vidéos et du calcul des décalages temporels Annexes Jeudi 25 Juin Mercredi 1 Juillet Fin de la vérification des paramètres pour les DVD Tentatives de résolution des problèmes de décalage avec les vidéos au format .avi (mp4 ou wmv) Vérification de l'heure de début de tous les mp4 à la main Génération de mp4 plus compressés (1 keyframe par seconde) Adaptation des scripts de génération des vignettes Lancement du script général sur MatLab Import des fichiers Att dans la base de données PostgreSQL, enfin!! Étude de la librairie jgGraph : lecture de la doc et analyse des exemples Tentative de génération d'un graphique à partir des données de la BD Vendredi 26 Juin Fin du processus de génération des vignettes (6h... plus les deux plongées générées pendant la nuit) Réflexion sur l'insertion des données dans la base de données PostGreSQL Élaboration d'un script PHP adapté aux fichiers Att Recherche d'un module pour générer des graphiques en PHP ou en JS après PHP Tentative d'activation de PostGIS Lundi 29 Juin Séminaire de Jian Lin (WHOI) sur les dorsales lentes Création d'un fichier d'info sur les images : nom des images + date et heure Import des données Att et images Problème dans la requête SQL avec les '' et les ' Problèmes de format des données Découverte de la fonction d'import de fichier tabulés et csv Mardi 30 Juin Reformatage des données à importer pour qu'elles soient compatibles à l'outil d'import de PostgreSQL (Pb persistant sur les formats de dates) Réunion avec Joël BOULIER Avancée du stage MCD: améliorations et validation A faire: SADT décrivant les processus principaux pour la mise en ligne Installation avec Olivier SOUBIGOU d'une nouvelle version de Adélie vidéo ++ : Import de fichiers numériques, choix du format image en sortie -- : Pb de lecture, codecs manquants Intervention de Laurent POUILLOUX Activation du langage Plpgsql dans PostgreSQL Conversion de la base en géodatabase (ajout des tables spatiales) Installation d'une bibliothèque PHP pour les graphiques (jpGraph) Page 83 - Jeudi 2 Juillet Résolution des problèmes d'accès à la BD avec Laurent Pouilloux: Génération automatique des graphiques à partir de la BD Gestion des requêtes Ajax Début d'adaptation des requêtes SQL aux données récemment importées Vendredi 3 Juillet Problèmes avec les formats de dates SQL et JS : Fonction epoch de calcul du nombre de er secondes depuis le 1 janvier 70 à partir d'une date Sauvegarde des données par le SVN Mercredi 15 Juillet Résolution du problème concernant les formats de date avec E. Fritsch Réflexion sur l'organisation du rapport de stage Rédaction de la bibliographiede début de stage Génération des champs de temps pour les tables concernées Création de la table d'informations sur les images et Import des données Harmonisation des ShapeFiles Markers et BenchMark Jeudi 16 Juillet Import des vignettes dans l'espace de stockage réservé au site Internet Refonte des menus (encore... enfin!) Adaptation des requêtes SQL aux vraies tables de données Intégration du tableau d'affichage final + Affichage des informations Séparation des requêtes concernant les images selon la caméra Affichage des images au bon emplacement Vendredi 17 Juillet Correction des fonctions de lecture des images: Déplacement du curseur et Click dans la barre de défilement Replacement du curseur après la requête SQL Replacement et Actualisation du temps courant après la req. SQL Bouton d'avancement à la prochaine information ou image Création du graphique représentant l'altitude et l'immersion -> Pb: l'altitude ne correspond pas vraiment à ce qu'elle devrait ... Réflexion sur une décomposition SADT du processus de mise en ligne Annexes Lundi 20 Juillet Lundi 27 Juillet Briefing avec Javier Avancée du projet à ce journaliste Préparation de la nouvelle campagne Programmation restante Création d'un ShapeFile commun regroupant les Markers et les Benchmarks Tentatives d'import d'un ShapeFile dans la BD PostGIS -> Pb d'accès à la BD Récupération des commentaires des opérations dans les fichiers Adélie Création d'une boite de liste déroulante RDV avec Laurent Pouilloux Installation d'une liaison SSH sur l'ordinateur portable pour accéder à la BD et au site depuis l'extérieur de l'IPGP (et donc sur le bateau) Intégration d'un module d'authentification dans le site Création des tables nécessaires dans la BD (page, user, group, et les liaison entre ces tables) Aide sur la commande psql Présentation de la bibliothèque fpdf: génération automatique de documents au format Pdf Remplissage de la table page Appels à la table page pour afficher le titre et l'icône de la page Tentative d'intégration d'un lien d'export en pdf Mardi 21 Juillet Import des données des rapports AlaMer dans la BD PostGIS Ajout d'une liste déroulante de 5 lignes Affichage des commentaires dans la liste déroulante A faire: sélectionner les commentaires à afficher selon la plongée Mercredi 22 Juillet Ajout d'1 requête d'actualisation et de sélection des rapportss selon la plongée Mise en page du MCD Ajout d'un copyright Ifremer en dessous des images Création du footer ( liens vers une page de contact et de plan du site) Création d'une page de contact Réflexion sur l'organisation de la page de cartographie interactive Recherche sur Scriptaculous pour réaliser un menu en accordéon Jeudi 23 Juillet Remplissage et désactivation de la zone de commentaires sans plongée choisie Création et mise en page de la page présentant le plan du site Intégration du pied de page dans la page de visualisation des vidéos Organisation de la page de cartographie Ajout d'une série de menus en Accordéons dans la page de cartographie Utilisation de versions différentes de prototype et de Scriptaculous Vendredi 24 Juillet Résolution des conflits entre les différentes versions de framework présentes Ajout des zones de recherches géographiques Ajout de zones de sélection des campagne, année, participant et plongée Liaison entre les différents éléments Le choix d'une campagne sélectionne les plongées et active la liste Page 84 - Mardi 28 Juillet Liaison des menus de paramétrage de la cartographie interactive L'année suit la campagne On choisit une année ou une campagne Création d'un modèle de Pdf grâce à la bibliothèque fpdf Organisation graphique du Pdf Sélection des éléments composant la fiche synthétique Mercredi 29 Juillet Automatisation de la génération du Pdf Récupération des éléments affichés dans le navigateur Formatage des données à envoyer dans l'URL Appel des données reçues en GET pour la création du Pdf Ajout d'options supplémentaires dans la zone de paramétrage Affichage des lieux et marqueurs connus, des navigations, des Équipements et des Échantillons Liaison entre les différentes cases à cocher Cocher une catégorie, active et coche ses sous-catégories Import d'un ShapeFile dans la BD Postgres/PostGIS -> Pb: Création sous l'utilisateur postgres -> la table obtenue lui appartient, ce qui empêche sa visualisation dans phppgadmin 2 solutions envisagées mais qui n'ont pas résolues le Pb: Initialiser un mot de passe pour l'utilisateur postgres ne suffit pas pour se connecter avec cet utilisateur dans phppgadmin Impossible de changer le propriétaire d'une table appartenant à postgres si on est connecté dans phppgadmin sous un autre utilisateur Annexes Jeudi 30 Juillet Jeudi 6 Aout Point d'avancement avec Javier Explication de l'emplacement des fichiers et données créés Définition des critères de paramétrages nécessaires Accord sur les termes à afficher: l'anglais sera la langue de travail Définition des priorités d'avancement futures Intégration d'un système de déconnexion Abandon du polylinguisme Résolution du problème de lecture des tables protégées avec Laurent Pouilloux Autorisation pour toutes les personnes ayant un compte de se connecter dans phppgadmin -> On peut donc se connecter en utilisateur postgres dans phppgadmin et donner des droits de lecture à l'utilisateur sig Documentation sur OpenLayers (découverte d'un tutoriel clair) Recherches sur Scriptaculous et la gestion des menus Nouvelles tentatives d'import de la couche WMS de marine geosciences Ajout d'une couche de points représentant les markers Ajout d'une couche de points représentant les benchmarks Réflexion sur l'ajout d'un graticule (grille de référence géographique) Vendredi 7 Aout Rédaction du rapport Définitiion de la charte graphique, Réflexion sur les titres Mise en place des différentes parties (page de garde, sommaire…) Tentative de connexion à distance au site Internet (semi-réussite) Lundi 10 Aout Mise en place des menus comme convenu avec Javier Abandon de l'accordéon pour des menus déroulables Rédaction de commentaires dans le code Rédaction du rapport Paragraphe dédié au projet MoMAR Ajout de liens de téléchargement dans la partie d’export des données Travail sur la couche WMS de Marine GeoSciences Etude d’ajout de lignes Affichage des marqueurs et benchmarks directement par la case à cocher. Lundi 3 Aout Mardi 11 Aout Ajout de plusieurs type de fonds de cartes dans l'espace de visualisation cartographique : Les couches GoogleMaps Des couches WMS issue de Web services Travail sur les contrôles et autres outils à ajouter à la carte Ajout d'un zoom par une boîte Ajout de la main de navigation Ajout d'outils pour accéder aux zooms précédent et suivant Tentative d'insertion d'un outil de mesure Ajout des Vent Sites et des Instruments à la base de données PostGres Intégrations des différentes couches d’instruments à la carte OpenLayers (Vent, JPP, OBS, Temperature Sensors, Colonizator, EM, Currentmeter) Gestion de l’affichage par les cases à cocher de la zone de paramétrage. Nouvelles tentatives infructueuses d’ajout de la couche WMS de MGDS Rédaction du rapport de stage Présentation de l’IPGP et de l’équipe de GéoSciences Marines Mardi 4 Aout Implémentation des fonctions de zoom sur zone (trois zones pré-définies) et sur une emprise géographique Rassemblement des navigations dans un unique ShapeFile formaté Ajout des navigations à la BD PostGres Découverte et formatage de données sur les plongées de la campagne GraviLuck’06 Ajout de ces plongées à la BD Ajout (enfin !!) de la couche WMS de Marine GeoSciences qui est très lente Test sur les différents types de géométries proposées par PostGIS Rédaction du rapport de stage Bibliographie Vendredi 31 Juillet Ajout d'un outil de mesure (de distance ou de surface) = Echec Ajout de la couche WMS avec les données de marine geosciences = Echec Personnalisation des boutons déplacement, zoom et vue globale = Réussite Mercredi 5 Aout Intégration d'un script d'ajout d'outils de mesures de distance ou de surface Mise en page des outils Ajout de marqueurs aléatoires avec un style différent selon un attribut Page 85 - Mercredi 12 Aout Annexes Jeudi 13 Aout Lundi 24 Aout Ajout d’une navigation selon son numéro de plongée Ajout de grilles de graticules Réglages avec Javier des niveaux de zoom maximal et minimal Remplissage et Corrections dans la BD Postgre Date et vaisseau pour chaque campagne Création des tables des vaisseaux et des engins submersibles Ajout des clés étrangères, contraintes évoquées dans le MCD Ajout des bonnes couches WMS (avec les couleurs) Ajout du graphique des navigations dans le module de plongée Rendez-vous avec Laurent Pouilloux Correction du système d'authentification pour pouvoir utiliser le ldap de l'ipgp Explications supplémentaires pour l'accès à distance : passer par localhost Vendredi 14 Aout Rédaction du rapport Intégration du Carnet de bord Description des données et sources de données Intégration du modèle conceptuel de données et description Mardi 25 Aout Accès à distance au site Internet, enfin! Tentative d'ajout de la nav dans le pdf Rédaction du rapport de stage Frameworks javascript Mercredi 26 Aout Lundi 17 Aout Rédaction du rapport de stage (OpenLayers, Glossaire, GéoServer) Travail sur l’affichage des navigations Recherches sur l’export de la carte OpenLayers en format image (jpeg) Jeudi 27 Aout Réparation de l'affichage des instruments Tentative de gestion de la couche de base en fonction de l'échelle (ou du zoom) Nettoyage du code avant migration Gestion de l'affichage d'une partie d'export en fonction du groupe Début de migration du serveur web en libre accès Rédaction du rapport Mardi 18 Aout Affichage des navigations Gestion de cet affichage par véhicule et par plongée Recherches sur l’affichage d’info-bulles Mercredi 19 Aout Ajout des info-bulles sur les instruments scientifiques Ajout des informations de position dans le module Vidéo et le pdf généré Travail sur les labels et le graphique de navigation dans le module Vidéo Jeudi 20 Aout Vendredi 28 Aout Sauvegarde des données Préparation du matériel nécessaire pour la campagne Rédaction du rapport Mise en ligne du site Internet Remodelage de la gestion de l’affichage / effacement des instruments Mise en place d’export de fichiers stockés sur le serveur Tentative d’ajout d’exports de données de la base de données Samedi 29 et Dimanche 30 Aout Vendredi 21 Aout Lundi 31 Aout Ajout des exports liés à la base de données Ajout des données raster de bathymétrie Création des fichiers au format .tiff et de projection (.twf, .prj) Stockage des données dans GeoServer Mise en place des couches WMS Appel des couches WMS depuis le client OpenLayers Installation du matériel informatique Vérification des poste de travail (ArcGIS / Adélie) Installation du portable mac et du système de sauvegarde Configuration du PC portable et du mac (réseau, internet, mozilla) Réunion d’information Installation du fichier Alamer Remplissage des participants dans le rapport de campagne Alamer Page 86 - Transit aérien vers Horta Annexes Mardi 1 Septembre Lundi 7 Septembre Tentative de connexion à distance sur sig.ipgp.fr = Echec DEPART !!!!!! Correction fiche de Quart Exercice des combinaisons et Réunion sur la sécurité Calcul des coordonnées des évènements Explication à Thibault du logiciel Alamer pour la pl388 Extraction des données CTD des pl AUV 1 et 2 Mercredi 2 Septembre Cartographie du lac de lave Rapport Alamer (Explication du logiciel à Valérie et Julie, Identification des opérations pl388) Pb : certains capteurs de température ne se trouvent pas dans la BD Alamer Trombinoscope du bord Réunion sur les objectifs des plongées AUV prévues Cartographie des éléments à récupérer Calcul des points de relocalisation des OBS Fiche descriptive de la plongée 1 de Victor Compilation des points remarquables pour l’équipe ROV Décision du tracé de la plongée 1 AUV Cartographie de la zone de Menez Hom = Préparation des dragues Jeudi 3 Septembre Cartographie détaillée des éléments à récupérer sur TourEiffel et MontSégur Traitement pl386 (Import dans Adélie, Nettoyage de la navigation, Initialisation du rapport Alamer) Mise en place du processus de sauvegarde des vidéos Mardi 8 Septembre Mercredi 9 Septembre Traitement des pl AUV 1 et 2 Sélection et formatage des données Nettoyage de la navigation Export des résumés des pl 386 et 387 Recherches sur les capteurs de température (fiches + GIS) Jeudi 10 Septembre Préparation profils de la pl 390 en mode MMR et OTUS Traitement pl 389 (Import Adélie et Initialisation rapport Alamer) Vendredi 4 Septembre Vendredi 11 Septembre Cartographie de la plongée AUV 1 Traitement pl387 (Import Adélie, Nettoyage de la navigation, Initialisation du rapport Alamer) Installation capture vidéo pour export d’images (préparation pl Nautile) Cartographie des dragues et CTD potentielles Préparation profil Victor MMR et Cartographie de travail Import Adélie pl 390 Extraction des données de magnétisme dans pl1 AUV Prévision d’une CTD et cartographie de travail Carte du profil 4 AUV Samedi 5 Septembre Samedi 12 Septembre Explications à Javier du logiciel Alamer Préparation pl AUV (profil 2 perpendiculaire à l’axe) Rédaction du planning pour les 3 jours à venir Préparation du profil de recherche du site hydrothermal Ewan Cartographie préparatoire de la plongée Nettoyage pl 389 (début) Carte de présentation du site pour Benoît (JPP et OBS) Dimanche 6 Septembre Cours sur les données AUV avec Patrice Copies et conversions des DVD (pendant le quart de 00h à 4h) Opérations Victor dans le conteneur Explication à Cédric du logiciel Alamer Finalisation de la navigation de la pl388 Rédaction du planning pour les 3 jours à venir Page 87 - Dimanche 13 Septembre Résolution des problèmes de profils durant la plongée Traitement de la pl 389 (suite) Réunion : Discussion sur le rapport de campagne Fin traitement pl AUV 1 et 2 Récupération des évènements ROV pl 389 Annexes Lundi 14 Septembre Lundi 21 Septembre Récupération des évènements ROV pl 389 Confirmation position de JPP Est Validation des pl AUV avec Mathilde ->Export des données de Mag et des nav au format Caraïbe Tentative d’ajout d’une localité dans Alamer (mail à M.C. Fabri) Initialisation rapport Alamer pl390 Traitement des navigations des pl AUV08 et MMR 394 Fin des rapports Alamer pl 389 et 392, à relire Nouvel import des plongées MMR pour Julie avec 1sec d’échantillonnage Mardi 15 Septembre Réflexion sur les prochaines plongées MMR avec la carte de Javier Préparation des profils avec Mathilde Rédaction Cruise report (Début partie Navigation, Refonte trombinoscope) Carte Thibault/Eric : coordination de l’étude de la température et de la vitesse des fluides Mercredi 16 Septembre Ajout de nouvelles localités dans Alamer ère Tracé de la 1 plongée MMR 50m (perpendiculaire à l’axe) +Cartographie Mise à jour du trombinoscope Traitement de la navigation de la pl AUV6, Export au format caraïbe Import et traitement pl 392 (la BUC est meilleure !) Cartographie de synthèse pl AUV 1, 2, 4, 6 pour le cruise report Mardi 22 Septembre Relecture des rapports Alamer pour identification des opérations Préparation d’un survey AUV au sud de l’axe Mercredi 23 Septembre Fin de la relecture du rapport Alamer pl 389, 392 et 388 Fin traitement pl 393 et 394 et pl AUV07 Mise en place de sauvegarde des navigations finales sur le NAS Extraction des données CTD et Mag pl AUV07 Cartographie d’inventaire des pl effectuées Jeudi 24 Septembre Traitement de la pl 395 (Import Adélie, Initialisation rapport Alamer, Nettoyage de la navigation) Placement des capteurs de température sur les mosaïques Correction de la date dans la pl AUV08 Jeudi 17 Septembre Vendredi 25 Septembre Préparation de profils MMR50m et AUV Construction sur Mimosa Import des mosaïques dans ArcMap Relocalisation des capteurs de température sur les mosaïques Traitement de la pl 395 (à nouveau, fichiers non sauvegardés) Réunion sur la politique de sauvegarde des données Traitement pl AUV09 et exports au format caraïbe, excel Relecture totale et finalisation des rapports Alamer Vendredi 18 Septembre Samedi 26 Septembre Cartographie zoomée pour Benoît avec JPP Extraction des données CTD et Altitude de la pl AUV06 Calage des capteurs de température avec Thilbaut Samedi 19 Septembre Cartographie finale des plongées de l’AUV Traitement et sauvegarde des navigations des pl 395 ? 392 ? 388 ? 389 Prévision de profils supplémentaires pour la plongée MMR Prévision d’une série de CTD pour la fin de la campagne Import pl 396 et début de nettoyage de la navigation Préparation des profils MMR et AUV pour différents scénarios Calage des capteurs de température avec Thilbaut Dimanche 27 Septembre Dimanche 20 Septembre Cartographie finale des plongées du Victor Export des rapports Alamer et des données Mag et CTD manquantes Préparation boîte AUV avec Mathilde et Patrice Point avec Mathilde sur l’inventaire des données et le Cruise Report Lundi 28 Septembre Rédaction du Cruise Report Sauvegarde des Page 88 - données du NAS Annexes Annexe 5 – Cruise Report - Navigation Victor Navigation Positioning systems The Victor 6000 is a ROV (Remote Operated Vehicle). It is driven by the ROV team from the ship thanks to an optical cable. Two different positioning systems are available: the estimated navigation and the BUC. Estimated Navigation During the dives, the ROV Victor 6000 calculates its geographical position from its last position and the data given by an inertial sensor. This positioning system is very accurate locally but a drift can be introduced by submarine currents. BUC – Base Ultra Courte The BUC is an ultra short baseline acoustic positioning system. The ship sends out a sound wave and when the ROV receives this signal, it calculates its new position base on the travel-time of the acoustic wave. This positioning system is not affected by submarine currents so its absolute location is more accurate but there can be a large error locally. Two complementary systems The BUC is theoretically better than the estimated navigation. But sometimes, the transmition of the acoustic wave is blocked because of a bad choice of the frequency or too much noice from the boat. As a consequence, the Estimated Navigation is more stable than the BUC system so the ROV team uses it to drive the robot. But they need to relocate regularly the estimated navigation in order to reduce the drift. This relocalisation is indispensable for the dive in survey mode in order to respect the profiles and to reach dive’s cartographic objectives without holes in the original profiles. Data processing Raw Data For each dive, the Victor Team made a CD (or a DVD) containing all the data recorded by the ROV. This data includes the estimated navigation, the BUC data, an hybrid navigation, the images taken by the scientists during the dives, and informations about the camera during the shooting. The hybrid navigation is a combination of the BUC data and the estimated navigation. It has never been used for the processing of the navigation because of a lack of information about the methodology used to build it in the Ifremer documentation. At the beginning of the cruise (until the dive number 392 on the 15th of September), there was a technical problem in the transmition of the acoustic wave. So, the BUC data are unusable for the dives 386 to 392. For these dives, the estimated navigation was processed with regard to the BUC and the relocalisation done by the pilots. These dives were done in a sampling mode or with the OTUS acquisition which will allow recalculating later a better navigation during the generation of the mosaic. Page 89 - Annexes Comparaison of the BUC data before and after the dive 392 Bad BUC transmition in sampling mode Bad BUC transmition in survey mode Good BUC transmition: only a few points are aberrant Number Dive Positionning System used for the processing 386 - 1 Estimated Navigation 387 - 2 Estimated Navigation 388 - 3 Estimated Navigation 389 - 4 Estimated Navigation 390 – 5 Estimated Navigation 391 - 6 Estimated Navigation 392 – 7 BUC 393 – 8 BUC 394 – 9 BUC 395 – 10 BUC 396 - 11 BUC Page 90 - Annexes Methodology The raw data are first imported thanks to an Ifremer software module, “Import des données du Victor 6000”. This software converts the raw data to ArcGIS format (.dbf) and sorts the data by type. Navigation data was processed with the Ifremer software, Adelie. This software is delivered as an extension of the GIS software ArcGIS of ESRI enterprise. Adelie gives tools to draw tracks and export them to a readable format for the ROV team (Vemo+ format) before the dives and tools to process the navigation after the dives (filters, conversion of points to lines, smoothing of the tracks…). Aberrant points were removed from the navigation data by filtering. Then, the navigation tracks were smoothed using a Gaussian algorithm. Processing Line Victor raw navigation data Victor imported navigation data Victor processed navigation data (Every ArcGIS Shapefile contains 6 files) Output Data Once processed, the data are in an ESRI format: one shapefile (.shp) for each dive with the time and the coordinates. They were converted to different formats for those who needed the navigation data. So, in the final data storage, there are three folders: One with the Shapefiles (ArcGIS-ESRI format) One with Excel files One with text files formatted for Caraïbe (for the bathymetry processing) Page 91 - Annexes Chronological summary Dive 386-1 Dive 387-2 Dive 388-3 01/09/09 to 02/09/09 02/09/09 to 03/09/09 04/09/09 to 05/09/09 3 short dives in sampling mode with a technical problem on the arm “maestro” Dive 389-4 05/09/09 to 09/09/09 1 long dive in sampling mode Dive 390-5 Dive 391-6 10/09/09 to 11/09/09 11/09/09 to 14/09/09 2 dives with OTUS, magnetism and MMR at an altitude of 8m Dive 392-7 15/09/09 to 16/09/09 1 dive in sampling mode Dive 393-8 Dive 394-9 16/09/09 to 19/09/09 19/09/09 to 21/09/09 2 dives with MMR at an altitude of 50m Dive 395-10 21/09/09 to 24/09/09 1 dive in sampling mode Dive 396-11 24/09/09 to 26/09/09 1 dive with MMR at an altitude of 50m Sampling dives Three dives have been performed in sampling mode to sample fluids and fauna and capture video of the LuckyStrike vent sites. During these three dives, instrumentation was deployed and recovered too: at the very beginning of the cruise temperature probes were deployed on the volcano area, at the middle of the cruise two pressure gauges were replaced, at the end of the cruise the short period instrumentation was recovered, and the rest of the instrumentation was deployed for one more year. Before this, three dives were performed in sampling mode but only a few operations were successfull because of technical problems on the arm of Victor. Page 92 - Annexes Dive 386 Date 03/09/2009 Observateurs CANNAT Mathilde ESCARTIN Javier Station Lucky strike Latitude Moyenne N 37 17.5000 Longitude Moyenne W 32 16.7000 Objectifs de la plongée 3 sites d'études prévus : MontSegur, Tour Eiffel et Roldan Récupération de capteurs de températures et de boîtes microbio. Pose de nouveau capteurs de température et de boîte microbio. Prélèvement de fluides et de biologie. Bilan de la plongée Aucune opération effectuée Problème technique diagnostiquée sur le bras du Victor Plongée écourtée Page 93 - Annexes Dive 387 Date 02/09/2009 Observateurs CANNAT Mathilde ESCARTIN Javier CHAVAGNAC Valérie Station Lucky strike Latitude Moyenne N 37 17.5000 Longitude Moyenne W 32 16.7000 Objectifs de la plongée 3 sites d'études prévus : MontSegur, Tour Eiffel et Roldan Récupération de capteurs de températures et de boîtes microbio. Pose de nouveau capteurs de température et de boîte microbio. Prélèvement de fluides et de biologie. Bilan de la plongée Aucune opération effectuée Problème technique diagnostiquée sur le bras du Victor Plongée écourtée Page 94 - Annexes Dive 388 Date 04/09/2009 Observateurs CANNAT Mathilde ESCARTIN Javier CHAVAGNAC Valérie BOULARD Cédric BARREYRE Thibaut Station Lucky strike Latitude Moyenne N 37 17.5000 Longitude Moyenne W 32 16.7000 Objectifs de la plongée 3 sites d'études prévus : MontSegur, Tour Eiffel et Roldan Récupération de capteurs de températures et de boîtes microbio. Pose de nouveau capteurs de température et de boîte microbio. Prélèvement de fluides et de biologie. Bilan de la plongée 1 capteur de température posé 2 capteurs de température récupérés 3 seringues de fluide prélevées 2 bouteilles de fluide prélevées Problème technique diagnostiquée sur le bras du Victor Plongée écourtée Page 95 - Annexes Dive 389 Date 05/09/2009 Observateurs BARREYRE Thibault, BOULART Cédric, CANNAT Mathilde, CARLUT Julie, CHAVAGNAC Valérie, CREPEAU Valentin, CASTILLO Alain, ESCARTIN Javier, LEFEBVRE Alice, LESONGEUR Françoise, MALVOISIN Benjamin, MESTRE Nelia, MITTELSTAED Eric, ROMEVAUX-JESTIN Céline, SALOCCHI Aura Station Lucky strike Latitude Moyenne N 37 17.5000 Longitude Moyenne W 32 16.7000 Objectifs de la plongée Bilan de la plongée Sites d'étude: MontSegur, Tour Eiffel, Roldan, Pico, Isabel, Crystal, White Castel, Y3 Récupération de l'instrumentation mise en place durant la campagne MoMAR'08 (capteurs de température et colonisateurs microbiologiques), Mise en place d'une série de capteurs de température pour une an ou un mois de mesures Pélèvements de fluides et faune sur les sites hydrothermaux Capture vidéo de plumes hydrothermaux 26 capteur de température posé et 5 récupérés 9 seringues et 10 bouteilles de fluide prélevées 2 colonisateurs microbiologiques récupérés et 1 déployé 11 vidéos capturées Page 96 - Annexes Dive 392 Date 15/09/2009 Observateurs BARREYRE Thibault, BOULART Cédric, CANNAT Mathilde, CARLUT Julie, CHAVAGNAC Valérie, CREPEAU Valentin, CASTILLO Alain, ESCARTIN Javier, LEFEBVRE Alice, LESONGEUR Françoise, MALVOISIN Benjamin, MESTRE Nelia, MITTELSTAED Eric, ROMEVAUX-JESTIN Céline, SALOCCHI Aura, LECOMTE Benoit, POT Olivier, SILVA Catia Station Lucky strike Latitude Moyenne N 37 17.5000 Longitude Moyenne W 32 16.7000 Objectifs de la plongée Bilan de la plongée Récupération et remplacement des capteurs de pression Prélèvement de fluides et d’échantillons biologiques Récupération et pose de colonisateurs microbiologiques Remise en place du dernier capteur de température Mise en place d'un panneau de calibration pour la caméra 1 capteur de température posé et 6 récupérés 4 seringues et 4 bouteilles de fluide prélevées 3 colonisateurs microbiologiques récupérés et 1 déployé 4 prélèvements biologiques 1 vidéo capturée Page 97 - Annexes Dive 395 Date 21/09/2009 Observateurs BARREYRE Thibault, BOULART Cédric, CANNAT Mathilde, CARLUT Julie, CHAVAGNAC Valérie, CREPEAU Valentin, CASTILLO Alain, ESCARTIN Javier, LEFEBVRE Alice, LESONGEUR Françoise, MALVOISIN Benjamin, MESTRE Nelia, MITTELSTAED Eric, ROMEVAUX-JESTIN Céline, SALOCCHI Aura, LECOMTE Benoit, POT Olivier, SILVA Catia Station Lucky strike Latitude Moyenne N 37 17.5000 Longitude Moyenne W 32 16.7000 Objectifs de la plongée Bilan de la plongée Récupération et remplacement des capteurs de pression Prélèvement de fluides et d’échantillons biologiques Récupération et pose de colonisateurs microbiologiques Remise en place du dernier capteur de température Mise en place d'un panneau de calibration pour la caméra 11 capteur de température posé et 11 récupérés 12 seringues et 9 bouteilles de fluide prélevées 1 colonisateur microbiologique récupéré et 1 déployé 5 prélèvements biologiques 16 vidéos capturées Page 98 - Annexes Survey Dives Two types of survey dives were performed: For the OTUS acquisition, two dives (390 and 391) were performed at an altitude of 8m with an interval between tracks of 15m. During these two dives, the MMR was turned on but there were several technical problems. For the MMR acquisition, three dives (393, 394 and 396) were performed at an altitude of 50m with an interval between tracks of 120m. Page 99 - Annexes Dive 390 Date 10/09/2009 Station Lucky strike Objectifs de la plongée Compléter le survey OTUS de la campagne MoMAR08 au NordEst du lac de lave Page 100 - Annexes Dive 391 Date 11/09/2009 Station Lucky strike Compléter le survey OTUS de la campagne MoMAR08 au lac de lave Compléter la couverture OTUS des sites hydrothermaux principaux Trouver le site Hydrothermal Ewan découvert durant la campagne Graviluck06 Bilan de 3 vidéos capturées la plongée Ewan est proche Objectifs de la plongée Page 101 - Annexes Dive 393 Date 16/09/2009 Station Lucky strike Objectifs de la plongée Compléter la couverture cartographique au centre et au sud du volcan LuckyStrike Dive 394 Date 19/09/2009 Station Lucky strike Objectifs de la plongée Compléter la couverture cartographique au sud du volcan LuckyStrike et vers le sud le long de l’axe de la dorsale Page 102 - Annexes Dive 396 Date 24/09/2009 Station Lucky strike Objectifs de la plongée Compléter la couverture cartographique au sud du segment LuckyStrike Page 103 - Annexes AUV Navigation Data and Positioning systems AsterX is an AUV (Autonomous Underwater Vehicle). Its trajectory is programmed on board before each dive and is not modifiable during the dive. In real time it reports its acoustic position which allows a relocalisation to its actual position. The only modification permitted during a dive is to force the AUV to jump over portions of the curent dive plan. PHINS – Estimated navigation During the dives, the AUV AsterX calculates his geographical position from his previous position and the data given by his inertial sensor, the PHINS. This positioning system is very accurate locally but a drift can be introduced by submarine currents. In consequence, the AUV always thinks that it is on its programmed trajectory but actually it often drifts off course, especially during descent. So, the AUV team must occasionally relocalisate it using the acoustic position. GAPS – Global Acoustic Positioning System The AUV can have the same data as Victor 6000 because it has the same BUC positionning system, but the GAPS is used by the AUV team because it is more accurate and more stable. Data processing Raw Data For each dive, the AUV Team gives a numeric folder with all the data recorded by the AUV during the dives. This folder had 4 subfolders which contain: The ‘log_AUV’ with the GPS data, the PHINS data (roll, pitch, heading, depth, altitude, CTD, and vehicle status during the dive) The bathymetry data in the folder “CU” (charge utile) The GAPS raw data All the files which Mimosa outputs (Mimosa is the software used by the AUV team to manage the dives: programming of the trajectory, monitoring of the dives…). The files are sorted by type. The data used for the navigation processing is the GAPS synchro data which is sorted by Mimosa. This data is delivered in a NMEA format: all the PTSAG lines of the GAPS receptor are grouped in a text file by Mimosa. Methodology The first step of the process is the conversion of the GAPS data to a text format readable by ArcGIS. Once imported in ArcGIS, the methodology and the sofware are the same as for the Victor navigation processing: first the aberrant points are filtered and then the tracks are smoothed. But the difference is that the AUV tracks are less smoothed for two reasons: The GAPS data are cleaner than that provided by the BUC. The descent and ascent of the AUV is helical and these parts of the trajectory are usefull for the calibration of the magnetometer. A strong smooth would erase the helical trajectory. Page 104 - Annexes Output Data Once processed, the data are in an ESRI format: one shapefile (.shp) for each dive with the time and the coordinates. They have been converted to different formats for those who needed the navigation data. So, in the final data storage, there are three foolders: One with the Shapefiles (ArcGIS-ESRI format) One with Excel files One with text files formatted for Caraïbe (for the bathymetry processing) Chronological summary Dive 1 Dive 2 04/09/09 09:35-13:17 14:30–16:09 Dive 4 11/09/09 11:58-15:56 Dive 6 16/09/09 11:32-17:38 Dive 7 19/09/09 11:24-17:19 Dive 8 21/09/09 11:21-20:03 Dive 9 24/09/09 09:27-18:14 2 short dives with technical problems Orientation North-South 1 short dive with technical problems 1 dive in Menez Hom area 1 short dive with technical problems 1 long dive in Menez Hom area 1 long dive in the South of the segment Page 105 - 2 profiles 1 profile 4 profiles + 3 transverses 1,5 profile 11 profiles 7,5 profiles Annexes Dive 1 and 2 Date Objectifs plongée 04/09/2009 de la Cartographie du segment LuckyStrike parallèlement à l’axe Page 106 - Annexes Dive 4 Date 11/09/2009 Objectifs de la plongée Cartographie du perpendiculairement à l’axe segment Dive 6 Date 16/09/2009 Objectifs de la plongée Cartographie de la zone de Menez Hom Page 107 - LuckyStrike Annexes Dive 7 Date 19/09/2009 Objectifs de la plongée Cartographie du Segment LuckyStrike Dive 8 Date 21/09/2009 Objectifs de la plongée Cartographie de la zone de Menez Hom Page 108 - Annexes Dive 9 Date 24/09/2009 Objectifs de la plongée Cartographie du Segment LuckyStrike Page 109 -