Rapport TFE Hoarau3_save17h15_261009_corrige

Transcription

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

Documents pareils