Nomenclature pour les métadonnées sismologiques des niveaux

Transcription

Nomenclature pour les métadonnées
sismologiques des niveaux 'network', 'station',
'channel'
Auteurs : groupe Nomenclature RESIF
Date de mise à jour : 2014-01-23
Version : 1.6
État : document de travail
Diffusion : RESIF
Objet du document :
Ce document propose une nomenclature commune qui est issue des travaux du groupe
«nomenclature et station.xml» de RESIF. La nomenclature concerne les réseaux, les stations
et les canaux d'acquisition et tous leurs attributs. La structure de données de référence est la
structure FDSN-stationXML définie par la FDSN.
1
Mises à jour du document :
Version
Date
1.0
2013/05/20 C. Péquegnat
Création du document
1.1
Intégration des commentaires issus du CR de la
réunion de mai 2013, rédigés par G. Cougoulat
1.2
Intégration des modifications qui font suite à l'atelier
nomenclature de Yenne. Le document est scindé en
deux parties (texte et tables).
1.3
Modification en fonction des retours et mises à jour
des tables de travail.
1.4
Intégration des commentaires entendus pendant la
réunion téléphonique 2013/12/16
1.5
Intégration des commentaires de C.Maron
1.6
Intégration
des
modifications
des
tables
AgencyTable et NetworkTable proposées par la
direction de RESIF. Modification du § 6.1 (choix du
modèle des aliases de messageries, suite à
directives de la direction de RESIF
2
Rédacteur (sur la base des documents et Objet de la mise à jour
remarques fournis par les membres du
groupe)
Membres du groupe 'Nomenclature RESIF'
Nom
Institut ou Laboratoire ou OSU
Bes de Berc Maxime
EOST
Brunel Didier
OCA
Cano Yoann
CEA
Cougoulat Glenn
ISTerre
Crawford Wayne
IPGP
Dewée Olivier
IPGP
Dutil Martin
EOST
Engel Fabien
EOST
Janex Gaël
ISTerre
Langlais Mickaël
ISTerre
Leroy Nicolas
IPGP
Maron Christophe
OCA
Olivier Serge
CEA
Pardo Constanza
IPGP
Péquegnat Catherine
ISTerre
Vergne Jérôme
EOST
Wolyniec David
OSUG
3
Table des matières
1 Introduction.............................................................................................................................. 6
2 Documents de référence.........................................................................................................6
3 Structure du document............................................................................................................7
4 But et périmètre de la nomenclature........................................................................................7
4.1 Caractère pro-actif et non normatif de la nomenclature....................................................8
4.2 Antennes et instruments concernés.................................................................................8
5 Langue d'expression des métadonnées...................................................................................9
6 Proposition de nomenclature...................................................................................................9
6.1 Niveau Network................................................................................................................9
6.1.1 Description ............................................................................................................. 10
6.1.2 Restricted Status....................................................................................................11
6.1.3 Comment ............................................................................................................... 11
6.1.4 alternateCode , historicalCode ...............................................................................12
6.1.5 Extensions au modèle proposées pour le niveau Network......................................13
6.2 Niveau Station ............................................................................................................... 13
6.2.1 Nom de stations (code)...........................................................................................14
6.2.2 alternateCode, historicalCode.................................................................................14
6.2.3 Description des stations..........................................................................................14
6.2.4 Comment................................................................................................................ 15
6.2.5 RestrictedStatus.....................................................................................................16
6.2.6 Site......................................................................................................................... 16
6.2.7 Vault....................................................................................................................... 17
6.2.8 Geology.................................................................................................................. 17
6.2.9 Operator................................................................................................................. 17
6.2.10 Equipment............................................................................................................ 18
6.2.11 Extensions au modèle proposées pour le niveau Station......................................18
6.3 Niveau Channel.............................................................................................................. 18
6.3.1 RestrictedStatus.....................................................................................................20
6.3.2 Description des Channels.......................................................................................20
6.3.3 Comment................................................................................................................ 20
6.3.4 Equipment (Sensor, Dataloger)...............................................................................21
6.3.5 Serial Number.........................................................................................................22
4
6.3.6 Extensions demandées..........................................................................................22
6.3.7 Autres éléments de description des canaux (non encore analysés par le groupe de
travail).............................................................................................................................. 22
5
1 Introduction
Ce document propose une nomenclature pour les métadonnées sismologiques au sein
du SI RESIF. La nomenclature concerne les réseaux, les stations et les canaux et tous leurs
attributs.
Le modèle de données de référence est la structure FDSN-stationXML définie par la
FDSN (référence, voir § 2). Le document concerne uniquement l'expression linguistique des
éléments terminaux des 3 premiers niveaux du modèle défini par FDSN-stationXML.
Nous précisons que FDSN-stationXML décrit les métadonnées nécessaires à
l'utilisation et à l'interprétation des données par les utilisateurs, mais que le format ne décrit pas
toutes les métadonnées nécessaires à la gestion d'un réseau. Les informations portées par
FDSN-stationXML sont la partie visible, exportée des métadonnées. Cependant, les travaux du
groupe ont montré la nécessité d'établir la correspondance entre certains éléments publiques
et leur(s) version(s) opérationnelle(s) utilisée(s) dans le processus de gestion des
métadonnées au sein de RESIF (cas des types de capteurs et des types de numériseurs, pour
lesquels nous avons introduit une distinction entre METATYPE et TYPE).
Ce document propose également certaines extensions au modèle FDSN-stationXML,
en fonction des besoins des réseaux et instruments dans RESIF.
Le présent document sera maintenu et révisé périodiquement par les membres du
groupe nomenclature. En particulier, le vocabulaire contrôlé et les différentes listes sont
amenés à évoluer en fonction des évolutions des réseaux, des stations et des canaux au sein
de RESIF.
La périodicité des révisions sera décidée par le groupe.
Les documents stabilisés produits lors des révisions seront placés dans l'espace
documentaire RESIF.
Les documents de travail seront placés dans un espace distinct, accessible aux
membres du groupe.
2 Documents de référence
•
http://www.fdsn.org/xml/station/fdsn-station-1.0.xsd : Base FDSN StationXML schema
•
http://www.fdsn.org/xml/station/Variations-FDSNSXML-SEED.txt An overview of major
variations between SEED 2.4 and FDSN StationXML
6
•
http://www.fdsn.org/seed_manual/SEEDManual_V2.4.pdf : SEED manual
•
http://www.isc.ac.uk/ : Internation Seismological Centre & International Station Registry
•
http://inspire.jrc.ec.europa.eu/ : INSPIRE directive
•
http://www.cnil.fr/ : CNIL
•
http://www.iris.edu/NRL/: IRIS DMC Library of Nominal Responses for Seismic
Instruments
•
http://schema.datacite.org/meta/kernel-3/doc/DataCite-MetadataKernel_v3.0.pdf :
DataCite Metadata Schema for the Publication and Citation of Research Data
•
http://www.resif.fr/org.php : liste des organismes partenaires de RESIF
•
http://www.insu.cnrs.fr/node/1260 : liste des Services d'Observation labellisé en
Sciences de la Terre
3 Structure du document
Le document est composé de deux parties :
1. une partie descriptive : nomenclatureRESIF.version (le présent document)
2. une partie énumérative : nomenclatureRESIFTable.version, qui contient la description
de la structure de données pour les trois niveaux et les tables contenant les listes et le
vocabulaire controlé proposés par le groupe.
Les deux parties sont produites et mises à jour conjointement.
4 But et périmètre de la nomenclature
La nomenclature RESIF est destinée à :
- faciliter l'homogénéisation d'une partie des métadonnées au sein de RESIF. Par exemple, il
est souhaitable que les désignations des fournisseurs de données, les noms des sites, les
noms des instruments, ... soient homogènes au sein du SI.
- faciliter la production de champs textuels dans les fichiers de structure FDSN-stationXML en
7
sortie1 qui soient analysables par un programme informatique2.
- faciliter le recensement de l'existant et de l'historique.
- se mettre en conformité avec les législations française et européenne (CNIL, INSPIRE)
4.1 Caractère pro-actif et non normatif de la nomenclature
Les discussions et réunions de travail autour de la nomenclature RESIF ont mis en
évidence la réticence pour certains réseaux ayant un historique important3 de gérer une mise à
jour rétroactive de leurs métadonnées. On précise que la nomenclature ici présentée est
destinée en priorité aux métadonnées futures, et qu'elle n'est pas normative : il ne sera pas
appliqué de filtre en entrée du noeud B destiné à vérifier la conformité des informations
fournies par les noeuds A avec la nomenclature RESIF. Le groupe recommande cependant
fortement de décrire tous les réseaux, stations et canaux récents ou nouveaux au plus plus
près des usages proposés. Certaines obligations sont par ailleurs légales (CNIL, INSPIRE).
A noter que la mise à jour des métadonnées par les noeuds A se fait selon un rythme
différent de la mise à jour des documents de référence produit par le groupe nomenclature. Par
exemple, la création d'un nouveau Site est concomitante avec l'ajout d'une station dans les
métadonnées transférées par un noeud A vers le noeud B et ne saurait en aucun cas attendre
la mise à jour de la nomenclature dans les documents. En revanche, il est souhaitable que les
gestionnaires
des
métadonnées
dans
les
noeuds
A
adaptent
leur
gestion
aux
recommandations qui figurent dans la nomenclature RESIF.
4.2 Antennes et instruments concernés
La nomenclature concerne les antennes RESIF suivantes :
- antenne large-bande : réseau large bande permanent, réseau large bande du CEA, réseau
LSBB, et réseau permanent de Nouvelle Calédonie,
- antenne accélérométrique : réseau accélérométrique permanent,
réseau permanent de
Nouvelle Calédonie,
1
Par exemple, des outputs du WEBservice : fdsn-station (http://ws.resif.fr/fdsnws/station/1/) ou des outputs de la base de
données GISSMO développée pour la gestion matérielle du réseau RLBP
2
Par exemple, tout programme exécuté par le portail RESIF et destiné à des collections d'informations exploitées par des
interfaces utilisateurs
3
Par exemple, l'antenne SISMOB ne modifiera pas (au moins à court terme) les métadonnées associées aux campagnes
anciennes.
8
- antenne mobile (SISMOB),
- antenne OBS (parc OBS de l'INSU),
- réseau mondial Geoscope,
- réseaux sismologiques des Observatoires Volcanologiques ,
- réseau sismologique de l'Observatoire des Mouvements et Instabilités des Versants.
Remarque : les listes de matériels et de sites présentées dans les différentes tables annexées
ne sont pas exhaustives et seront complétées dans les révisions futures. Ces listes ont été
initialisées avec le contenu des métadonnées présentes au noeud B avant la fin de l'année
2013, date à laquelle les métadonnées des noeuds A Geoscope et Observatoires
Volcanologiques n'étaient pas connues du noeud B. Pour ce qui est de la liste des sites, l'OCA
se propose d'en faire la mise en forme pour tous les réseaux permanents de RESIF, dans la
continuité de l'effort effectué pour celle figurant dans les tables actuelles.
5 Langue d'expression des métadonnées
De façon générale, la langue choisie par RESIF pour l'expression des métadonnées est
l'Anglais, exception faite pour les noms d'instituts ou d'organismes français, les noms de villes
et de sites en France, qui seront exprimés en Français. Tous les commentaires et toutes les
descriptions se feront en Anglais.
6 Proposition de nomenclature
6.1 Niveau Network
On décrit ici tout ce qui concerne le niveau de description Network.
Les feuilles du document nomenclatureRESIFTable concernées par ce niveau sont les
suivantes :
- feuille
networkType : reprend et commente les éléments formels du modèle FDSN
StationXML pour ce niveau. Dans cette feuille, les éléments en vert désignent des éléments
discutés au sein du SI RESIF ; la synthèse des discussions est reportée dans ce paragraphe.
Les éléments en vert souligné correspondent aux éléments pour lesquels une liste d'items est
9
proposée. Les cellules en jaune décrivent des extensions au modèle proposées par le groupe.
- feuille NetworkTable : contient la liste des réseaux RESIF et leurs descriptions à ce jour, avec
les codes (FDSN). Cette table a été validée par la direction de RESIF (janvier 2014). Cette liste
à été initialisée avec le contenu des métadonnées présentes au noeud B en décembre 2013,
elle a été complétée pour les réseaux dont les métadonnées sont gérées par les noeuds A
Geoscope et Observatoires Volcanologiques.
- feuille AgencyTable : contient la liste des noms des organismes, observatoires ou laboratoires
ou des services (au sens très large) en charge des réseaux, des stations et des données au
sein de RESIF. Cette liste a été initialisée en fonction des listes qui figurent sur le site web de
RESIF et sur le site de l'INSU (pour l'énumération des Services d'Observation). Au niveau
Network, la mention d'une Agency ne peut se faire que dans un Comment (cf ci-dessous)
portant sur le réseau. Nous notons qu'il est parfois nécessaire de produire des désignations
combinées (ex : GEOSCOPE, IPGP) dans certains cas. Les règles pour l'expression des
combinaisons et l'ordre d'apparition des items dans la Description doivent être fixés par les
réseaux, mais elles doivent figurer dans les tables maintenues par le groupe. A ce jour, nous
n'avons pas produit de combinaisons. Cette table a été validée par la direction de RESIF
(janvier 2014)
- feuille EmailTable4 : les métadonnées pour RESIF exprimées au format FDSN-StationXML ne
comporteront aucune information nominative, et les adresses de messagerie électronique
seront des adresses génériques. La table EmailTable contient un ensemble de propositions
d'adresses génériques et des propositions d'utilisation de ces adresses. Au niveau Network, la
mention d'un Email ne peut se faire que dans un Comment (cf ci-dessous) portant sur le
réseau. Cette table a été validée par la direction de RESIF (janvier 2014).
6.1.1 Description
La Description d'un réseau se fait en Anglais.
4
10
Il appartient à la direction du SI-RESIF de faire mettre en place l'infrastructure de listes au sein du SI.
6.1.2 Restricted Status
Dans le modèle FDSN-stationXML, des restrictions d'accès aux données peuvent être
posées aux niveaux Network, Station ou Channel. Au sein du SI RESIF, les restrictions d'accès
aux données se feront au niveau du réseau uniquement, et pour les données des réseaux
mobiles seulement. Toutes les autres données RESIF sont publiques.
6.1.3 Comment
0-n Comment peuvent être associé à un réseau. Les Comment peuvent être datés
(date de début et de fin de validité) et peuvent être « signés ». Ils sont rédigés en Anglais.
La signature d'un Comment se compose des éléments suivants :
Name, Agency, Email, Phone number
Name : ne sera pas renseigné dans RESIF
Phone number : ne sera pas renseigné dans RESIF
Email : on utilisera des adresses de messagerie génériques afin de pérenniser la gestion des
noms en s’affranchissant des problèmes avec la CNIL
Remarques :
(1) Contrairement à ce qui est proposé pour les niveaux Station ou Channel, le groupe n'a PAS
défini de liste de Comment ou de consignes de descriptions des commentaires pour le niveau
Network. Quelques suggestions :
- un Comment peut-être fourni pour les réseaux mobiles pour préciser la date à laquelle les
données deviendront publiques.
- un Comment peut-être fourni pour les réseaux mobiles pour préciser le programme de
recherche auquel la campagne de mesure est associée, et les éventuelles collaborations
nationales ou internationales qui ont permis la campagne de mesure.
- un Comment peut-être proposé pour expliquer la composition multi-antennes d'un réseau (au
sens FDSN), par exemple pour expliquer que FR comprend des données accélérométriques et
des données de mouvements de terrain en plus des données large-bande pour certaines
stations.
11
Etc.
(2) Les métadonnées associées au niveau Network sont relativement limitées. Il n'est
cependant pas utile de surcharger ce niveau, car dans un avenir très proche, un D.O.I 5 sera
attaché à chaque réseau, et les métadonnées définies pour la cible permanente de ce D.O.I
sont beaucoup plus riches que ne le sont les possibilités de FDSN-stationXML. Les standards
et consignes pour les métadonnées dans les DOI sont en cours d'étude 6 ; les résultats seront
publics rapidement. Voir à ce sujet le document : DataCite
Metadata Schema for the
Publication and Citation of Research Data (cf §2).
(3) Quelles sont les Agencies et quelles sont les adresses de messagerie à utiliser au niveau
Network ?
- pour ce qui concerne l' Agency : le choix doit être fait par le responsable scientifique du
réseau, ou le PI de la campagne. En ce sens, la liste de la feuille AgencyTable doit être
complétée : elle ne contient à ce jour que les noms des fournisseurs de données pour RESIF
et les noms des Services d'Observation en science de la Terre.
- pour ce qui concerne l'adresse mail signataire d'un Comment de réseau : nous proposons la
définition d'une adresse : FDSN(large)@resif.fr par réseau mobile ou temporaire. Exemple :
[email protected], [email protected], [email protected], etc
- autre schéma proposé : [email protected] (ex : [email protected] ). Ce schéma a
été invalidé par la direction de RESIF (janvier 2014)7
- les réseaux restent bien entendu libres quant au choix de l'adresse normalisée aux différents
niveaux des métadonnées : pour certains, seule l'adresse générale [email protected] sera
utilisée, quel que soit le niveau et le champ, pour d'autres l'usage des adresses plus
spécifiques sera privilégiées.
6.1.4 alternateCode , historicalCode
La balise alternateCode sera utilisée pour désigner (par leur code FDSN) les réseaux
qui co-exploitent des stations (ceci est par exemple le cas pour le réseau GEOSCOPE).
Cette balise peut également être utilisée par les campagnes temporaires SISMOB pour
désigner le réseau par l'acronyme de la campagne (ex : LAPNET, pour XK, ou XK2007)
5
Digital Object Identifier
6
Travail en cours au sein de la FDSN, collaboration entre EIDA et IRIS, livraison : 2014.Q1
7
Ne pas oublier que le niveau Network sera décrit beaucoup plus finement dans les métédonnées DataCite (DOI)
12
La balise historicalCode pourra si besoin être utilisée hors du cadre des codes réseaux
FDSN, pour spécifier si il y a la volonté de le faire les noms historiques des réseaux ('RAP',
'Renass', etc)
6.1.5 Extensions au modèle proposées pour le niveau Network
Une extension a été proposée8 :
digitalObjectIdentifier (string)
contient le DOI attaché au réseau, si il existe. (cf
www.datacite.org)
Cette extension a été acceptée par la FDSN (décembre 2013)
6.2 Niveau Station
On décrit ici tout ce qui concerne le niveau de description Station
suivantes :
- feuille stationType : reprend et commente les éléments formels du modèle FDSN StationXML
pour ce niveau. Dans cette feuille, les éléments en vert désignent des éléments discutés au
sein du SI RESIF ; la synthèse des discussions est reportée dans ce paragraphe. Les éléments
en vert souligné correspondent aux éléments pour lesquels une liste d'item est proposée pour
le SI-RESIF. Les cellules en jaune décrivent des extensions au modèle proposée par le groupe.
- feuille SiteTable : propose une liste des sites (avec leurs attributs) pour les stations de
certains réseaux permaments RESIF. Cette liste a été initialisée à partir des métadonnées
présentes au noeud B en décembre 2013. Elles sera complétée par l'OCA au début 2014 pour
le réseau Geoscope et les réseaux des Observatoires Volcanoligiques.
- feuille EmailTable : propose des adresses de messagerie générique à utiliser pour le niveau
Station (dans la signature des commentaires, et dans la définition des Agencies qui figurent
dans la description des Operators ).
8
13
Ces propositions ont été transmises aux WG FDSN concernés. La demande d'ajoût d'un DOI est validée.
sein de RESIF. Au niveau Station, la mention d'une Agency peut se faire dans un Comment (cf
ci-dessous) de station, ainsi que dans la définition d'un Operator.
- feuille StationCommentTable : propose une liste de commentaires de stations, sur la base de
la standardisation proposée par l'IPGP, complétée par les membres du groupe.
- feuille VaultTable : propose une liste de description pour les 'bâtis' capteur au sein de RESIF.
- feuille GeologyTable : propose une classification des types de sol sur la base de la
classification utilisée par le réseau RAP.
6.2.1 Nom de stations (code)
Les conventions de nommage des (nouvelles) stations permanentes doivent suivre les
règles de nommage qui sont définies par les réseaux.
Remarque :
Veiller à ce que les définitions utilisées dans le cadre de RESIF soient cohérentes avec les
déclarations des stations dans les catalogues internationaux. Selon les choix adoptés par
RESIF, cela passera par une modification et/ou un complément dans le 'station book' maintenu
par l'ISC (International Station Registry)
Les conventions de nommage des stations des réseaux mobiles sont définies par les PI
des campagnes.
6.2.2 alternateCode, historicalCode
A utiliser éventuellement en cas de renommage de station, n'a pas été discuté pour le
niveau Station au sein du groupe.
6.2.3 Description des stations
Deux options de langue sont proposées par le groupe, et devront être tranchées par la
direction de RESIF :
14
(1) Le choix de la langue pour l'expression des Description est laissé aux responsables des
réseaux, en fonction des couvertures de réseaux (ex : Français pour le LB, Anglais pour
GEOSCOPE, langues locales ou Anglais pour SISMOB, etc)
(2) La langue est l' Anglais de tous les cas, et nous ajoutons un champ optionnel pour
l'expression dans la langue locale (+ le code de langue)9.
Remarque : nous pouvons énoncer des Description de Station et des Description de Site (voir
ci-dessous). Y a-t-il des règles à observer pour ces deux types de Description?
6.2.4 Comment
0-n Comment peuvent être associé(s) à une station. Les Comment peuvent être datés
(date de début et de fin) et peuvent être « signés ». Ils sont rédigés en Anglais.
Le groupe propose une liste de
Comment de stations, basée sur le travail
d'uniformisation fait par l'IPGP. A cette liste sont ajoutés des commentaires sur la localisation
des stations particuliers associés aux stations fonds de mer.
Voir la feuille : StationCommentTable
La signature d'un Comment se compose normalement des éléments suivants :
Name : ne sera pas renseigné
Phone number : ne sera pas renseigné
Remarque :
- Au niveau Station, le nom de l' Agency qui signe les Comment devrait être soit le nom de
l'organisme en charge de la maintenance de la station, soit le nom de l'organisme en charge de
la validation des données produites par la station.
L'adresse de messagerie à utiliser devrait être une adresse de types [email protected] ou
9
15
Mais cette possibilité n'est pas définie dans le modèle FDSNStation.XML actuel ; cette modification n'est pas été remontée.
[email protected].
Le but étant que l'utilisateur final puisse contacter via ces adresses des destinataires qui
pourront lui répondre pour tout ce qui concerne cette station ou ses (méta)données.
6.2.5 RestrictedStatus
Il n'y a pas dans RESIF de restriction d'accès au niveau des stations.
6.2.6 Site
Voir la feuille : SiteTable
L'Anglais est préféré (Bejing plutôt que Pékin)
Un site est normalement décrit par les éléments suivants :
Name, Description, Town, County, Region, Country
Pour les stations situées sur sol français : la classification officielle de l'INSEE,
'INSPIRE compatible', sera utilisée.
Name : le nom du site (équivalent ou non – selon les réseaux- au code de la station).
Exemple : 'Musée Dauphinois'. Ce nom peux expliciter le code de la station ou désigner de
façon groupée plusieurs stations installées en proximité.
Description :
Town : le libellé de la classification INSEE est utilisé lorsqu'il est différent du nom du
site. Dans tous les cas, le COG (Code Officiel Géographique) est précisé. Exemple : '38195,
Grenoble'
County : on utilise (quand c'est possible) la notion de subdivision administrative de
3ème niveau (soit département). Exemple: 'Isère'
Region : on utilise (quand c'est possible) la notion de subdivision administrative de
2ème niveau (soit région). Exemple: 'Rhône-Alpes'
Country : Pays. Exemple : 'France'
Nous recommandons d'utiliser les règles et codes INSEE pour toute création de Site
dans les métadonnées transférées au noeud B. Pour les sites à l'étranger : utiliser le code
PAYS fourni par l'INSEE
16
Remarque : en cours de travail, nous avons fait la constatation suivante : pour certains, les
notions de Site et de Station désignent des entités différentes, alors que pour d'autres, toutes
les stations (acquisitions) installées sur le même Site portent nécessairement le même code.
Cette distinction correspond à des pratiques différentes au sein des réseaux, et ces pratiques
doivent être préservées.
Par exemple, pour OMIV (Mouvements de terrain) : le site Avignonet comprend 4 stations dont
les noms sont différents. Pour le LSBB, le site Rustrel comprend plusieurs acquisitions, qui
toutes ont pour nom de code RUSF.
6.2.7 Vault
Voir la table VaultTable
Remarques
(1) il n'est pas à exclure que l'on souhaite différencier les types de Vault par capteurs10 (et pas
seulement par stations) dans certains cas. Le modèle actuel ne le permet pas.
(2) une version ultérieure de cette table devrait permettre de préciser l'environnement du site
(glissements, falaise, volcan, bassin sédimentaire, rocher, en ville, isolé, ..)
6.2.8 Geology
Voir la table GeologyTable
Cette liste est la classification actuellement utilisée par le RAP.
6.2.9 Operator
Un Operator est composé des éléments suivants :
name, Agency, Contact, Website
Voir les tables AgencyTable, EmailTable
10
17
Donc en fait, par 'location code'
- Au niveau Station, le nom de l' Agency qui tient lieu d' Operator devrait être le nom de
l'organisme en charge de la maintenance de la station. L'adresse de messagerie à utiliser
devrait être une adresse de type [email protected]. L'idée est que cette adresse doit
pouvoir être utilisée par exemple par des systèmes de surveillance automatique, qui doivent
pourvoir communiquer avec l'opérateur de la station.
- Website est l'URL du site WEB de l'organisme Agency
6.2.10 Equipment
Si l'information décrite par le type complexe Equipment décrit TOUS les canaux de la
station, alors cette information figure au niveau Station, et non au niveau Channel.
Se reporter à la description d'un Equipment au niveau Channel.
6.2.11 Extensions au modèle proposées pour le niveau Station
Les balises et types suivants supplémentaires sont proposées pour décrire la position
des sismomètres fond de mer11 :
(1) Depth DistanceType. Cet attribut n'est pas présent au niveau station dans le modèle.
(2) Levelling LevellingType::STRING [MOTORIZED,GRAVITY] : attribut obligatoire indiquant
le type de nivellement (si motorisé ou par gravité)
6.3 Niveau Channel
On décrit ici tout ce qui concerne le niveau de description Channel
suivantes :
- feuille
channelType : reprend et commente les éléments formels du modèle FDSN
StationXML pour ce niveau. Dans cette feuille, les éléments en vert désignent des éléments
11
18
Ces extensions ont été transmises au WG FDSN concerné mais n'ont pas encore reçu de réponse.
discutés au sein du SI RESIF ; la synthèse des discussions est reportée dans ce paragraphe.
Les éléments en vert souligné correspondent aux éléments pour lesquels une liste d'item est
proposée pour le SI-RESIF. Les cellules en jaune décrivent des extensions au modèle
proposée par le groupe.
- feuille EmailTable : propose des adresses de messagerie générique à utiliser pour le niveau
Channel (dans la signature des commentaires).
sein de RESIF. Au niveau Channel, la mention d'une Agency ne peut se faire que dans un
Comment .
- feuille SensorTable : contient la liste des types de capteurs proposée par le groupe. Cette
liste contient les colonnes suivantes : Manufacturer, Metatype, Type, Description, Model
La colonne Metatype énumère les intitulés utilisés pour la publication de la métadonnée via les
services FDSN-station (ws.resif.fr), arklink (eida.resif.fr) et netdc ([email protected]). Cette
colonne contient les métadonnées orientées vers l' utilisateur final.
La colonne Type énumère les intitulés qui peuvent être utilisés pour la gestion des
métadonnées au sein de RESIF, par exemple pour le transfert de métadonnées des noeuds A
au noeud B (sous forme dataless ou station.XML), et par les outils de gestion des
métadonnées.
Les règles de ré-écriture (ex : CMG-3T-30-2000 ==> CMG-3T) devront toutes être validées par
le groupe nomenclature.
Cette liste est amenée à évoluer en fonction de l'évolution des matériels RESIF et en fonction
de l'évolution des canaux collectés et diffusés par RESIF (capteurs environnementaux).
Il est important de noter que cette liste (et les Type et Metatype qu'elle comporte) a été
construite de façon à être la plus proche possible du standard 'de facto' que constitue la NRL
maintenue par IRIS, tout en tenant compte de la spécificité de certains matériels utilisés par les
réseaux RESIF.
- feuille DataloggerTable : contient la liste des types de numériseurs proposée par le groupe.
Cette liste est amenée à évoluer en fonction de l'évolution des matériels RESIF.Cette table est
construite sur le même principe que la table SensorTable, et contient en particulier un Type et
un Metatype. De même que lors de la construction de SensorTable, nous avons veiller à rester
au plus près des dénominations de la NRL.
19
- feuille UnitTable : contient la liste des unités de mesure
- feuille StorageTable : contient la liste des formats qui ont fait l'objet d'une description validée
par la FDSN (cf manuel SEED, 196, DDL)
6.3.1 RestrictedStatus
Il n'y a pas dans RESIF de restriction d'accès au niveau des Channel.
6.3.2 Description des Channels
La langue est l' Anglais dans tous les cas.
Remarque : que met-on dans la description d'un Channel? Doit-on standardiser les
descriptions de Channel?
6.3.3 Comment
0-n Comment peuvent être associé(s) à un Channel. Les Comment peuvent être datés
(date de début et de fin) et peuvent être « signés ». Ils sont rédigés en Anglais.
Le groupe propose une liste de
Comment de channels, basée sur le travail
d'uniformisation des commentaires de stations fait par l'IPGP, auxquels s'ajoutent les
commentaires fournis par le RAP.
Voir la feuille : ChannelCommentTable
La signature d'un Comment se compose normalement des éléments suivants :
Name : ne sera pas renseigné
Phone number : ne sera pas renseigné
20
Remarque :
- Au niveau Channel, le nom de l' Agency qui signe les commentaires devrait être le nom de
l'organisme en charge de la validation des données pour ce Channel
L'adresse de messagerie à utiliser devrait être une adresse de [email protected].
Le but étant que l'utilisateur final puisse contacter via ces adresses des destinataires qui
pourront lui répondre pour tout ce qui concerne ce Channel ou ses meta(données)
6.3.4 Equipment (Sensor, Dataloger)
Chaque Equipment doit être décrit par les attributs suivants :
Type, Description, Manufacturer, Model, SerialNumber, InstallationDate, RemovalDate,
CalibrationDate
Le travail du groupe à partir des systèmes de gestions des données locaux aux noeuds
A et l'examen des métadonnées au format SEED dataless fournis par les noeuds A au noeud B
ont montré une forte hétérogénéité dans la manière de nommer les instruments (capteurs,
numériseurs).
Les listes contenant le bilan de l'existant sont contenue dans le document :
nomenclatureRESIFTable.version, feuilles : DataLoggerALL et SensorALL
La mise en commun des listes produites et la synthèse validée par le groupe se trouve
dans les tables : SensorTable et DatalogerTable12
12
Il y a une différence syntaxique et fonctionnelle entre (1) les noms et descriptions des instruments qui figurent dans les
volumes FDSN-stationXML, qui sont destinés à décrire la chaîne d'acquisition pour l'utilisateur des données, étant entendu
que la réponse instrumentale fournie au niveau 'response' peut et doit être aussi spécifique et précise que possible et (2) les
noms ou parties de noms des fichiers informatiques contenant les divers éléments de réponses instrumentales correspondant
à cette chaîne d'acquisition. Les documents nomenclatureRESIF et nomenclatureRESIFTable sont concernés par (1) (colonne
Metatype) et par (2) (colonne Type). Mais il doit être gardé à l'esprit que les structures de données produites et échangées
au sein du SI RESIF pour la gestion des métadonnées (typiquement, de GISSMO à PHOENIX par exemple) doivent comporter
les éléments permettant d'inférer (2) à partir de (1). Parmi ces éléments, on peut mentionner (non exhaustif) dans le cas des
capteurs : la période, la fréquence, la sensibilité, la pleine échelle, le niveau de coupure, etc... .Notons que dans la plupart des
cas, le code du canal (qui contient la composante,le numéro de série et les dates d'ouverture/fermeture de canaux associées
au type permettent d'identifier de façon univoque la ressource contenant la description de la réponse de l'intrument.
21
6.3.5 Serial Number
Il
est
demandé
de
spécifier
les
numéros
de
série
tels
que
fournis
par le constructeur, sans rien enlever ni interpréter, enfin d' éviter des problèmes dus aux
évolutions par les constructeurs de leurs propres nomenclatures.
6.3.6 Extensions demandées
WaterDepth : element : distanceType: 0..1
Water depth, mandatory for OBS position description
PostDecimation : element : string : 0..*
Materiel element for postdecimation
Clock : element : string : 0..*
Clock type
Ces demandes ont été portées au WG de la FDSN en charge de la définition des
standards pour les métadonnées, mais nous n'avons pas eu de réponse à ce jour.
L'élément PostDecimation est indispensable pour rendre compte de façon satisfaisante de la
réponse de certaines chaînes d'acquisition présentes dans RESIF13.
6.3.7 Autres éléments de description des canaux (non encore analysés par le
groupe de travail)
Pour rappel, la structure FDSN-stationXML comporte pour le niveau Channel
les
éléments descriptifs suivants :
13
Cas des combinaisons entre numériseurs TITAN et stations MYKERINOS, que nous n'avons pas décrit de façon satisfaisante
à ce jour.
22
<xs:element name="CalibrationUnits" type="fsx:UnitsType"
minOccurs="0"/><xs:element name="Sensor" type="fsx:EquipmentType"
minOccurs="0"/><xs:element name="PreAmplifier" type="fsx:EquipmentType"
minOccurs="0"/><xs:element name="DataLogger" type="fsx:EquipmentType"
minOccurs="0"/><xs:element name="Equipment" type="fsx:EquipmentType"
minOccurs="0"/><xs:element name="Response" type="fsx:ResponseType"
minOccurs="0"/>
Le groupe n'a pas encore analysé l'élément : PreAmplifier14, ni proposé d'utilisation de
l'élément Equipment.
L'élément Response ne fait pas partie du présent document.
14
Cet élément est présent dans la base de données GISSMO et dans le logiciel PHOENIX,, ainsi que dans les systèmes de
gestion de données utilisés par les noeuds A RAP et SISMOB.
23

Nomenclature pour les métadonnées sismologiques des niveaux

Transcription

Documents pareils

Voir la une

Exclure les stations de ski de la défiscalisation dans les Zones de

stations d`epuration a disques biologiques

11. 2000-2010, une décennie de développement des stations ZRR

Plan Hôtel Pershing Hall

Annexe 1 Montagne et neigex - Auvergne - Rhône

Les ventes de chalets et appartements à la montagne ont chuté. Les

Plan des pistes - Les Stations de la Drôme