Stage de Travaux de Fin d’Etudes - ENSG, l'école de la

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 à Suivi à Suivi à Suivi à long terme du site hydrothermallong terme du site hydrothermallong terme du site hydrothermallong terme du site hydrothermal

Lucky Strike (Dorsale Nord Atlantique)Lucky Strike (Dorsale Nord Atlantique)Lucky Strike (Dorsale Nord Atlantique)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 -

- Page 3 -

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

Diffusion Web : Internet 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 4 -

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 sous-

marines.

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 5 -

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 6 -

Sommaire

- Page 7 -

Sommaire

Jury 3

Glossaire 4

Sommaire 7

Résumé 11

Abstract 11

Liste des Annexes 12

Liste des Figures 13

Remerciements 15

Introduction 17

I. Contexte et Enjeux Scientifiques 19

A. Présentation de L’Institut de Physique du Globe 19

B. Présentation de l’équipe de GéoSciences Marines 19

C. Présentation du projet MoMAR 20

II. Réalisation d’une interface de partage de données 21

A. Inventaire des données mises en lignes 21

1. Les sources de données 21 a) La Géodatabase ArcGIS 21 b) Les Campagnes en mer 23

i. Données acquises par les capteurs des engins et du PourquoiPas 23 ii. Données issues des rapports de plongées 23

c) Les données créées durant le stage 24 i. Métadonnées sur les campagnes du projet MoMAR 24 ii. Données images et métadonnées associées 24 iii. Gestion et sécurité du site créé 24

2. Modèle Conceptuel de données 25 a) Sécurité des données 26

i. Protection contre les tentatives de piratage 26 ii. Restrictions d’accès au site Internet 26

b) Données géographiques et temporelles 27 c) Les plongées, nœud de liaison entre les données 27

3. Implémentation de la base de données 28

Sommaire

- Page 8 -

B. Analyse fonctionnelle 28

1. Organisation du site Internet 28

2. Inventaire des fonctions nécessaires 29 a) Exploration des données des campagnes MoMAR 29

i. Sélection des données 29 ii. Navigation 29 iii. Affichage des données 29

b) Reconstitution de plongées virtuelles 30 i. Sélection des données 30 ii. Visualisation virtuelle des plongées 30 iii. Navigation temporelle 30

c) Fonctionnalités générales 30

3. Interfaces graphiques 31 a) Cartographie Interactive 31 b) Plongées virtuelles 33

C. Réalisation 35

1. Architecture 35 a) Client-Serveur et Serveur cartographique WMS 35 b) Organisation physique des fichiers 36

2. Solutions techniques 38 a) Langages de programmation 38

i. Html et CSS 38 ii. Javascript 38 iii. PHP et SQL 39

b) Technologies Explorées 39 i. OpenLayers 39 ii. GéoServer 41

c) Bibliothèques supplémentaires 42 i. Prototype 42 ii. Scriptaculous 43 iii. FancyZoom 44 iv. JpGraph 44 v. FPdf 44

3. Gestion de projet 45 a) Processus de mise en ligne 45 b) Déroulement du stage 46 c) Perspectives de développement 49

Sommaire

- Page 9 -

III. BathyLuck09’ 50

A. Navigation des engins submersibles 50

1. Logiciels et Formation 50

2. Préparation des plongées 51 a) Élaboration des trajectoires des plongées 51 b) Cartographie de travail 52 c) Lien avec l’équipe de pilotage des engins 52

3. Données et Traitements 53 a) Données brutes 53 b) Reconstitution de la navigation réelle 53 c) Données finales 57

B. Opératrice SIG 58

1. Cartographie exploratoire et Aide à la décision 59

2. Synthèse des opérations 60 a) Rapports Alamer 60 b) Cartographie de synthèse 61

C. Gestion des données 64

1. Politique de sauvegarde 64

2. Intégration des données 65 i. Base de données administrateur 65 ii. Base de données Utilisateur sous ArcGIS 66 iii. Base de données PostGresSQL 66

Conclusion 67

Bibliographie 69

Rapports Imprimés 69

Sites Internet consultés 70

Programmation et Webmapping 70 Entraide informatique 70 Entraide Géomatique 70 Frameworks en JavaScript 70 Frameworks en PHP 70 Systèmes de Gestion de Bases de Données 71

Géosciences Marines 71 Le Projet MoMAR 71 WHOI – Woods Hole Oceanographic Institute 71 MGDS – Marine GéoSciences Data System 71

Base de données 71

Annexes 72

- Page 10 -

- Page 11 -

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 12 -

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 : 76

1. Formatage des données pour GéoServer 76

2. Stockage des données dans GéoServer 77

3. Configuration du service WMS dans GéoServer 77

4. Vérification 77 Tutoriel sur le site de Geoserver 78 Info sur les CoverageStores 78 Info sur les Coverages 78 Couches WMS en place 78

Annexe 4 : Carnet de bord 79

Annexe 5 – Cruise Report - Navigation 89

Victor Navigation 89

Positioning systems 89 Estimated Navigation 89 BUC – Base Ultra Courte 89 Two complementary systems 89

Data processing 89 Raw Data 89 Methodology 91 Output Data 91

Chronological summary 92

Sampling dives 92

Survey Dives 99

AUV Navigation 104

Data and Positioning systems 104 PHINS – Estimated navigation 104 GAPS – Global Acoustic Positioning System 104

Data processing 104 Raw Data 104 Methodology 104 Output Data 105

Chronological summary 105

- Page 13 -

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 14 -

- Page 15 -

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 16 -

Introduction

- Page 17 -

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.

Introduction

- Page 18 -

l. Contexte et Enjeux Scientifiques

- Page 19 -

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.

l. Contexte et Enjeux Scientifiques

- Page 20 -

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.

ll. Réalisation d’une interface Web de partage des données

- Page 21 -

II. Réalisation d’une interface Web

de partage de données

A. Inventaire des données mises en lignes

1. Les sources de données

a) 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 22 -

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 raster de bathymétrie, de Sonar, de gravimétrie et de magnétisme.

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 23 -

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. i. i. i. Données acquises par les capteurs des engins et du PourquoiPasDonnées acquises par les capteurs des engins et du PourquoiPasDonnées acquises par les capteurs des engins et du PourquoiPasDonné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. ii. ii. ii. Données issues des rapports de plongéesDonnées issues des rapports de plongéesDonnées issues des rapports de plongéesDonné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 24 -

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. i. i. i. Métadonnées sur les campagnes du projet MoMARMétadonnées sur les campagnes du projet MoMARMétadonnées sur les campagnes du projet MoMARMé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. ii. ii. ii. Données images et métadonnées associéesDonnées images et métadonnées associéesDonnées images et métadonnées associéesDonné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. iii. iii. iii. Gestion et sécurité du site crééGestion et sécurité du site crééGestion et sécurité du site créé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 25 -

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 26 -

a) Sécurité des données

i. i. i. i. Protection contre les tentatives de piratageProtection contre les tentatives de piratageProtection contre les tentatives de piratageProtection 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. ii. ii. ii. Restrictions d’accès au site Restrictions d’accès au site Restrictions d’accès au site Restrictions d’accès au site InternetInternetInternetInternet

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 27 -

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 28 -

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 29 -

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. i. i. i. Sélection des donnéesSélection des donnéesSélection des donnéesSé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. ii. ii. ii. NavigationNavigationNavigationNavigation

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. iii. iii. iii. Affichage des donnéesAffichage des donnéesAffichage des donnéesAffichage des données

Gestion de la superposition et de l’ordre des couches

Choix de la sémiologie


- Page 30 -

b) Reconstitution de plongées virtuelles

i. i. i. i. Sélection des donnéesSélection des donnéesSélection des donnéesSé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. ii. ii. ii. Visualisation virtuelle des plongéeVisualisation virtuelle des plongéeVisualisation virtuelle des plongéeVisualisation virtuelle des plongéessss

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. iii. iii. iii. Navigation temporelleNavigation temporelleNavigation temporelleNavigation 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 31 -

3. Interfaces graphiques

a) 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 32 -

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 33 -

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 34 -

Figure 7 - Export du module vidéo sous forme de fiche synthétique


- Page 35 -

C. Réalisation

1. Architecture

a) 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 36 -

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 37 -

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 38 -

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. i. i. i. Html et Html et Html et Html et CSSCSSCSSCSS

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. ii. ii. ii. JavascriptJavascriptJavascriptJavascript

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 39 -

iii. iii. iii. iii. PHPHPHPHPPPP et SQL et SQL et SQL 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. i. i. i. OpenLayersOpenLayersOpenLayersOpenLayers

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 Ge osciences

var topo = new OpenLayers.Layer.MapServer(

"MGDS Global Multi-Resolution Topography (GMRT)",

"http://www.marine-geo.org/exe/mapserv?map_imagety pe=jpeg&",

{map: '/home/mgds/web/www.marine-geo.org/htdocs/se rvices/ogc/wms.map',

layers: 'topo'});


- Page 40 -

//Appel d’une couche WMS sur le serveur GeoServer m is en place

var bathy_momar = new OpenLayers.Layer.WMS(

"Momar Bathymetry", "http://janus.ipgp.fr:8080/geo server/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 2co uches 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('mapSca le'));

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'), numdigi ts: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.ne xt]);

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 41 -

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. ii. ii. ii. GéoServerGéoServerGéoServerGé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 42 -

c) Bibliothèques supplémentaires

i. i. i. i. PrototypePrototypePrototypePrototype

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 43 -

ii. ii. ii. ii. ScriptaculousScriptaculousScriptaculousScriptaculous

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 44 -

iii. iii. iii. iii. FancyZoomFancyZoomFancyZoomFancyZoom

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"> //im age affichée par click

<img id="cam1" src="public/image/imgInit.jpg" titl e="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. iv. iv. iv. JpGraphJpGraphJpGraphJpGraph

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. v. v. v. FPdfFPdfFPdfFPdf

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 45 -

3. Gestion de projet

a) 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 46 -

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 47 -

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 48 -

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 49 -

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

lll. Bathyluck’09

- Page 50 -

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.

lll. Bathyluck’09

- Page 51 -

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 8 m 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

lll. Bathyluck’09

- Page 52 -

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.

lll. Bathyluck’09

- Page 53 -

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. Données et Traitements

a) 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.

lll. Bathyluck’09

- Page 54 -

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

lll. Bathyluck’09

- Page 55 -

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

lll. Bathyluck’09

- Page 56 -

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

lll. Bathyluck’09

- Page 57 -

c) Données finales

La trajectoire finale ainsi obtenue est au format ESRI sous forme d’un Shapefile de linéaires. Ce format est lisible par la plupart des SIG libres et du commerce. Cependant, les chercheurs en géosciences marines ne sont pas coutumiers de ces logiciels. Aussi, chaque trajectoire a été exportée en format Excel et texte afin de pouvoir être lue par les personnes intéressées.

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

lll. Bathyluck’09

- Page 58 -

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.

lll. Bathyluck’09

- Page 59 -

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 pas contraintes par une position géographique précise prédéfinie

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.

lll. Bathyluck’09

- Page 60 -

2. Synthèse des opérations

a) 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.

lll. Bathyluck’09

- Page 61 -

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

lll. Bathyluck’09

- Page 62 -

Figure 36 – Echantillonnage de roches pour l’étude volcanologique

lll. Bathyluck’09

- Page 63 -

Figure 37 – Répartition des capteurs de température sur le site hydrothermal MontSégur

lll. Bathyluck’09

- Page 64 -

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

(au format DVD et compressé en mp4) ≈ 2 Tb

Données bathymétriques en cours de traitement 600 Gb

Données brutes Victor6000 et AsterX

(Navigation, Capteurs, Bathymétrie, OTUS) 1Tb

Données thématiques

(Magnétisme, MapR, Pression, Navigation, Biologie, Chimie, GIS, Rapport de campagne)

100 Gb

Données sismiques des OBS

(Brutes et converties au format .sac) 150 Gb

lll. Bathyluck’09

- Page 65 -

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. i. i. i. Base de données administrateurBase de données administrateurBase de données administrateurBase 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.

lll. Bathyluck’09

- Page 66 -

À 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. ii. ii. ii. Base de donBase de donBase de donBase de données Utilisateur sous ArcGISnées Utilisateur sous ArcGISnées Utilisateur sous ArcGISné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. iii. iii. iii. Base de données PostGresSQLBase de données PostGresSQLBase de données PostGresSQLBase 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.

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

- Page 69 -

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édio-

atlantique. 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.

Bibliographie

- Page 70 -

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/OpenLayers-js.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

Bibliographie

- Page 71 -

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.

Annexes

- Page 72 -

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

Annexes

- Page 73 -

Annexe 2 - Modèle physique de données

att_pl id_att Integer cap Real gite Real assiette Real immersion Real altitude Real vitesse_x Real vitesse_y Real pan Real tilt Real cap_ccd Real ass_ccd Real zoom Integer ouverture Integer focus Integer id_pl Integer

dateheure Timestamp without time zone

temps Integer

campagne id_camp Integer name Text date_deb Date date_fin Date chef Text annee Integer id_vessel Integer

droits_groups id_group Integer id_page Integer date Date droit Character(8)

groups id_group Integer date_in Date nom Character(32) gidnumber Integer

image id_image Integer chemin Text cam Integer dive Integer heure Time without time zone


src Text nom Text temps Integer

instruments gid Integer name Character varying(12) cruise_pi Character varying(12) pi Character varying(12) date Character varying(12) time Character varying(12) latitude Numeric longitude Numeric depth Numeric cruise Character varying(12) vessel Character varying(12) recovery Character varying(12) rec_cruise Character varying(12) ship_lat Numeric ship_lon Numeric utmx Numeric utmy Numeric site Character varying(30) type Character varying(50) comments Character varying(100) instrument Character varying(50) the_geom geometry

pages id_page Integer date_in Date libelle Character(32) titre_page Character(64) icone Character(32)

Annexes

- Page 74 -

markers_benchmarks gid Integer objectid Integer name Character varying(254) cruise_pi Character varying(12) pi Character varying(12) date Character varying(15) time Character varying(10) latitude Numeric longitude Numeric depth Numeric cruise Character varying(20) vessel Character varying(15) recovery Character varying(20) rec_date Character varying(10) rec_cruise Character varying(20) dive Numeric type Character varying(50) utmx Numeric utmy Numeric comments Character varying(100) the_geom geometry

report id_report Integer


localite Character(32) latitude Text longitude Text prof Integer cap Real dive Integer commentaires Text temps Integer

vessel id_vessel Integer name Text institute Text page_web Text

users id_user Integer date_in Date login Character(32) password Character(128) name Character(50) firstname Character(50)

user_groups id_user Integer id_group Integer date_in Date

vehicle id_vehicler Integer name Text type Text institute Text

vent_sites gid Integer name Character varying(25) latitude Numeric longitude Numeric depth Numeric markers Character varying(50) x_utm Numeric y_utm Numeric the_geom 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)


temps Integer

Annexes

- Page 75 -

plongee id_pl Integer num_abs Integer num_rel Integer date_deb Timestamp without time zone date_fin Timestamp without time zone date_arr Timestamp without time zone date_dep Timestamp without time zone positionnement Text lat_min Real lat_max Real lon_min Real lon_max Real dx_aire Integer dy_aire Integer profondeur Integer utm_nb Integer utm_x0 Integer utm_y0 Integer hemisphere Character (2) status Text commentaire Text id_camp Integer responsable Text preliminary_navigation_file Text lat_moy Text lon_moy Text id_vehicle Integer

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.

Annexes

- Page 76 -

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.

ImportantImportantImportantImportant :::: 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

Annexes

- Page 77 -

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"

VVVValider alider alider alider les configuration réalisées avec les boutonsles configuration réalisées avec les boutonsles configuration réalisées avec les boutonsles configuration réalisées avec les boutons "APPLY" ET "SAVE" "APPLY" ET "SAVE" "APPLY" ET "SAVE" "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", un dossier "nom du CoverageStorage_nom du Coverage" a dû se créer

Si ça n'a pas marché, autant tout recommencer ;)Si ça n'a pas marché, autant tout recommencer ;)Si ça n'a pas marché, autant tout recommencer ;)Si ça n'a pas marché, autant tout recommencer ;)

Annexes

- Page 78 -

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

Annexes

Page 79 -

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

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

Page 80 -

Vendredi 15 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

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

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

Mercredi 20 Mai 2009 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

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 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

Page 81 -

Mercredi 27 Mai 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

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 2 Juin 2009 Départ pour les Açores Préparation pour la mission Annulation de la mission => Déception

Mercredi 3 Juin 2009 Organisation du rapatriement de l'équipe scientifique Visite géologique du Volcan Do Caphelino sur l'île de Horta

Jeudi 4 Juin 2009 Retour en France

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

Lundi 8 Juin 2009 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

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 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

Jeudi 11 Juin 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

Vendredi 12 Juin 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

Page 82 -

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

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

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 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

Page 83 -

Jeudi 25 Juin 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

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)

Mercredi 1 Juillet 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

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 secondes depuis le 1

er 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

Page 84 -

Lundi 20 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

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

Lundi 27 Juillet 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 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

Page 85 -

Jeudi 30 Juillet 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

Vendredi 31 Juillet 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

Lundi 3 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

Mardi 4 Aout 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

Jeudi 6 Aout 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 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.

Mardi 11 Aout 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

Mercredi 12 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

Annexes

Page 86 -

Jeudi 13 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

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

Lundi 17 Aout Travail sur l’affichage des navigations Recherches sur l’export de la carte OpenLayers en format image (jpeg)

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 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

Vendredi 21 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

Lundi 24 Aout 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

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 Rédaction du rapport de stage (OpenLayers, Glossaire, GéoServer)

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

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

Samedi 29 et Dimanche 30 Aout Transit aérien vers Horta

Lundi 31 Aout 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

Annexes

Page 87 -

Mardi 1 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é

Mercredi 2 Septembre 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

Vendredi 4 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

Samedi 5 Septembre Explications à Javier du logiciel Alamer Préparation pl AUV (profil 2 perpendiculaire à l’axe) Rédaction du planning pour les 3 jours à venir

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

Lundi 7 Septembre 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

Mardi 8 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

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 11 Septembre 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 12 Septembre 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 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

Page 88 -

Lundi 14 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

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 Tracé de la 1

ère 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

Jeudi 17 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

Vendredi 18 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 Préparation des profils MMR et AUV pour différents scénarios Calage des capteurs de température avec Thilbaut

Dimanche 20 Septembre Préparation boîte AUV avec Mathilde et Patrice Point avec Mathilde sur l’inventaire des données et le Cruise Report

Lundi 21 Septembre 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 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

Vendredi 25 Septembre 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

Samedi 26 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

Dimanche 27 Septembre Cartographie finale des plongées du Victor Export des rapports Alamer et des données Mag et CTD manquantes

Lundi 28 Septembre Rédaction du Cruise Report Sauvegarde des données du NAS

Annexes

Page 89 -

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.

Annexes

Page 90 -

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




390 – 5 Estimated Navigation


392 – 7 BUC

393 – 8 BUC

394 – 9 BUC

395 – 10 BUC

396 - 11 BUC

Annexes

Page 91 -

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)

Annexes

Page 92 -

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.

Annexes

Page 93 -

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

Annexes

Page 94 -

Dive 387

Date 02/09/2009

Observateurs CANNAT Mathilde ESCARTIN Javier CHAVAGNAC Valérie



Longitude Moyenne W 32 16.7000




Aucune opération effectuée Problème technique diagnostiquée sur le bras du Victor Plongée écourtée

Annexes

Page 95 -

Dive 388

Date 04/09/2009

Observateurs

CANNAT Mathilde ESCARTIN Javier CHAVAGNAC Valérie BOULARD Cédric BARREYRE Thibaut







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

Annexes

Page 96 -

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





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

Annexes

Page 97 -

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





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

Annexes

Page 98 -

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





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

Annexes

Page 99 -

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.

Annexes

Page 100 -

Dive 390

Date 10/09/2009



Compléter le survey OTUS de la campagne MoMAR08 au Nord-Est du lac de lave

Annexes

Page 101 -

Dive 391

Date 11/09/2009



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


3 vidéos capturées Ewan est proche

Annexes

Page 102 -

Dive 393

Date 16/09/2009



Compléter la couverture cartographique au centre et au sud du volcan LuckyStrike

Dive 394

Date 19/09/2009



Compléter la couverture cartographique au sud du volcan LuckyStrike et vers le sud le long de l’axe de la dorsale

Annexes

Page 103 -

Dive 396

Date 24/09/2009



Compléter la couverture cartographique au sud du segment LuckyStrike

Annexes

Page 104 -

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.

Annexes

Page 105 -

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

2 short dives with technical problems Orientation North-South

2 profiles

Dive 4 11/09/09 11:58-15:56 1 short dive with technical problems 1 profile

Dive 6 16/09/09 11:32-17:38 1 dive in Menez Hom area 4 profiles + 3 transverses

Dive 7 19/09/09 11:24-17:19 1 short dive with technical problems 1,5 profile

Dive 8 21/09/09 11:21-20:03 1 long dive in Menez Hom area 11 profiles

Dive 9 24/09/09 09:27-18:14 1 long dive in the South of the segment 7,5 profiles

Annexes

Page 106 -

Dive 1 and 2

Date 04/09/2009


Cartographie du segment LuckyStrike parallèlement à l’axe

Annexes

Page 107 -

Dive 4

Date 11/09/2009

Objectifs de la plongée Cartographie du segment LuckyStrike perpendiculairement à l’axe

Dive 6

Date 16/09/2009

Objectifs de la plongée Cartographie de la zone de Menez Hom

Annexes

Page 108 -

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

Annexes

Page 109 -

Dive 9

Date 24/09/2009

Objectifs de la plongée Cartographie du Segment LuckyStrike

Documents

Stage de Travaux de Fin d’Etudes - ENSG, l'école de la