Portail WEB RESIF Cahier des charges fonctionnel · 1 Portail WEB RESIF - Cahier des charges fonctionnel ! InstitutdePhysiqueduGlobedeParis ’ 1,#rue#Jussieu75238Paris#cedex#05 Paris,#le#4#Avril2013

1

Portail WEB RESIF -

Cahier des charges fonctionnel

Institut de Physique du Globe de Paris 1, rue Jussieu 75238 Paris cedex 05

Paris, le 4 Avril 2013

Version 2.0

2

3

Historique des modifications

Date Version Description Auteurs

30/11/2012 1.0 Document initial IPGP : V. Douet, C. Pardo, N. Shapiro

04/04/2013

2.0

Intégration des remarques faites sur la première version du cahier des charges

IPGP : V. Douet, N. Shapiro

4

SOMMAIRE

1 Présentation du document.................................................................................................... 6 1.1 But du document.............................................................................................................................6 1.2 Les interlocuteurs ..........................................................................................................................6 1.3 Le produit portail web ..................................................................................................................7

2 Objectifs du projet ................................................................................................................... 7 2.1 Objectif du portail web RESIF .....................................................................................................7 2.2 Tour d’horizon des portails d’accès aux données sismologiques existants ...............7 2.3 Public visé .........................................................................................................................................8

3 Arborescence du portail web RESIF................................................................................... 8 4 Charte graphique...................................................................................................................... 9 5 Spécifications fonctionnelles ............................................................................................ 10 5.1 Contenu et interfaces.................................................................................................................. 10 5.2 Langues supportées .................................................................................................................... 10 5.3 L’aide en ligne et F.A.Q. .............................................................................................................. 11 5.4 Afficher la page d’accueil.......................................................................................................... 11 5.5 Afficher les actualités ................................................................................................................. 12 5.6 Afficher la description du système d’information RESIF ............................................... 13 5.7 Afficher les descriptions des OSU et des partenaires fournisseurs de données .... 13 5.8 Afficher les descriptions des réseaux .................................................................................. 15 5.9 Visualiser les stations ................................................................................................................ 16 5.10 SeismiQuery RESIF.................................................................................................................... 18 5.10.1 Visualiser l’inventaire des stations .............................................................................................18 5.10.2 Visualiser l’inventaire des données .............................................................................................20

5.11 Accéder aux données ............................................................................................................... 21 5.11.1 Accéder aux données par évènements .......................................................................................22 5.11.2 Accéder aux données pour une période donnée....................................................................25 5.11.3 Accéder aux données temps réel ..................................................................................................28 5.11.4 Accéder aux données accéléromètriques..................................................................................29 5.11.5 Accéder aux données par d’autres moyens..............................................................................31 5.11.6 Afficher les citations ...........................................................................................................................32 5.11.7 Demander l’accès aux données restreintes ..............................................................................33

5.12 Afficher la sismicité .................................................................................................................. 34 5.12.1 Afficher la sismicité des différents catalogues sur une carte ...........................................34 5.12.2 Afficher les séismes d’un intérêt particulier ............................................................................35

5.13 Présenter des outils, logiciels, librairies permettant de manipuler les données RESIF 36 5.14 Présenter les modalités de contact aux utilisateurs ..................................................... 37 5.14.1 Récolter l’avis des utilisateurs .......................................................................................................37 5.14.2 Récupérer les questions des utilisateurs...................................................................................38 5.14.3 Afficher les informations sur les contacts RESIF ...................................................................38

5.15 Afficher l’aide en ligne et les FAQ (« Frequently asked questions »)....................... 39 5.16 Afficher les mentions légales ................................................................................................ 40

5

5.17 Afficher le plan du site............................................................................................................. 40 5.18 Rechercher des informations sur le site ........................................................................... 41 5.19 Administrer le site .................................................................................................................... 42

5.19.1 Afficher le formulaire de connexion à la partie « Administration » ....................................42 5.19.2 Afficher les statistiques du portail web .....................................................................................43 5.19.3 Afficher les statistiques des données distribuées..................................................................44 5.19.4 Afficher les « retours » et les questions des utilisateurs ....................................................45 5.19.5 Gérer les contenus du portail web ...............................................................................................46 5.19.6 Gérer les utilisateurs de la partie « Administration » ..........................................................47 5.19.7 Sauvegarder et restaurer le portail en production ...............................................................47

6 Architecture du portail........................................................................................................ 49 6.1 Architecture logicielle................................................................................................................ 49 6.2 Architecture web ......................................................................................................................... 50 6.3 Liste des « web services » à mettre en place au nœud B ................................................ 50 6.4 Développement de la « couche logicielle d’abstraction » .............................................. 53 6.5 Conformité aux standards ........................................................................................................ 53 6.6 Nom de domaine et hébergement .......................................................................................... 54 6.6.1 Nom de domaine.....................................................................................................................................54 6.6.2 Hébergement............................................................................................................................................54

7 Equipe technique et planning de réalisation............................................................... 55 8 Glossaire................................................................................................................................... 61 9 Annexes .................................................................................................................................... 63 9.1 Annexe 1 : Réponse point par point aux remarques sur la version 1.0 du cahier des charges du portail RESIF .............................................................................................................. 63 9.2 Annexe 2 : Réponses au questionnaire concernant le document sur les besoins du portail ......................................................................................................................................................... 91

6

1 Présentation du document

Le projet RESIF-‐SI dans son ensemble développe un système d'Information réparti pour les données du TGIR RESIF composé de « nœuds A » pour la collecte et la validation des données, d’un « nœud B » pour l’archivage, et d’un portail web pour la distribution de ces données « RESIF ».

1.1 But du document

Basé sur le document « Document de Spécification de Besoins pour le portail web » et sur les deux réponses reçues via le questionnaire qui a été mis en place sur le site web RESIF actuel pour recenser les besoins des futurs utilisateurs (voir Annexe 1 page 91), ce document décrit en détail les fonctionnalités de la première version du portail web RESIF.

Ce document permettra, une fois validé par le comité de pilotage (COPIL), de démarrer les spécifications techniques et le développement de chaque composant du portail RESIF. Un composant du système portail web RESIF est une unité de composition logicielle pouvant être produite et déployée séparément.

Référence :

Le document de spécification de besoins pour le portail web « RES-‐CSI-‐TEC-‐SR-‐002-‐PortailWeb-‐v1.0.pdf » est disponible sur le site de la DT INSU : https://resif.dt.insu.cnrs.fr/fileviewer.php?file_id=258

1.2 Les interlocuteurs

La réalisation du portail web RESIF devra se faire en concertation avec plusieurs interlocuteurs.

Le développement du portail web se fera en lien étroit avec le COPIL de RESIF-‐SI (Système d’Information RESIF), le « nœud B », les différents « nœuds A », ainsi qu’avec des interlocuteurs extérieurs au projet «RESIF » tel IRIS, ORFEUS et le CSEM et ceux désignés par le comité de pilotage de RESIF-‐SI.

7

1.3 Le produit portail web

Le produit portail web RESIF comprendra :

-‐ les codes sources

-‐ la documentation technique

-‐ la documentation utilisateur

-‐ une version de production

-‐ une version de développement

-‐ les procédures de restauration et de sauvegarde

2 Objectifs du projet 2.1 Objectif du portail web RESIF

L’objectif principal du portail web RESIF est de faciliter l’accès aux données sismologiques « RESIF » hébergées au nœud B en proposant un ensemble de fonctionnalités et d’outils aux utilisateurs.

Dans cette première version le portail web se limitera aux données sismologiques des réseaux RESIF.

2.2 Tour d’horizon des portails d’accès aux données sismologiques existants

Voici une liste des principaux « portails » d’accès aux données sismologiques déjà existants. Cette liste n’est bien sûr pas exhaustive.

• Le portail mondial IRIS : http://www.iris.edu • Le portail Européen NERIES : http://www.seismicportal.eu/jetspeed/portal/

• Le portail WebDC de GFZ permettant de récupérer les données des nœuds européens EIDA : http://www.webdc.eu/

• Le portail français Fosfore : http://www.fosfore.ipgp.fr/portal

• Le portail du réseau GEOSCOPE : http://geoscope.ipgp.fr • Le portail d’accès aux données du RAP : http://bdsis.obs.ujf-‐grenoble.fr/

8

2.3 Public visé Le portail web RESIF s’adresse à quatre groupes principaux d’utilisateurs :

1. Les scientifiques

2. Le TGIR RESIF

3. Des centres de données et des centres de détection/alerte de séismes

4. Les utilisateurs divers (passionnés, curieux,...)

3 Arborescence du portail web RESIF

Présentation du bandeau du portail web :

• Le logo RESIF et Portail • Icône de retour à l’accueil • Rubrique recherche

• Langues supportées • Aide & FAQ

Présentation de l’arborescence des menus en entête de page :

• Le système d’information RESIF o Schéma général

o Descriptif des données RESIF • Les Observatoires de Sciences de l’Univers et Partenaires • Réseaux

o Les réseaux permanents o Les réseaux temporaires o Les réseaux virtuels

• Stations • « SeismiQuery » RESIF • Accès aux données

o Accès aux données "évènements" o Accès aux données continues o Accès aux données temps-‐réel

o Accès aux données accélérometriques o Autres moyens d'accès aux données :

-‐ Les Webservices -‐ Le protocole « Arclink »

o Citations o Demande d’autorisation d’accès aux données restreintes

9

• Sismicité

o Cartes de sismicité o Séismes d’un intérêt particulier

• Outils, logiciels, librairies

Présentation de l’arborescence des menus en pied de page :

• Mentions légales • Plan du site

• Nous contacter o Retour des utilisateurs o Nous poser de questions

o Qui contacter • Administration du site

4 Charte graphique

La charte graphique du portail web RESIF s’inspirera de celle déjà utilisée dans le site web RESIF actuel. Cependant des évolutions et des adaptations seront nécessaires.

Squelette proposé pour la page d’accueil :

10

5 Spécifications fonctionnelles

5.1 Contenu et interfaces Dans sa majeure partie le portail web RESIF sera ouvert à tous, il ne sera pas demandé aux utilisateurs de s’identifier pour consulter le portail web et récupérer des données publiques. Cependant les données de certains réseaux sont en accès restreint, il sera alors demandé aux utilisateurs autorisés voulant récupérer ces données de s’identifier (par adresse email et mot de passe).

Certains contenus du portail comme les actualités, les descriptions des réseaux, les descriptions des types de données, etc. seront gérés par un CMS (Système de gestion de contenu) avec le COPIL du RESIF-‐SI comme modérateur (ou représentants désignés par le COPIL).

Une partie administration du portail web avec accès restreint permettra aux utilisateurs autorisés, et en fonction des droits qui leurs sont donnés, d’administrer certaines parties du portail web en éditant leur contenu, ainsi que d’accéder au statistiques du portail web et des données « RESIF ».

Pour toutes les pages de type « documentation » ou « article » le portail proposera d’exporter ces pages au format PDF afin de faciliter l’impression et la consultation de ces informations.

Dans cette partie du document nous décrivons les fonctionnalités du portail d’accès aux données, dans sa première version. La présentation de chaque fonctionnalité est accompagnée d’un tableau synthétisant les informations importantes ainsi que d’une description détaillée.

5.2 Langues supportées Le portail web RESIF sera proposé aux utilisateurs en Français et en Anglais, tous les textes et contenus du portail web seront disponibles dans ces deux langues.

Le portail sera conçu de telle manière que l’ajout d’une langue supplémentaire sera facilement intégrable si un jour cela s’avère utile.

11

5.3 L’aide en ligne et F.A.Q. Le portail web RESIF proposera une fonctionnalité regroupant les aides des différentes fonctionnalités du portail web. Cette fonctionnalité sera accessible depuis le menu « Aide & FAQ» situé dans le bandeau. De plus dans chaque fonctionnalité du portail un bouton « Aide » apportera un accès direct à l’aide correspondante à cette fonctionnalité.

Dans l’aide proposée une partie sera dédiée au F.A.Q. (« Frequently Asked Questions »). Cette partie présentera les réponses aux questions les plus fréquemment posées par les utilisateurs.

5.4 Afficher la page d’accueil Toutes les pages du portail web contiendront un entête de page et un pied de page identiques.

• Dans l’entête de page on retrouvera l’accès aux différents menus, la fonctionnalité de recherche d’informations dans le portail web, un lien vers l’aide en ligne et les FAQ, ainsi que des liens permettant de choisir la langue (Anglais ou Français).

• Dans le pied de page on trouvera un accès vers la fonctionnalité « Nous contacter », un accès vers le plan du site, un accès à la page des mentions légales du site, ainsi qu’un lien vers la fonctionnalité d’administration du portail web RESIF.

• Dans le corps de la page d’accueil on retrouvera une brève description du portail web RESIF avec un court descriptif des fonctionnalités importantes, la liste des cinq dernières actualités liées au portail web RESIF (ainsi qu’un lien vers la fonctionnalité contenant toutes les actualités), et les cinq derniers séismes d’un intérêt particulier.

12

5.5 Afficher les actualités

Tableau présentant la fonctionnalité :

Sujet Description

Intitulé Afficher les actualités du portail RESIF

Objectif L’objectif est de tenir au courant les utilisateurs des informations importantes concernant les données RESIF et le portail web RESIF.

Courte description Le portail RESIF présentera des actualités concernant les données, les stations, les réseaux, les fonctionnalités du portail, etc.

Provenance des informations et données

Les actualités mises en ligne sur le portail devront être validées par le COPIL. Il est du devoir des responsables (ou personnes désignées par le COPIL) du « nœud B », des « nœuds A », du portail et du COPIL de proposer les actualités.

Accès Cette fonctionnalité sera accessible depuis la page d’accueil qui présentera un lien vers toutes les actualités. Sur la page d’accueil seront présentées les 5 dernières actualités.

Description détaillée de la fonctionnalité

Le portail web RESIF présentera les actualités qui ont un lien direct avec le portail web RESIF.

Les actualités concernant les fonctionnalités du portail (nouvelle fonctionnalité disponible, nouveau web service, nouveau software disponible ou problème de maintenance de serveur web, etc.) et les actualités concernant les données disponibles (nouvelles données disponibles, ajout d’un réseau, ajout d’une station, problème d’accès à certaines données etc.). Les actualités liées au TGIR RESIF en lui-‐même sont disponibles sur le site web RESIF (http://www.resif.fr)

Une actualité sera composée, d’un titre, d’une date de mise en ligne, d’un auteur, et du texte de l’actualité.

Un flux RSS (voir glossaire page 61) des actualités sera mis en place.

Les actualités seront gérées avec un CMS via la rubrique « Administration du site ». Les personnes autorisées à gérer les actualités (ajout / modification / suppression) seront :

-‐ Un ou deux représentants du portail web

-‐ Un ou deux représentants du nœud B

13

-‐ Un ou deux représentants des nœuds A

-‐ Un ou deux représentants du COPIL

5.6 Afficher la description du système d’information RESIF Tableau présentant la fonctionnalité :

Sujet Description

Intitulé Afficher la description du système d’information RESIF

Objectif L’objectif est de présenter le schéma général du système d’information distribué RESIF et la description des données gérées par ce système.

Courte description Cette fonctionnalité comprendra : -‐ La description du système d’information distribué RESIF composé d’un centre de données unique et des centres de collecte et validation de données. -‐ La description des types données gérées par ce système d’information. -‐ La description de la notion validation des données


Ce contenu sera statique et sera géré dans la partie « Administration du site »

Accès Cette fonctionnalité sera accessible depuis le menu « Le système d’information RESIF ».


Cette fonctionnalité devra présenter le schéma général du Système d’Information RESIF en décrivant particulièrement les fonctions des différents nœuds ainsi que les liens avec les centres opérationnels.

De plus cette fonctionnalité décrira l’ensemble des types de données RESIF ainsi que les différents formats d’échange.

5.7 Afficher les descriptions des OSU et des partenaires fournisseurs de données

Cette fonctionnalité affichera la description des Observatoires de Sciences de l’Univers et des différents partenaires liés à RESIF.

14


Sujet Description

Intitulé Afficher la description des OSU et des partenaires

Objectif L’objectif est de présenter les différents OSU et partenaires pourvoyeurs de données RESIF et de faire connaître leurs rôles au sein de RESIF.

Courte description Une page présentera la liste des OSU et partenaires, et pour chaque entité on retrouvera un descriptif, la liste des réseaux gérés par cette entité, les personnes à contacter, etc.


Chaque OSU ou partenaire aura un accès dans la partie « Administration » lui permettant de gérer ses informations.

Accès Cette fonctionnalité sera accessible depuis le menu « Les OSU et partenaires» du portail web RESIF.


Une page présentera la liste des OSU et des partenaires, en cliquant sur le nom de l’entité le descriptif apparaitra sur cette même page.

Pour chaque entité on retrouvera au minimum les informations suivantes :

• Le descriptif de celle-‐ci.

• La liste des réseaux et stations gérés par l’entité (avec un lien pour chaque réseau vers la page de description du réseau).

Remarque : il faudra bien faire la distinction entre les organismes responsables du fonctionnement d’un réseau et les organismes opérateurs d’un ensemble de stations pour le compte d’un ou plusieurs réseaux.

• Les personnes pouvant être contactées

• Un lien vers le site web de l’entité

• La date de mise à jour de ces informations.

15

Les descriptions des OSU et des partenaires seront gérées avec un CMS (voir glossaire). Chaque OSU ou partenaire sera responsable des informations qui seront présentées. Les personnes autorisées à gérer ces informations (ajout / modification / suppression) seront :

• Un ou deux représentants de chaque OSU ou partenaire

• Un ou deux représentants du portail web

• Un ou deux représentants du COPIL

5.8 Afficher les descriptions des réseaux

Sujet Description

Intitulé Afficher la description des réseaux

Objectif L’objectif est de présenter le but scientifique des réseaux (permanents, temporaires, virtuels), et de présenter les personnes responsables ou à contacter pour ce réseau.

Courte description Trois pages présenteront la liste des réseaux disponibles. Une page sera consacrée aux réseaux permanents, une autre aux réseaux temporaires, et une autre aux réseaux virtuels.


Chaque OSU ou partenaire aura un accès à une interface pour gérer les informations sur les réseaux dont il a la charge.

Accès Cette fonctionnalité sera accessible depuis les menus « Réseaux / Réseaux permanents», « Réseaux / Réseaux temporaires» et « Réseaux / Réseaux virtuels» du portail web RESIF.


Trois pages présenteront la liste des réseaux disponibles. Une page sera consacrée aux réseaux permanents, une autre aux réseaux temporaires et une autre aux réseaux virtuels.

Un réseau virtuel est un groupe de stations ayant une affiliation qui va au delà d’une affiliation classique à un réseau. On peut utiliser cette notion de réseau virtuel pour définir un sous-‐ensemble d’un réseau existant. Exemple pour le réseau RAP on utilisera cette notion de réseau virtuel pour les sous-‐réseaux RAP-‐LGIT, RAP-‐BRGM, etc.

On peut aussi utiliser cette notion de réseau virtuel lors d’un projet ou d’une initiative particulière en sélectionnant des stations de réseaux différents afin d’établir un nouveau réseau avec un ensemble de stations correspondants au besoin du projet.

Sur chaque page on retrouvera la liste des réseaux et en cliquant sur le nom du réseau le descriptif complet de celui-‐ci apparaitra sur cette même page.

Pour chaque réseau on retrouvera au minimum les informations suivantes :

16

• Présentation générale du réseau

• Les objectifs scientifiques du réseau

• Les responsables du réseau

• Des personnes à contacter pour avoir de plus amples informations sur ce réseau

• La date de mise à jour de ces informations.

Les descriptions des réseaux seront gérées avec un CMS. Chaque OSU ou partenaire sera responsable des informations des réseaux qu’il gère. Les personnes autorisées à gérer ces informations (ajout / modification / suppression) seront :

-‐ Un ou deux représentant de chaque OSU ou partenaire

-‐ Un ou deux représentant du portail web

5.9 Visualiser les stations

Sujet Description

Intitulé Afficher les réseaux des stations RESIF

Objectif L’objectif de cette fonctionnalité est de présenter de manière conviviale les réseaux et leurs stations dans une carte type « Google Maps » et dans un tableau.

Courte description Une page web présentera une zone de sélection comportant différents critères afin d’afficher les stations correspondantes sur une carte ou sous forme de liste dans un tableau, au choix.

Une fois cette sélection effectuée l’utilisateur pourra « cliquer » sur les stations afin d’obtenir pour chacune d’elle une « Fiche descriptive de la station » comportant de nombreuses informations.


Ces informations sur les stations proviennent des bases de données implantées au « nœud B » et seront accessibles via des « web services » déployés au « nœud B ».

Accès Cette fonctionnalité sera accessible depuis le menu « Stations» du portail web RESIF.

17


Une page web présentera une zone de sélection comportant différents critères afin d’afficher les stations correspondantes sur une carte ou sous forme de liste dans un tableau. Les critères de sélection des stations seront les suivants :

-‐ Sélection par type de réseau : permanent, temporaire, virtuel

-‐ Sélection d’un ou plusieurs réseaux

-‐ Type de station : sismologie, accéléromètrie, GPS, etc.

-‐ Statut de la station : en fonctionnement, arrêtée, prévue (si le « nœud B » peut fournir cette dernière information

-‐ Par région (latitude, longitude)

Une fois cette sélection effectuée les stations correspondantes seront affichées sur une carte ou dans un tableau. L’utilisateur pourra « cliquer » sur les stations afin d’obtenir pour chacune d’elles une « Fiche descriptive de la station ».

Cette « fiche descriptive » sera composée de plusieurs onglets :

• Un onglet « Description »

Dans cet onglet on retrouvera les informations suivantes :

Nom de la station, code, réseau, type de la station, statut de la station, OSU(s) en charge de la station, localisation (région, lieu, pays), latitude, longitude, élévation, commentaires, photos, cartes.

• Un onglet « Information sur le site » fournira des informations sur le site de la station (description précise du site, classe du site (A+, A, B etc..), cartes géologiques, informations spécifiques pour les stations accéléromètriques, etc.)

• Un onglet « Acquisitions» présentera la liste des acquisitions configurées en station par période (opérationnelles, arrêtées). Pour chaque acquisition sera présenté le « Location Code » associé, la liste d’instruments (capteurs, numériseurs avec si possible leurs numéros de séries) et la description des canaux. Pour chaque canal on affichera les graphiques des réponses instrumentales de celui-‐ci et on permettra à l’utilisateur de récupérer des fichiers tels que les « RESP FILES » ou les fichiers de « Pôles et Zéros » (SAC).

• Un onglet « Continuité des données » présentera des graphiques de continuité des données validées et archivées de la station par année.

• Un onglet « Courbes de bruit » présentera des graphiques telles que les courbes de bruit, les spectres, etc. de la station.

Un bouton « Exporter en format PDF » sera proposé afin de pouvoir distribuer et imprimer facilement la « Fiche descriptive » complète de la station au format PDF.

Depuis cette interface il sera aussi possible de récupérer le fichier StationXML ainsi que le fichier DATALESS SEED de la station.

18

5.10 SeismiQuery RESIF

Sujet Description

Intitulé SeismiQuery : Visualiser les métadonnées et l’inventaire de données validées archivées au nœud B.

Objectif L’objectif de cette fonctionnalité est fournir une vue sur les informations relatives aux réseaux, stations, canaux, inventaire de données validées archivées selon différents critères de sélection.

Courte description Avec cette interface, l’utilisateur pourra faire de requêtes soit sur les métadonnées du point de vue des stations, soit du point de vue de l’inventaire de données.


Ces informations sur les métadonnées proviennent des bases de données du « nœud B » et seront accessibles via des « web services » déployés au « Nœud B ».

Accès Cette fonctionnalité sera accessible depuis le menu « SeismiQuery RESIF » du portail web RESIF.


Cette fonctionnalité est basée sur les fonctionnalités proposées par l’interface SeismiQuery de IRIS-‐DMC.

Cette fonctionnalité se décomposera en 2 composantes:

5.10.1 Visualiser l’inventaire des stations Cette interface se présentera sous forme d’un formulaire permettant à l’utilisateur d’inventorier les stations et leurs configurations correspondant à différents critères.

Les critères de recherches des stations seront :

-‐ Code réseau

-‐ Code station

-‐ Période (date de début -‐ date de fin)

-‐ Statut de la station

-‐ Région (latitude minimum, latitude max, longitude min, longitude max)

-‐ Type de sol

-‐ Classe de sol

-‐ Critère sur « Champ libre »

-‐ Critère sur le type de la station : « En forage » ou « en bâtiment »

19

En plus, l’utilisateur pourra ajouter des critères sur les canaux :

-‐ « Location code »

-‐ Canal

-‐ Pas d’échantillonnage

-‐ Capteur (type ou modèle)

Au minimum un des critères suivants devra être spécifié: réseau, station, période (ou statut de la station), capteur.

Avant de valider sa recherche, l’utilisateur précisera les informations qu’il souhaitera voir s’afficher à l ‘écran.

L’utilisateur pourra sélectionner les informations suivantes:

-‐ Code réseau

-‐ Code station

-‐ Nom du site de la station

-‐ Latitude de la station

-‐ Longitude de la station

-‐ Elévation de la station

-‐ Type de sol

-‐ Classe de sol

-‐ Critère sur « Champ libre »


-‐ Date de début de la station

-‐ Date de fin de la station

-‐ « Location code » -‐ Canal

-‐ Date de début du canal

-‐ Date de fin du canal

-‐ Pas d’échantillonnage

-‐ Capteur

-‐ Latitude – Longitude du canal

-‐ Élévation

-‐ Profondeur

-‐ Azimut, Dip

20

Exemple :

Il sera possible d’exporter la liste des résultats obtenus au format ASCII.

5.10.2 Visualiser l’inventaire des données


Cette interface proposera 2 visualisations possibles :

1. Une visualisation « simple », avec un minimum de critères permettant rapidement à l’utilisateur de connaître les données disponibles pour un réseau ou une station donnée pour une période.

Pour cela l’utilisateur sélectionnera d’abord un réseau, une station (facultatif), puis une année. Un calendrier est alors affiché représentant les jours de l’année où il y a des données. Une barre de navigation permettra d’afficher les autres années.

En cliquant sur un jour donné, un tableau affichera les données disponibles par canal. Le tableau présentera les informations suivantes : Réseau, Station, « Location code », Canal, Date de début et Date de fin des données.

21

2. Une visualisation « enrichie », permettant d’afficher les données disponibles en fonction de nombreux critères :

• Réseau

• Station • Location code

• Canal • Période (date et heure de début, date et heure de fin) • Région (latitude minimum, latitude max, longitude min, longitude max)

• Pas d’échantillonnage • Capteur (par type ou modèle) • Elévation (min et max)

• Profondeur (min et max) • Azimut (min et max) • Dip (min et max)

• Type de sol • Classe de sol • Critère sur « Champ libre »

• Critère sur le type de la station : « En forage » ou « en bâtiment » • Critère sur les données : déclenchées ou continues

Au minimum les critères suivants devront être renseignés : réseau et période.

Remarque : D’autres critères pourraient être obligatoires afin de limiter la taille des requêtes à exécuter au « nœud B » (A voir avec le « Nœud B »).

Une fois la recherche effectuée le portail web affichera un tableau ainsi qu’un graphique représentant les données disponibles par canal pour cette période.

Le tableau présentera les informations suivantes : Réseau, Station, « Location code », Canal, Date de début et Date de fin des données.

Lorsqu’il y aura une absence de données les commentaires de la station et/ou des canaux seront affichés pour la période donnée.

Il sera possible d’exporter la liste des résultats obtenus au format ASCII.

5.11 Accéder aux données

Plusieurs fonctionnalités d’accès aux données seront proposées :

• Accès aux données par "évènements" • Accès aux données par période

• Accès aux données temps-‐réel • Accès aux données accélérometriques • Autres moyens d'accès aux données :

o Webservices o Protocol « arclink »

22

5.11.1 Accéder aux données par évènements


Sujet Description

Intitulé Accéder rapidement aux données par évènements grâce à une interface conviviale.

Objectif L’objectif est de fournir aux utilisateurs une interface conviviale permettant de récupérer facilement les données d’un ou plusieurs évènements selon de nombreux critères.

Courte description Cette fonctionnalité permettra aux utilisateurs de récupérer des données d’un ou plusieurs évènements. Plusieurs formats de données et métadonnées seront disponibles : miniSEED, Full SEED, SAC, ASCII, Dataless SEED, StationXML, XML Inventory.


Les données et informations de cette interface proviennent du nœud B via les web services déployés au nœud B.

Accès Cette fonctionnalité sera accessible depuis le menu « Accès aux données / Accès aux données par évènements»


Cette fonctionnalité s’inspire de fonctionnalités déjà existantes dans d’autres centres de données. Elle comprend trois étapes :

-‐ La première étape qui permet à l’utilisateur soit de sélectionner le ou les évènements dont il souhaite récupérer les données

-‐ Une deuxième étape permettant à l’utilisateur de sélectionner les stations dont il souhaite récupérer les données

-‐ Une troisième étape permettant à l’utilisateur de vérifier et d’affiner sa requête, de choisir le format des données, et le moyen qu’il souhaite utiliser pour les récupérer.

23

1. Première étape : Sélection des évènements La fonctionnalité permettra d’afficher sur une carte et dans un tableau les évènements recherchés. Les critères de recherche à la disposition de l’utilisateur sont les suivants :

-‐ Choix du catalogue

-‐ Magnitude min et magnitude max -‐ Le type de magnitude -‐ La région (latitude min et max et longitude min et max)

-‐ La profondeur min et la profondeur max -‐ Une période, date de début et date de fin

-‐ Type d’événement (séisme, tir de carrière, avalanche, etc..)

Une fois les évènements correspondant à la recherche afficher sur une carte et dans un tableau, l’utilisateur sélectionnera le ou les évènements de son choix. Pour chaque évènement il sera proposé un lien vers le format « QuakeML » de l’événement ainsi qu’un lien vers la page de cet événement sur le site du catalogue correspondant (si cette page existe). Il sera possible d’exporter la liste des évènements sélectionnés au format ASCII. Une fois cette étape réalisée, l’utilisateur pourra compléter sa requête en sélectionnant les stations pour lesquels il veut récupérer les données. Remarque : Cette fonctionnalité n’a pas pour objectif de distribuer des catalogues de sismicité. Pour cette fonctionnalité, l’objectif est de présenter les évènements aux utilisateurs afin qu’ils récupèrent les données liés à ces évènements. Pour chaque événement affiché un lien redirigeant vers l’évènement sur le site de l’organisme propriétaire du catalogue sera proposé.

2. Deuxième étape : Sélection des stations Pour cela les critères de recherches permettant d’afficher les stations sur une carte et dans un tableau seront les suivants :

-‐ Types de réseaux (permanent, temporaires, virtuels) -‐ Réseau -‐ Station

-‐ Type de capteur -‐ « Location code » -‐ Canal

-‐ Localisation (Latitude min et max, Longitude min et max) -‐ Distance épicentrale min et max

24

Une fois les stations correspondant à la recherche affichées sur une carte et dans un tableau, l’utilisateur sélectionnera le ou les stations dont il souhaite récupérer les données. Sur la carte et dans le tableau n’apparaitront que les stations ayant des données pour les critères sélectionnés. En cliquant sur une station l’utilisateur pourra consulter la « Fiche descriptive » de la station (cf « 5.9 Visualiser les stations »). Remarque : Les stations des réseaux en accès restreint apparaitront sur la carte et dans le tableau de manière différente des stations en accès ouvert. Par exemple une image représentant un petit cadenas pour être attaché au nom ou à l’icône de la station. Une fois cette étape réalisée, l’utilisateur pourra visualiser et affiner sa requête. 3. Troisième étape : Vérifier et affiner la requête Une fois la sélection des stations effectuée, l’utilisateur peut donc vérifier et affiner la requête qu’il souhaite soumettre. Une page s’ouvrira en rappelant dans un tableau le détail de la requête demandée. La requête sera décomposée en sous requêtes (jusqu’au niveau du canal). On retrouvera donc pour chaque sous requête les informations suivantes : réseau / station / « Location code » / Canal. L’utilisateur pourra alors affiner sa requête en sélectionnant ou désélectionnant ces sous requêtes. Ensuite l’utilisateur choisira la durée des enregistrements qu’il souhaite récupérer. Soit en sélectionnant une durée autour du temps origine du séisme. Soit en sélectionnant une durée autour d’une une phase sismique (P ou S). Puis il choisira le format dans lequel il souhaite récupérer les données : miniSEED, Full SEED, SAC, ASCII ou bien alors juste obtenir les fichiers de métadonnées : Dataless SEED, StationXML, XML Inventory. Et enfin l’utilisateur choisira la manière de récupérer les données :

-‐ Soit directement : une fenêtre de téléchargement du fichier de données s’ouvrira une fois que ce volume de données aura été créé au nœud B.

-‐ Soit indirectement : L’utilisateur se verra alors indiqué une URL ou récupérer le fichier de données. Cette URL sera active une fois le fichier de données créé au nœud B.

Avant de soumettre sa requête, l’utilisateur pourra exporter sa requête en plusieurs formats : fichier de requête permettant d’utiliser les « Web Services » et fichier de requête permettant d’utiliser le protocole « Arclink ». Remarque 1: Si la requête de l’utilisateur porte sur des réseaux en accès restreint, un message d’avertissement et un formulaire d’identification (email de l’utilisateur et mot de passe) apparaitront afin de signifier à l’utilisateur qu’il doit posséder les autorisations

25

nécessaires pour récupérer les données de ces réseaux. Le formulaire d’identification devra être rempli par l’utilisateur afin de pouvoir soumettre sa requête. Remarque 2: Lors de la demande de gros volumes de données, seule la méthode permettant de récupérer les données indirectement (via une URL) devra être utilisée. Dans le document de spécification et conception de cette interface, nous identifierons avec le nœud B quelles seront les modalités à imposer aux requêtes utilisateurs afin d’empêcher la création de volume de données excessif.

5.11.2 Accéder aux données pour une période donnée


Sujet Description

Intitulé Accéder rapidement aux données pour une période donnée grâce à une interface conviviale.

Objectif L’objectif est de fournir aux utilisateurs une interface conviviale permettant de récupérer facilement les données sur une période donnée et selon de nombreux critères.

Courte description Cette fonctionnalité permettra aux utilisateurs de récupérer des données par période. Plusieurs formats de données et métadonnées seront disponibles : miniSEED, Full SEED, SAC, ASCII, Dataless SEED, StationXML, XML Inventory.


Les données et informations de cette interface proviennent du nœud B via les webservices déployés au nœud B.

Accès Cette fonctionnalité sera accessible depuis le menu « Accès aux données / Accès aux données par période»


Cette fonctionnalité s’inspire de fonctionnalités déjà existantes dans d’autres centres de données. Elle comprend trois étapes :

-‐ La première étape qui permet à l’utilisateur de sélectionner une période pour laquelle il souhaite récupérer les données

26

-‐ Une deuxième étape permettant à l’utilisateur de sélectionner les stations dont il souhaite récupérer les données

-‐ Une troisième étape permettant à l’utilisateur de vérifier et d’affiner sa requête, de choisir le format des données, et le moyen qu’il souhaite utiliser pour les récupérer.

1. Première étape : Sélection de la période Pour récupérer les données sur une période, l’utilisateur entrera la date et l’heure de début et la date et l’heure de fin de cette période.

Une fois cette étape réalisée, l’utilisateur pourra compléter sa requête en sélectionnant les stations des réseaux dont il veut récupérer les données 2. Deuxième étape : Sélection des stations Pour cela les critères de recherches permettant d’afficher les stations sur une carte et dans un tableau seront les suivants :

-‐ Types de réseaux (permanent, temporaires, virtuels)

-‐ Réseau -‐ Station -‐ Type de capteur

-‐ « Location code » -‐ Canal -‐ Localisation (Latitude min et max, Longitude min et max)

Une fois les stations correspondant à la recherche afficher sur une carte et dans un tableau, l’utilisateur sélectionnera le ou les stations dont il souhaite récupérer les données. Sur la carte et dans le tableau n’apparaitront que les stations ayant des données pour les critères spécifiés précédemment. En cliquant sur une station l’utilisateur pourra consulter la « Fiche descriptive » de la station (cf « 5.9 Visualiser les stations »). Remarque : Les stations des réseaux en accès restreint apparaitront sur la carte et dans le tableau de manière différente des stations en accès ouvert. Par exemple une image représentant un petit cadenas pour être attaché au nom ou à l’icône de la station. Une fois cette étape réalisée, l’utilisateur pourra visualiser et affiner sa requête. 3. Troisième étape : Vérifier et affiner la requête Une fois la sélection des stations effectuée, l’utilisateur peut donc vérifier et affiner la requête qu’il souhaite soumettre. Une page s’ouvrira en rappelant dans un tableau le détail de la requête demandée. La requête sera décomposée en sous requêtes (jusqu’au niveau du

27

canal). On retrouvera donc pour chaque sous requête les informations suivantes : réseau / station / période demandée / « Location code » / Canal. L’utilisateur pourra alors affiner sa requête en sélectionnant ou désélectionnant des sous-‐requêtes. Ensuite il choisira le format dans lequel il souhaite récupérer les données : miniSEED, Full SEED, SAC, ASCII ou bien alors juste obtenir les fichiers de métadonnées : Dataless SEED, StationXML, XML Inventory. Enfin l’utilisateur choisira la manière de récupérer les données :

-‐ Soit directement : une fenêtre de téléchargement du fichier de données s’ouvrira une fois que ce volume de données aura été créé au nœud B.

-‐ Soit indirectement : L’utilisateur se verra alors indiqué une URL ou récupérer le fichier de données. Cette URL sera active une fois le fichier de données créé au nœud B.

Avant de soumettre sa requête, l’utilisateur pourra exporter sa requête en plusieurs formats : fichier de requête permettant d’utiliser les « Web Services » et fichier de requête permettant d’utiliser le protocole « Arclink ». Remarque : Si la requête de l’utilisateur porte sur des réseaux en accès restreint, un message d’avertissement et un formulaire d’identification (email de l’utilisateur et mot de passe) apparaitront afin de signifier à l’utilisateur qu’il doit posséder les autorisations nécessaires pour récupérer les données de ces réseaux. Le formulaire d’identification devra être rempli par l’utilisateur afin de pouvoir soumettre sa requête. Remarque : Lors de la demande de gros volumes de données, seule la méthode permettant de récupérer les données indirectement (via une URL) devra être utilisée. Dans le document de spécification et conception de cette interface, nous identifierons avec le nœud B quelles seront les modalités à imposer aux requêtes utilisateurs afin d’empêcher la création de volume de données excessif.

28

5.11.3 Accéder aux données temps réel


Sujet Description

Intitulé Accès aux données en temps réel

Objectif L’objectif est de présenter la façon d’accéder aux données en temps réel et quasi-‐réel des données RESIF.

Courte description Le portail RESIF présentera une description sur la manière de se connecter au serveur RESIF qui fourni l’accès aux données en temps réel ou à d’autres serveurs publiques qui fournissent les données RESIF en temps réel.


Cette description de la procédure de connexion aux données temps réel est un contenu statique qui sera rédigé avec l’aide du nœud B et validé par le COPIL.

Accès Cette fonctionnalité sera accessible depuis le menu « Données / Accès aux données temps réel


Le centre de données RESIF fourni l’accès automatique à une partie des données en temps réel ou quasi-‐réel. Cette fonctionnalité permet aux utilisateurs ou aux centres de données ou de détection de séismes d’accéder à l’information nécessaire pour accéder à ces données. Aujourd’hui cet accès est disponible via le protocole « seedlink » (développé par GFZ) sur un serveur RESIF publique ou sur d’autres serveurs « seedlink » publiques comme celui d’IRIS-‐DMC. Cette page présentera les instructions pour se connecter au serveur ainsi que des exemples.

29

5.11.4 Accéder aux données accéléromètriques


Sujet Description

Intitulé Accès aux données accéléromètriques

Objectif L’objectif est de fournir aux utilisateurs une interface conviviale permettant de récupérer facilement les données accéléromètriques selon de nombreux critères.

Courte description Plusieurs formats de données et métadonnées seront disponibles : miniSEED, Full SEED, SAC, ASCII, Dataless SEED, StationXML, XML Inventory.


Les données et informations de cette interface proviennent du nœud B via les webservices déployés au nœud B.

Accès Cette fonctionnalité sera accessible depuis le menu « Accès aux données / Accès aux données accéléromètriques»


Cette fonctionnalité fournira une interface permettant de récupérer les données en fonction de nombreux critères. Ces critères seront classés en 4 types de catégories : 1er Type : Critères sur les réseaux et stations

-‐ Réseau -‐ Station -‐ Type de sol

-‐ Classe de sol -‐ Critère sur « Champ libre »


2ème Type : Critères sur les Canaux 3ème Type : Critères sur les évènements

-‐ Magnitude

-‐ Profondeur -‐ Latitude -‐ Longitude

-‐ Type d’évènement

30

4ème Type : Critères concernant les enregistrements

-‐ Période : date de début date de fin -‐ PGA -‐ PGV

-‐ Durée -‐ Distance épicentrale -‐ Critère sur les données : « données non triées », « données triées incomplètes », « données

triées complètes »

Une fois cette sélection effectuée, les enregistrements disponibles seront affichés dans une liste, l’utilisateur pourra alors sélectionner ou désélectionner des enregistrements avant de soumettre sa requête. Enfin l’utilisateur choisira la manière de récupérer les données :

-‐ Soit directement : une fenêtre de téléchargement du fichier de données s’ouvrira une fois

que ce volume de données aura été créé au nœud B. -‐ Soit indirectement : L’utilisateur se verra alors indiqué une URL ou récupérer le fichier de

données. Cette URL sera active une fois le fichier de données créé au nœud B.

Avant de soumettre sa requête, l’utilisateur pourra exporter sa requête en plusieurs formats : fichier de requête permettant d’utiliser les « Web Services » et fichier de requête permettant d’utiliser le protocole Arclink. Remarque : Lors de la demande de gros volumes de données, seule la méthode permettant de récupérer les données indirectement (via une URL) devra être utilisée. Dans le document de spécification de cette interface, nous identifierons avec le nœud B quelles seront les modalités à imposer aux requêtes utilisateurs afin d’empêcher la création de volume de données excessif.

31

5.11.5 Accéder aux données par d’autres moyens

5.11.5.1 Accéder aux données par des « web services » Tableau présentant la fonctionnalité :

Sujet Description

Intitulé « web services » RESIF

Objectif L’objectif est de présenter en détail chaque « web service » publique déployé au nœud B et d’expliquer aux utilisateurs comment les utiliser. Exemple : http://www.iris.edu/ws

Courte description Plusieurs pages permettront de décrire les « web services » et leur fonctionnement.


Ces pages et interfaces seront réalisées par l’équipe du portail web en collaboration avec le « nœud B » et les éventuels « nœud A » hébergeant des « web services ».

Accès Cette fonctionnalité sera accessible depuis le menu « Accès aux données / Autres moyens / Web services »


Cette fonctionnalité se décomposera en deux parties : Une première page décrira de manière succincte tous les « web services » disponibles dans le SI-‐RESIF. Ensuite pour chaque « web service » une page expliquera en détail son fonctionnement et son utilisation. Cette page proposera des exemples ainsi qu’un formulaire simple permettant d’utiliser rapidement ce « web service ».

32

5.11.5.2 Accéder aux données via le protocole « arclink »


Sujet Description Intitulé Accès aux données via le protocole « arclink » Objectif L’objectif est d’expliquer aux utilisateurs comment se connecter au nœud

« arclink » EIDA afin de récupérer les données RESIF.

Courte description Le portail RESIF présentera une description sur la manière de se connecter au nœud « arclink » de RESIF.


Cette description de la procédure de connexion aux données validées est un contenu statique qui sera rédigé avec l’aide du « nœud B » et validé par le COPIL.

Accès Cette fonctionnalité sera accessible depuis le menu « Accès aux données / Autres moyens / Accès aux données via le protocole « arclink»


Cette page présentera les instructions pour se connecter au nœud EIDA de RESIF ainsi que des exemples.

5.11.6 Afficher les citations Tableau présentant la fonctionnalité :

Sujet Description

Intitulé Afficher les citations

Objectif L’objectif est de fournir aux utilisateurs des données RESIF les citations à faire apparaître dans leurs travaux.

Courte description Les utilisateurs des données RESIF seront invités à citer RESIF dans leurs publications scientifiques ou techniques. Le portail leur fournira le texte et les logos à utiliser.


Ces citations seront rédigées par le COPIL et les représentants des différents OSU.

Accès Cette fonctionnalité sera accessible depuis le menu « Données / Citations»

33

5.11.7 Demander l’accès aux données restreintes Un utilisateur souhaitant récupérer des données restreintes pourra faire une demande d’accès à ces données. Un identifiant (email) et un mot de passe lui seront fourni par le « nœud B » le cas échéant. Remarque : Le COPIL devra décider qui sont les personnes autorisées à fournir l’accès à des utilisateurs aux réseaux en accès restreint. Tableau présentant la fonctionnalité :

Sujet Description

Intitulé Demander l’accès aux données restreintes

Objectif L’objectif est de fournir un formulaire simple permettant à un utilisateur d’effectuer une demande d’autorisation d’accès aux données d’un réseau en accès restreint.

Courte description Un formulaire simple contenant les champs : email de l’utilisateur, nom du l’utilisateur, Institut de l’utilisateur, et le texte de la demande de l’utilisateur, permettra à l’utilisateur de saisir et d’envoyer sa demande.


Ce formulaire sera réalisé par le portail. Les demandes seront enregistrées dans la base de données du portail web et transmises aux personnes autorisées à fournir l’accès aux réseaux restreints à des utilisateurs.

Accès Cette fonctionnalité sera accessible depuis le menu « Données / Demander l’accès aux données restreintes»

34

5.12 Afficher la sismicité

Le menu « Sismicité » donnera accès à deux fonctionnalités : • Afficher la sismicité

• Afficher les séismes d’un intérêt particulier

5.12.1 Afficher la sismicité des différents catalogues sur une carte

Remarque : Le portail n’a pas pour objectif de distribuer des catalogues de sismicité. Pour cette fonctionnalité, l’objectif est de présenter la sismicité aux utilisateurs de manière conviviale. Pour chaque événement affiché un lien redirigeant vers l’évènement sur le site de l’organisme propriétaire du catalogue sera proposé.


Sujet Description

Intitulé Afficher la sismicité

Objectif L’objectif est de présenter la sismicité aux utilisateurs à la fois sur une carte et dans un tableau en fonction de divers critères de recherche.

Courte description Le portail RESIF présentera une interface avec des critères de recherches permettant d’afficher la sismicité de manière interactive (différents catalogues d’évènements seront proposés).


Cette interface du portail web récupèrera les informations concernant la sismicité via « web services ».

Accès Cette fonctionnalité sera accessible depuis le menu « Sismicité / Carte de sismicité»


Le portail RESIF présentera une interface permettant en fonction de divers critères de recherche d’afficher la sismicité. Cette fonctionnalité reprend dans les grandes lignes la première étape de la fonctionnalité permettant d’accéder aux données par évènements. Les critères de recherche seront les suivants:

• Choix du catalogue • Période (date de début et date de fin)

35

• Magnitude (magnitude minimum et magnitude maximum) • Latitude (latitude minimum et latitude maximum) • Longitude (longitude minimum et longitude maximum) • Profondeur (profondeur minimum et profondeur maximum) • Type d’événement (séisme, tir de carrière, avalanche, etc..)

Sur la carte (de type « Google Maps ») chaque événement sera représenté par un cercle dont la taille sera relative à la magnitude de l’évènement. La couleur de ce cercle sera relative à la profondeur de l’événement. En cliquant sur un événement de la carte l’utilisateur accèdera au détail de l’événement : Magnitude, Type de magnitude, Date, Localisation, Latitude, Longitude, Profondeur, URL du lien QuakeML de l’événement, ainsi qu’un lien vers la page de cet événement sur le site du catalogue correspondant (si cette page existe). Dans le tableau attenant à la carte on retrouvera la liste des évènements avec les mêmes informations que ci-‐dessus : Magnitude, Type de magnitude, Date, Localisation, Latitude, Longitude, Profondeur, URL du lien QuakeML de l’événement, ainsi qu’un lien vers la page de cet événement sur le site du catalogue correspondant (si cette page existe). Un bouton permettra d’exporter la liste des évènements de ce tableau dans différents formats (ASCII, PDF, Excel, ainsi que le format KML pour le logiciel « Google Earth »). Remarque : Pour qu’un catalogue de sismicité soit proposé via cette interface il faudra que celui-‐ci soit accessible via « web service » au format QuakeML. Pour le moment le CSEM propose son catalogue d’évènements au format QuakeML, le « web service » présentant le catalogue du ReNaSS au format QuakeML est en cours de réalisation et devrait être bientôt disponible.

5.12.2 Afficher les séismes d’un intérêt particulier


Sujet Description

Intitulé Afficher les séismes d’un intérêt particulier.

Objectif L’objectif est de montrer aux utilisateurs une page spéciale pour les séismes ayant un intérêt particulier.

Courte description Le portail RESIF présentera une interface avec la liste des séismes présentant un intérêt particulier. Pour chaque séisme on retrouvera un descriptif précis de cet événement (cartes, descriptifs scientifiques, etc..) ainsi qu’un volume de données dans différents format (SEED, SAC).


A établir par le COPIL

Accès Cette fonctionnalité sera accessible depuis le menu « Sismicité / Séisme d’un intérêt particulier»

36

5.13 Présenter des outils, logiciels, librairies permettant de manipuler les données RESIF

Cette partie sera dédiée aux différents clients (logiciels, scripts, librairies) permettant de récupérer et de manipuler les données RESIF. Cette page fournira l’accès en téléchargement à des scripts (scripts perl, python, etc..), des librairies (ObsPy, librairie MATLAB, librairie JAVA, etc..), des outils (exemple : outils de conversion d’un DATALESS en stationXML, etc.). Cette fonctionnalité décrira aux utilisateurs comment télécharger, installer et utiliser ces scripts, librairies et outils. Tableau présentant la fonctionnalité :

Sujet Description

Intitulé Outils, logiciels, librairies

Objectif L’objectif est de présenter en détail des scripts, des outils, des librairies permettant de récupérer et de manipuler les données.

Courte description Plusieurs pages permettront de décrire l’installation et l’utilisation des divers scripts, outils et librairies.


Ces pages et interfaces seront réalisées par l’équipe du portail web en collaboration avec le « nœud B » et les « nœud A »

Accès Cette fonctionnalité sera accessible depuis le menu « Outils, logiciels»

37

5.14 Présenter les modalités de contact aux utilisateurs

5.14.1 Récolter l’avis des utilisateurs Tableau présentant la fonctionnalité :

Sujet Description

Intitulé « Retours utilisateurs »

Objectif L’objectif est de fournir aux utilisateurs un moyen de faire remonter leurs remarques et leurs avis sur le portail web ainsi que sur les données RESIF.

Courte description Le portail RESIF présentera un formulaire permettant aux utilisateurs d’envoyer leurs remarques et leurs avis. Ce formulaire contiendra les champs suivants :

• Type du retour (« Quel est votre avis concernant les fonctionnalités du portail ? », « Quelles évolutions attendez vous ? », « Quel est votre avis concernant les données distribuées ? »)

• Email de l’utilisateur • Description


Le formulaire sera réalisé par l’équipe du portail, et les « retours utilisateurs » seront enregistrés dans la base de données du portail.

Accès Cette fonctionnalité sera accessible depuis le lien en bas de page « Nous contacter ».

Cette interface enregistrera dans une base de données du portail web tous les « retours utilisateur » et enverra un email à des personnes de RESIF (qu’il faudra identifier dans la suite du projet). Les retours des utilisateurs pourront être consultés à la demande sur le site d’administration du portail.

38

5.14.2 Récupérer les questions des utilisateurs Tableau présentant la fonctionnalité :

Sujet Description

Intitulé Question ou remarque

Objectif L’objectif est de fournir aux utilisateurs un moyen de transmettre rapidement une question ou une remarque.

Courte description Le portail RESIF présentera un formulaire permettant aux utilisateurs de saisir leur question ou remarque. Ce formulaire contiendra les champs suivants :

• Sujet • Nom de l’utilisateur • Email de l’utilisateur • Question ou Remarque


Le formulaire réalisé par l’équipe du portail web et les « questions utilisateurs » seront enregistrés dans la base de données du portail.


Cette interface enregistrera les questions et les remarques des utilisateurs dans une base de données du portail web et enverra un email à des personnes de RESIF (qu’il faudra identifier dans la suite du projet).

5.14.3 Afficher les informations sur les contacts RESIF


Sujet Description

Intitulé Afficher les informations sur les personnes pouvant être contactées par les utilisateurs.

Objectif L’objectif est de fournir aux utilisateurs une liste de contacts auxquels ils peuvent s’adresser.

39

Courte description Le portail RESIF présentera une liste de contact en précisant pour chacun d’eux leur fonction. De manière non exhaustive les contacts seront :

• Un contact du portail web RESIF (webmaster) • Un contact concernant les données stockées au Nœud B • Un lien vers la partie « Présentation des OSU » où se trouveront les

informations concernant les personnes à contacter pour chaque OSU


Contenu statique.


Cette information sera gérée avec le CMS du portail via la partie « administration ».

5.15 Afficher l’aide en ligne et les FAQ (« Frequently asked questions »)


Sujet Description

Intitulé Afficher l’aide pour les utilisateurs du portail web RESIF.

Objectif L’objectif est de fournir aux utilisateurs une aide sur les fonctionnalités les plus importantes du portail web et l’accès aux FAQ.

Courte description Le portail RESIF présentera une aide en ligne pour les fonctionnalités « SeismiQuery » RESIF, l’accès aux données et pour les fonctionnalités concernant la sismicité. Cette aide sera sous forme de document consultable en ligne mais pourra aussi s’accompagner de vidéos montrant comment utiliser ces fonctionnalités.


Ces documents et vidéos seront réalisés et maintenus par l’équipe du portail web RESIF.

Accès Cette fonctionnalité sera accessible depuis le menu « Aide » du portail web situé dans le bandeau, mais sera aussi accessible directement depuis les fonctionnalités grâce à un bouton « aide » renvoyant vers l’aide utilisateur correspondante.

40

5.16 Afficher les mentions légales


Sujet Description

Intitulé Afficher les mentions légales du site

Objectif L’objectif est d’afficher les mentions légales du site portail web RESIF.

Courte description La loi française oblige de faire figurer certaines mentions légales obligatoires sur un site web à travers une page facilement accessible.


Ce texte sera un contenu statique en conformité aux textes de la loi et validé par le COPIL.

Accès Cette fonctionnalité sera accessible depuis le menu « Mentions légales» du portail web situé en pied de page.

5.17 Afficher le plan du site Tableau présentant la fonctionnalité :

Sujet Description

Intitulé Afficher le plan du site

Objectif L’objectif est de construire une page web qui permet aux utilisateurs d'accéder rapidement à l'ensemble des fonctionnalités et des documents proposés sur le site, et qui facilite le travail des robots d'indexation (type Google, Yahoo, Bing, etc..).

Courte description Un page web représentera de manière hiérarchique le contenu du portail web RESIF. Un fichier dit « sitemap XML» représentera cette structure et sera utilisé par les moteurs d’indexation.

Provenance des données

Contenu statique

Accès Cette fonctionnalité sera accessible depuis n’importe quelle page du portail web via le lien « Plan du site » en pied de page et le fichier « sitemap.xml » sera disponible pour les moteurs d’indexation à la racine du site web.

41

5.18 Rechercher des informations sur le site


Sujet Description

Intitulé Rechercher des informations sur le portail web RESIF

Objectif L’objectif est de proposer aux utilisateurs une fonctionnalité permettant de trouver rapidement des informations sur le portail web RESIF.

Courte description Un champs de recherche dans l’entête de chaque page du portail web permettra aux utilisateurs d’effectuer une recherche, les résultats de cette recherche seront présentés sous forme de liste.


La recherche portera sur le contenu du portail web RESIF (actualités, description des réseaux, publications, etc.), mais pas directement sur les données et métadonnées sismologiques.

Accès Cette fonctionnalité sera accessible depuis n’importe quelle page du portail web via un champ de recherche dans le bandeau du portail web.


Un champ de recherche dans le bandeau du portail web permettra aux utilisateurs d’effectuer une recherche, les résultats de cette recherche seront présentés sous forme de liste. Chaque itération de cette liste comprendra le titre de la page contenant l’information recherchée ainsi qu’un court descriptif présentant le texte ou se trouve l’information recherchée. En cliquant sur le titre de la page l’utilisateur sera renvoyé vers la page correspondante.

Un moteur de recherche externe (Google, etc.) sera utilisé pour mettre en place cette fonctionnalité.

42

5.19 Administrer le site La partie « Administration » du portail web RESIF sera en accès restreint, elle sera accessible depuis le bouton« Administration » situé en bas de page du portail web RESIF.

Lorsque qu’un utilisateur « cliquera » sur le bouton « Administration » il sera redirigé vers une interface de connexion afin qu’il s’identifie.

Une fois authentifié, l’utilisateur accédera à la partie « Administration », les menus proposés dans la partie « Administration » seront les suivants :

-‐ Afficher les statistiques du portail web RESIF

-‐ Afficher les statistiques des données RESIF distribuées

-‐ Afficher les « retours » et « questions » des utilisateurs

-‐ Gérer les contenus du portail web RESIF

-‐ Gérer les utilisateurs du site

-‐ Effectuer des sauvegardes ou des restaurations

5.19.1 Afficher le formulaire de connexion à la partie « Administration »


Sujet Description

Intitulé Afficher le formulaire de connexion pour la partie « Administration »

Objectif L’objectif est de permettre aux utilisateurs de se connecter à la partie « Administration » du portail web RESIF.

Courte description Le portail RESIF présentera une interface permettant à l’utilisateur de s’identifier en entrant son « nom d’utilisateur » et son mot de passe. Si l’utilisateur est correctement authentifié alors il accèdera aux fonctionnalités de la partie « administration ». Sur cette interface il sera proposé un formulaire permettant de récupérer son mot de passe en cas d’oubli.


Base de données utilisateurs du site administration du portail

Accès Cette fonctionnalité sera accessible en cliquant sur le bouton « Administration » situé en bas de page du portail web RESIF.

43

5.19.2 Afficher les statistiques du portail web Tableau présentant la fonctionnalité :

Sujet Description

Intitulé Afficher les statistiques du portail web aux utilisateurs autorisés.

Objectif L’objectif est de rendre compte aux utilisateurs autorisés de la fréquentation générale du portail web, ainsi que de connaître les fonctionnalités les plus utilisées, d’avoir une synthèse géographique des visiteurs, etc.

Courte description Le portail RESIF présentera une interface permettant d’afficher les statistiques du portail web. L’affichage de ces statistiques se fera grâce à un outil externe.


Ces statistiques seront calculées par un outil externe.

Accès Cette fonctionnalité sera accessible depuis la partie « Administration » du portail web.


L’interface présentant les statistiques du portail web RESIF sera basé sur un outil de statistiques externe à RESIF. Il existe de nombreux outils permettant d’effectuer ces statistiques web, le plus connu étant « Google Analytics » (voir ci-‐dessous).

44

5.19.3 Afficher les statistiques des données distribuées


Sujet Description

Intitulé Afficher les statistiques des données RESIF distribuées aux utilisateurs autorisés.

Objectif L’objectif est de rendre compte aux utilisateurs autorisés du volume de données distribuées.

Courte description Le portail RESIF présentera une interface permettant d’afficher les statistiques concernant les données distribuées.


Ces statistiques seront calculées et fournies par le « nœud B » au portail web via un « web service ».


45


L’interface présentant les statistiques des données RESIF distribuées proposera un critère de sélection des statistiques par fenêtre de temps ainsi que deux critères d’affichage possibles :

• Affichage d’une page présentant des statistiques globales pour la période sélectionnée :

o Volume total des données distribuées. o Tableau et graphique présentant le volume des données distribuées pour chaque

réseau.

o Tableau présentant le volume des données des 100 stations les plus demandées.

• Affichage des statistiques du réseau (permanent, temporaire, ou virtuel) sélectionné pour la

période sélectionnée : o Affichage du volume des données distribuées pour ce réseau.

o Tableau présentant le volume des données distribuées pour chaque station de ce réseau.

Pour chaque affichage de statistiques, la page web devra pouvoir être exportée sous forme d’un document au format «PDF» afin de faciliter la diffusion de ces statistiques et leurs impressions. Remarque : En fonction des besoins et des demandes des utilisateurs d’autres modes de présentation des statistiques pourront être développés et mis à disposition sur le portail web.

5.19.4 Afficher les « retours » et les questions des utilisateurs Tableau présentant la fonctionnalité :

Sujet Description

Intitulé Afficher les « retours » et les questions des utilisateurs

Objectif L’objectif est d’afficher les « retours utilisateurs », les questions et les remarques qui ont été envoyés par les utilisateurs du portail web.

Courte description Un tableau affichera les « retours utilisateurs », les questions et les remarques qui ont été envoyés par les utilisateurs du portail web.

46


Base de données du portail


5.19.5 Gérer les contenus du portail web Tableau présentant la fonctionnalité :

Sujet Description

Intitulé Gérer les contenus du portail web

Objectif L’objectif est de proposer une partie permettant à des utilisateurs autorisés de gérer certains contenus du portail web.

Courte description En fonction des droits dont disposera l’utilisateur celui-‐ci pourra gérer différents contenus du portail web.


Base de données du CMS du portail web

Accès Cette fonctionnalité sera en accès restreint, elle sera accessible depuis la partie « Administration » du portail web.


Cette fonctionnalité est en accès restreint, en fonction de ses droits, l’utilisateur pourra gérer (ajouter / modifier /supprimer) tel ou tel contenu du portail web : Les contenus pouvant être édités sont :

-‐ Les actualités du portail RESIF

-‐ La description générale du Système d’Information RESIF -‐ Les descriptions des OSU -‐ Les descriptions des réseaux

-‐ Les descriptifs des données RESIF -‐ Les citations -‐ Les mentions légales

47

5.19.6 Gérer les utilisateurs de la partie « Administration » Tableau présentant la fonctionnalité :

Sujet Description

Intitulé Gérer les utilisateurs de la partie « administration » du portail web RESIF

Objectif L’objectif est de proposer une interface permettant aux administrateurs de gérer les utilisateurs pouvant accéder aux fonctionnalités de la partie « administrations » du portail web RESIF.

Courte description Cette fonctionnalité permettra d’ajouter ou supprimer des utilisateurs, et pour chaque utilisateur de lui attribuer des droits sur l’édition des différents contenus.



La gestion des utilisateurs se fera par catégorie d’utilisateurs : • Administrateur(s) du site : utilisateur qui tous les privilèges sur le site. • Utilisateurs avec droit d’édition et de publication sur le site de production

• Utilisateurs pouvant éditer et modifier certains contenus du site avec ou sans droit de publication.

• Utilisateurs pouvant accéder aux statistiques (du portail, d’accès aux données) en

consultation

5.19.7 Sauvegarder et restaurer le portail en production

Sujet Description

Intitulé Sauvegarder et restaurer le portail web en production

Objectif Sauvegarder le portail web RESIF et permettre la restauration à partir de sauvegardes.

Courte description Afficher des procédures de sauvegarde des différents composants du portail et de restauration.

Accès Cette fonctionnalité sera en accès restreint, elle sera accessible depuis la partie « Administration » du portail web.

48

Le portail web contiendra les procédures nécessaires pour sauvegarder ces composants : • Les sources du portail web

• Les bases de données de contenu, statistiques, gestion des utilisateurs.

• La documentation

De même une procédure de restauration à partir des sauvegardes sera inclue dans le produit. Ces procédures seront à définir avec le nœud B.

49

6 Architecture du portail

Ce chapitre décrit les architectures logicielle et web du système.

6.1 Architecture logicielle Le schéma suivant décrit les différents éléments qui constitueront le système « Portail web RESIF ».

50

6.2 Architecture web

6.3 Liste des « web services » à mettre en place au nœud B Les spécifications précises de tous les « web services » qui devront être mis en place au nœud B seront réalisées dans la suite du projet, cependant on peut déjà donner un bon aperçu de la liste des « web services » qui seront nécessaires d’être déployés au nœud B.

La plupart des « web services » ne serviront pas uniquement aux interfaces du portail web mais seront ouverts à tout le monde, d’autres seront strictement réservés au bon fonctionnement du portail web.

Le nommage et les fonctionnalités des « web services » utilisés dans le portail seront conformes avec le premier document émis par la FDSN :

http://www.fdsn.org/webservices/FDSN-‐WS-‐Specifications-‐1.0.pdf

51

« ws-‐station » : Ce « web service renverra en fonction de multiples paramètres pris en entrée, les informations sur les réseaux / stations / canaux au format « StationXML ».

Ce « web service » sera public, son fonctionnement et son utilisation seront présentés sur le portail web RESIF.

« ws-‐stationresif » : Ce « web service » renverra en fonction de multiples paramètres pris en entrée, des informations sur les stations et canaux qui seront plus spécifiques à RESIF et qui ne seront pas présentes dans le format « StationXML » (Photos des stations, cartes détaillées des sites des stations, etc..).

Ce « web service» sera public.

« ws-‐virtualnetwork» : Ce « web service » renverra la liste des stations des réseaux virtuels au format XML.


« ws-‐seismicnoise» : Ce « web service » renverra en fonction de multiples paramètres pris en entrée, des graphiques de courbes de bruits.


« ws-‐dataselect » : Ce « web service » renvoie des données au format miniSEED pour une série temporelle d’un seul canal.


« ws-‐timeseries» : Ce « web service » est similaire au « ws-‐dataselect » mais propose de renvoyer les données dans davantage de formats (ASCII, miniSEED, SAC).


« ws-‐bulkdataselect» : Ce « web service » renvoie des données au format miniSEED pour des séries temporelles de plusieurs canaux.

52


« ws-‐resp » : Ce « web service » renverra en fonction de multiples paramètres pris en entrée la réponse instrumentale des canaux au format « RESP_FILE »


« ws-‐sacpz » : Ce « web service » renverra en fonction de multiples paramètres pris en entrée, la liste les pôles et zéros par canal.


« ws-‐evalresp » : Ce « web service » renverra en fonction de multiples paramètres pris en entrée, les réponses instrumentales évaluées par RESIF (Graphiques d’amplitudes et de phases, etc.)


« ws-‐event » : Ce « web service » renverra en fonction de multiples paramètres pris en entrée, les évènements sismiques d’un catalogue de sismicité au format QuakeML.

Note importante : Ce ou ces « web services » « ws-‐event » ne seront à priori pas mis en place au « nœud B », mais plutôt au « nœud A » de l’EOST afin de distribuer le catalogue du RéNass.

D’autres « web services » « ws-‐event » seront à priori utilisés dans le portail web RESIF pour afficher la sismicité au niveau mondial. Pour le moment IRIS et le CSEM/ORFEUS proposent ce type de « web service ». Le « web service » « ws-‐event » proposé par IRIS permet d’accéder entre autre aux catalogues d’événement du NEIC et de l’ISC, celui du CSEM/ORFEUS permet d’accéder au catalogue du CSEM.

Ce(s) web service(s) seront publics, leur fonctionnement et leur utilisation seront présentés sur le portail web RESIF.

« ws-‐statistics » : Ce « web service » renverra en fonction de multiples paramètres pris en entrée, les statistiques d’accès aux données RESIF au format XML.

Ce « web service » sera privé, authentification nécessaire.

53

D’autres « web services » externes à RESIF pourront être utilisés pour enrichir le contenu des interfaces RESIF. Quelques exemples :

-‐ L’USGS propose un web service pour afficher les limites de plaques sur une carte de type « Google Maps ».

-‐ Le BRGM et l’IGN proposent des « web services » pour accéder à des cartes géologiques

-‐ etc..

Remarque : Le nœud B devra prévoir un espace de stockage accessible depuis le web pour les fichiers de données créés par les utilisateurs lors de l’utilisation des « web services » permettant d’accéder aux données (ws-‐bulkdataselect, ws dataselect, ws-‐timeseries).

6.4 Développement de la « couche logicielle d’abstraction »

Tout au long de la réalisation des interfaces web du portail web RESIF une « couche logicielle d’abstraction » sera implémentée afin d’isoler les interfaces du portail web du mécanisme d’accès aux données.

Les codes sources de cette « couche d’abstraction » seront fournis sous forme d’une ou plusieurs librairies à la fin du projet.

6.5 Conformité aux standards Le portail web RESIF sera développé conformément aux normes du W3C (World Wide Web Consortium). Toutes les pages seront testées par les outils de validation du W3C ((X)HTML et CSS).

Le portail sera testé sur les différents navigateurs web existants (deux dernières versions maximum): Firefox (version 18 et supérieures), IE (version 9 et supérieures), Safari (version 6.0, et supérieures), Chrome (version 24 et supérieures). Et sera compatible avec les différents systèmes d’exploitation : Windows, Mac-‐OSX, Linux, UNIX.

54

6.6 Nom de domaine et hébergement

6.6.1 Nom de domaine Le portail web RESIF sera accessible depuis le site web RESIF :

http://resif.fr

ou directement par l’URL :

http://portal.resif.fr

6.6.2 Hébergement L’hébergement des « web services » RESIF utilisés par les interfaces du portail web sera pris en charge par le nœud B car ces web services sont directement liés aux données hébergées au nœud B.

L’architecture proposée permet d’héberger les « web services » et les interfaces du portail web dans des lieux différents, cependant pour des questions de rapidité d’échange de données entre le « nœud B » et le portail web il est recommandé que le portail web RESIF dans sa version de production soit lui aussi hébergé au « nœud B ».

Cela implique que le nœud B sera responsable de la disponibilité du portail web et des web services RESIF. Le nœud B devra donc gérer les serveurs web de production, c’est à dire gérer la sécurité, gérer les sauvegardes, etc...

55

7 Equipe technique et planning de réalisation

Le tableau suivant montre les membres de l’équipe « projet Portail Web RESIF » que l’on souhaiterait mettre en place à l’IPGP pour une durée de 2 ans afin de réaliser le portail web RESIF :

Nom Rôle Temps

Nikolaï Shapiro Responsable scientifique 10%

Vincent Douet Chef de projet, développeur 80%

Constanza Pardo Contributions documents de spécification

10%

CDD-‐DEV (1) Développeur 100%

CDD-‐ASR (1)(2) Administrateur systèmes et réseaux

20%

(1) Postes à contrat à durée déterminée pour 2 ans, demandés à RESIF

(2) Poste mutualisé avec les Nœuds A GEOSCOPE et OVS à l’IPGP

56

Liste des tâches et livrables :

N° Tâche Produit Livrable Durée en mois

Date de début N° mois

Personnel impliqué dans les tâches

Priorité

Conduite du projet scientifique et technique

Tout au long du projet

0 V.Douet, N. Shapiro

D0 Mise en place du projet

1 0 V.Douet, C. Pardo, N. Shapiro

1 : Indispensable

D1 Cahier des charges fonctionnel et validation par le COPIL

Document 6 0 V.Douet, C. Pardo, N. Shapiro, COPIL

1 : Indispensable

D2 Choix de technologies Document 1 6 V. Douet, Nœud B

1 : Indispensable

D3 Mise en place de l’environnement de développement

0,5 6 V. Douet, CDD-‐DEV

1 : Indispensable

D4 Mise en place de la charte graphique.

Composant portail web

0,5 6 V. Douet, Prestataire pour le Design RESIF

1 : Indispensable

D5 Maquette du portail Composant web 1 6 V. Douet,CDD-‐DEV

2 : Importante

D6 Spécification des principaux webservices à mettre en place au nœud B

Document 1 8 V. Douet, Nœud B

1 : Indispensable

D7 Installation et configuration du CMS

Document et CMS fonctionnel

1 8 V. Douet, CDD-‐ASR, Nœud B

1 : Indispensable

D8 Mise en place du contenu statique

Contenu du portail web

Tout au long du projet

9 Equipe Portail, Nœuds A, Nœud B, COPIL, etc..

1 : Indispensable

D9 Spécifications, conception, développement, et déploiement de l’interface de visualisation des stations

Paragraphe 5.9

Document et composant portail web

3 9 V. Douet, CDD-‐DEV, Nœud B

1 : Indispensable

D10 Spécifications, conception, développement, et déploiement de l’interface d’accès aux données par période

Paragraphe 5.11.2



1 : Indispensable

D11 Spécifications, conception,

Document et composant


1 : Indispensable

57

développement, et déploiement de l’interface d’accès aux données par évènements

Paragraphe 5.11.1

portail web

D12 Spécifications, conception, développement, et déploiement de l’interface d’accès aux données accéléromètriques,

Paragraphe 5.11.4



1 : Indispensable

D13 Spécifications, conception, développement, et déploiement des autres interfaces d’accès aux données

Paragraphe 5.11.5

Document et composants portail web


2 : Importante

D14 Spécifications, conception, développement et déploiement de l’interface affichant la sismicité

Paragraphe 5.12.1

Document et composant web


2 : Importante

D15 Spécifications, conception, développement et déploiement de l’interface affichant les séismes d’un intérêt particulier

Paragraphe 5.12.2


1 17 V. Douet, CDD-‐DEV, Nœud B, COPIL

3 : Moyenne

D16 Spécifications, conception, développement et déploiement de l’interface « SeismiQuery »

Paragraphe 5.10



3 : Important

D17 Spécifications, conception, développement et déploiement des interfaces permettant de récolter les avis et les questions des



3 : Moyenne

58

utilisateurs

Paragraphe 5.14

D18 Spécifications, conception, développement et déploiement de l’interface d’aide aux utilisateurs



1 : Indispensable

D19 Spécifications, conception, développement et déploiement de l’interface d’administration du site

Paragraphe 5.19



2 : Importante

D20 Recette et validation Document de recette et validation

2 24 V.Douet, C. Pardo, N. Shapiro, COPIL

1 : Indispensable

D21 Documentation utilisateur et documentation technique

Documents 2 24 V. Douet, CDD-‐DEV, CDD-‐ASR, Nœud B

1 : Indispensable

D22 Déploiement de la version finale et mise en ligne

Produit Portail Web

1 25 V. Douet, CDD-‐DEV, CDD-‐ASR, Nœud B

1 : Indispensable

D23 Livraison du produit complet (les codes sources des interfaces et de la « couche d’abstraction », la documentation technique, la documentation utilisateur, etc..)

Produit Portail Web

25 1 : Indispensable

59

Quelques remarques importantes concernant ce planning :

• Les déploiements des premiers composants du portail web au nœud B commenceront à partir de la tâche D9. Une première version permettant de visualiser les stations et d’accéder aux données continues par période sera disponible après la tâche D10 à la fin du mois n°13, (soit 7 mois après la validation du cahier des charges par le COPIL)

• Pour la réalisation du portail RESIF suivant ce planning, l’arrivée d’un CDD développeur dans l’équipe du portail web est nécessaire rapidement. Le recrutement de ce développeur devra commencer dès que le COPIL aura validé le cahier des charges (D1).

Ci-‐dessous la représentation du planning de réalisation du portail web RESIF sous la forme d’un diagramme de Gantt simplifié :

60

61

8 Glossaire

ArcLink : ArcLink est un protocole basé sur TCP dédié à la distribution des données et des métadonnées archivées et validées (par opposition aux données temps réel ou temps quasi réel qui sont distribuées par SeedLink). Les communications client/serveur se font par le protocole ArcLink et non par mail ou ftp. Le format des données récupérées est SEED. ArcLink est développé par GFZ.

CMS (Content Management System) : Un CMS est un système de gestion de contenu, cette famille de logiciels est destinée à la conception et à la mise à jour dynamique de sites Web

OSU : Observatoire des Sciences de l’Univers

QuakeML : Format d'échange XML des données paramétriques des évènements sismologiques.

RSS : (sigle venant de l'anglais « Really Simple Syndication ») est une famille de formats de données utilisés pour la syndication de contenu Web.

Un produit RSS est une ressource Web dont le contenu est produit automatiquement (sauf cas exceptionnels) en fonction des mises à jour d’un site Web. Les flux RSS sont souvent utilisés par les sites d'actualité et les blogs pour présenter les titres des dernières informations consultables en ligne.

SeedLink : SeedLink est un protocole d’échange de données au format SEED.

SI : Système d’Information

62

StationXML : StationXML est un format d’échange XML destiné à partager les métadonnées des stations. Le schéma du stationXML est maintenu entre autre par IRIS, la FDSN et le NEIC.

Plus d’informations : http://www.fdsn.org/xml/station/

TGIR : Très Grande Infrastructure de Recherche

« Web service » : Un « web service » est un programme informatique permettant la communication et l'échange de données entre applications et systèmes hétérogènes dans des environnements distribués.

63

9 Annexes 9.1 Annexe 1 : Réponse point par point aux remarques sur la

version 1.0 du cahier des charges du portail RESIF En vert : Réponse positive à la remarque En rouge : Réponse négative à la remarque En orange : Simple commentaire sur la remarque En magenta : remarques a discuter avec le COPIL Eléonore STUTZMANN : CS du noeud A « Géoscope » à l’IPGP J’ai lu le document portail web (je ne suis pas impliquée à l IPGP concernant le portail, donc j’ai un avis extérieur.) Je l’ai trouvé assez complet. Ci -‐ dessous quelques propositions ou remarques J’ai une question concernant les méta données: • est -‐ ce qu’ il y aura une page par station quelque part dans laquelle on aura des info sur les réponses instrumentales? Je ne sais pas si c’est indispensable, je m’en sert sur le site géoscope mais surtout pour vérifier le réseau dont j’ai la charge. Si j’ai bien compris c’ est uniquement par le ws-‐resp qu’ on a accès aux meta données (?)

Oui le but est aussi d’afficher les graphiques des réponses instrumentales via la fiche descriptive de la station et de pouvoir récupérer le fichier StationXML, DATALESS et les fichiers RESP Paragraphe 5.9

• concernant l’ accès aux données (p22) dans les critères de sélections j’en rajouterais 2: distance épicentrale min et max et durée autour d’une phase donnée (P ou S par ex)

Ces critères ont été ajouté : Paragraphe 5.11.1

• concernant le tutorial (p33) faire une video me parait compliquépour juste expliquer seismiquery

On verra mais il existe des logiciels permettant de faire rapidement des vidéos pour expliquer le fonctionnement d’interfaces.

• concernant les ws -‐ je n’ ai pas compris si les fonctionalités seront appliquées uniquement aux données physiquement au centre B ouà toutes les données ARCLINK (à dire toutes les données européennes)

Les fonctionnalités seront appliquées uniquement aux données RESIF présentes au nœud B. Au moins dans cette première version du portail.

-‐ je trouve que ws-‐stat (les stat) devraient être ouvertes

64

A discuter avec le COPIL -‐ concernant ws-‐seismicnoise courbes de bruit, je croyais qu’ on avait convenu que chaque noeud A gère les PSD de son réseau. Dans ce cas ce ws devrait etre decentralisé dans les noeuds A. Sinon c’est un double travail puisque de toutes façon les noeuds A les calcule puisque ils valident les données.

Il a été prévu que le Nœud B fournirait les courbes de bruit par webservice. Cela permettra d’avoir des courbes de bruit homogène pour toutes les stations. Il n’a pas été prévu que les nœud A fournissent des courbes du bruit au portail, et il n’est pas sûr que chaque nœud A puissent développer et maintenir des webservice permettant au portail de récupérer les courbes de bruit.

Marie Calvet, Matthieu Sylvander, Alexis Rigo Commentaires généraux

• -‐ Attention les OSU ne sont pas les seuls organismes à fournir des données qui seront distribuées par RESIF. C’est particulièrement vrai pour l’accélérométrie, la vélocimétrie Large-‐Bande et peut être aussi pour le GPS.

Oui ces partenaires seront ajoutés : Paragraphe 5.7

• -‐ Si le portail Web doit aussi distribuer les données GPS, le document n’explique absolument pas si le schéma actuel pourra être modifié facilement étant donnée que les données comme les besoins utilisateurs seront très différents . La page d’accueil (telle qu’elle est proposée actuellement) est très orientée « Sismologie ». De plus, les données GPS française sont actuellement distribuées soit par Nice (GeoAzur) soit par le RPG de l’IGN. Le ReNaG devrait peut être bénéficier de plus de moyens pour fonctionner de façon optimale mais on peut s’interroger sur la nécessiter de créer un troisième portail Web pour les données GPS. Le site de l’IGN distribue toutes les données françaises. Peut-‐on envisager que les données GPS soient distribuées par RESIF en renvoyant par un lien sur les sites ReNaG et IGN ?

Pour le moment le portail est très axé sismologie, c'est ce qui avait été demandé, les données GPS seront intégrées dans un second temps. L'architecture du portail basée sur les webservices à pour but de faciliter son évolution et de permettre l’intégration de nouvelles fonctionnalités. En basant le portail sur les webservices l’objectif est de s’affranchir dans les fonctionnalités proposées par le portail de la provenance des données. Quand les données et métadonnées GPS seront disponibles on peut donc très bien envisager d’aller récupérer ces données par webservice dans d’autres organismes qu’au nœud B.

• -‐ Comment va se faire la transition avec les portails Web existants comme par exemple BDSis (http://bdsis.obs.ujf-‐grenoble.fr/BDsis/) qu’on utilise actuellement pour accéder aux données RAP, ou Phosphore ?

En ce qui concerne les portails existants ils resteront en place jusqu'a la mise en ligne d’une version portail RESIF fournissant au moins les mêmes services. Ensuite le portail Fosfore sera arrêté. Concernant les portails des instituts, chaque institut est libre de faire ce qu'il lui

65

plait !! Bien que le but du portail RESIF soit de fournir des fonctionnalités qui répondent aux besoins du plus grand nombre, il restera peut être dans chaque institut des fonctionnalités bien spécifiques que ceux-‐ci souhaitent conserver.

• -‐ Le document ne mentionne aucun planning des réalisations ! Il paraît important que le

développement du portail Web se fasse en phase avec celui du SI-‐RESIF et de RESIF-‐CLB. • -‐ Le document ne mentionne pas non plus de plan de charge. Est-‐ce que l’IPGP dispose du

personnel compétant pour réaliser ce portail Web ou faudra-‐t-‐il faire appel à des sous-‐ traitants spécialisés dans la réalisation de ce type de produit ?

Le plan de développement avait été supprimé de ce cahier des charges à la demande du COPIL. Un plan détaillé du planning de développement avec les ressources demandées sera fourni dans la prochaine version du cahier des charges.

Paragraphe 2.2 : Public visé

Quel public précisément est visé quand on parle de "la TGIR RESIF"? Dans les utilisateurs divers, rajouter les scolaires. Dans les OSU, nous sommes submergés de demandes de la part de lycéen pour des TPE. Ce portail (en plus du site web RESIF proprement dit) pourrait largement répondre à beaucoup de ces demandes.

Selon le document de spécification de besoin de portail web établi par le COPIL en mai 2012, « Le contenu des pages Web RESIF destiné au grand public ne sera pas traité dans ce document. »

Paragraphe 4 : Page d’accueil Pour le contenu de l’onglet "5 dernières actualités" , des informations du type « station TOTO en panne » sont-‐elles vraiment utiles sur la page d’accueil de ce portail ? Pour les "5 derniers séismes d'un intérêt particulier" qui définira cet intérêt ? Est-‐ce qu’une carte et quelques sismogrammes récents ne seraient pas plus « sexy » ? S'il faut mettre des actualités, ne faut-‐il pas se limiter à une ou deux (pour éviter que certaines soient affichées alors qu’elles sont périmées)? Toujours sur la page d’accueil, le terme « SeismiQuery RESIF » n’est pas du tout explicite en français peut-‐on envisager de le remplacer par "inventaire des stations et des données " (???). En anglais, c'est moins gênant, les visiteurs seront tous sismologues.

Le portail est un portail d'accès au données et donc je pense que les infos impactant les données et stations dans les actualités sont vraiment nécessaires ; bien entendu si une fois en place on s’aperçoit que la section des actualités n’est pas assez vivante on reverra son contenu.

Pour les séismes d'un intérêt particulier les règles seront à définir par le COPIL et les scientifiques mais par défaut on peut imaginer un genre de règle type : séismes mondiaux > 6,5 / séismes européens > 5,5 / séismes francais > 4

Pour le terme « SeismyQuery » on essaiera de trouver un équivalent français, dans le cahier

des charges nous continuerons a employer ce terme afin que tout le monde comprenne de quoi il s’agit.

Paragraphe 5.7 : Afficher les descriptions des OSU et les réseaux

66

Le document ne mentionne que les OSU comme partenaires de RESIF et donc comme pourvoyeurs de données. Or il existe des partenaires comme le BRGM et le L ;G qui participe à RESIF en tant qu’opérateurs. Si les données acquises sont distribuées par RESIF il faut qu’ils apparaissent au même titre que les OSU. La situation se présentera pour les données LB et les données accélérométriques. Le BRGM par exemple supervise une quinzaine de stations officiellement RAP. Actuellement, le RAP distribue aussi des données acquises par des réseaux associés comme le RAS-‐CGMA (Antilles), le RAS-‐LDG ou encore le RAS-‐BRGM. Il faudrait définir la notion de « Réseaux virtuels ».

Oui ces partenaires seront ajoutés : Paragraphe 5.7 La notion de réseaux virtuels sera mieux définie : Paragraphe 5.8

Paragraphe 5.8 : Visualiser les stations

Onglet « Information de site » : Pour les stations accélérométriques il faudrait que des informations spécifiques apparaissent telles que : station au rocher ou au sédiment, Vs30, champ libre,... Comment seront inclus les sites multi-‐capteur comme par exemple les bâtiments ou les forages ? Onglet « acquisition » : il faudra préciser si la station fonctionne sur un mode continu ou déclenché. Il y a encore beaucoup de stations déclenchées et il en restera encore pendant quelques années. Il pourrait être intéressant de pouvoir exporter les informations basiques concernant les stations telles que localisation, date de mise en service, type de capteur, conditions de sites,... sous un format ASCII pour permettre aux utilisateurs de faire leur propre carte.

Oui nous allons ajouter toutes ces informations spécifiques au stations accélérométriques dans la mesure ou le nœud B dispose de ces informations : Paragraphe 5.9

Concernant l’export au format ASCII, cela n’est pas nécessaire à ce niveau là. Ces informations pourront être récupérées par webservice dans le fichier StationXML, il sera expliqué comment y accéder simplement

Paragraphe 5.9 : SeismyQuery RESIF Paragraphe 5.9.1 : Possibilité de télécharger un fichier correspondant à la sélection ?

Oui le portail proposera cela : Paragraphe 5.10.1 Paragraphe 5.9.2 :

• -‐ Prévoir un critère de sélection sur le type de données : déclenchées et/ou continues. Prévoir de rajouter des critères de sélection spécifiques au RAP (PGA, etc ...)

Ces critères seront ajoutés : Paragraphe 5.10.2 et 5.11.4 • -‐ Il n’est pas clair dans ce paragraphe si on pourra visualiser les données disponibles sur

l’ensemble des stations préalablement sélectionnées ou si cette visualisation devra se faire station par station.

Cette visualisation se fera sur l’ensemble des stations sélectionnées

• -‐ Ajouter la possibilité de télécharger le tableau des données accessibles. Oui cela sera ajouté : Paragraphe 5.10.2

Paragraphe 5.10 : Accéder aux données Temps réel :

-‐ Accès temps-‐réel : on ne comprends pas bien la philosophie. Si la fonctionnalité correspondante doit "décrire comment y accéder au noeud B", pourquoi ne pas pointer directement sur le web-‐service chargé de réaliser cet accès, sachant que pour toutes les autres fonctionnalités ce sera le cas (elles pointent toutes sur des web-‐services du noeud B) ?

67

Les données en temps réel ne seront pas accessibles par un des web-‐services mais par le protocol SeedLink. Le but est d’expliquer comment se connecter au serveur seedlink publique de RESIF

Données validées : -‐Il faudrait indiquer explicitement que la sélection des données sur une période permet d’accéder aux enregistrements en continu.

• -‐ Etape 1 : Rajouter des critères accélérométriques tel que le PGA par exemple. Oui, cela sera dans une fonctionnalité spécifique aux données accéléromètriques : Pagaraphe

5.11.4 • -‐ Etape 1 : Actuellement il existe plusieurs catalogues de sismicité. Sur quel catalogue se

basera cette recherche d’évènements. Ce catalogue doit couvrir la sismicité française mais aussi la sismicité mondiale. Est-‐ce qu’il y aura un catalogue RESIF au moins pour la sismicité française ? Dans tous les cas, il faut que les utilisateurs connaissent l’origine des informations « évènements » (qui a fait la localisation et le calcul de la magnitude).

L’objectif est de permettre aux utilisateurs de se connecter a différents catalogues. Les catalogues devront être accessibles par webservice et retourner du format QuakeML. Pour le moment IRIS, le CSEM proposent ces webservices. Le travail est en cours au RéNass afin de proposer un webservice retournant leur catalogue au format QUakeML.

• -‐ Etape 2 : Il faut être définir plus précisément la notion de fenêtre. Il ne faut pas limiter en particulier la longueur de la fenêtre.

• -‐ Rajouter la possibilité de télécharger sous la forme d’un fichier l’ensemble des évènements et stations selectionnées.

OK cela sera possible. Paragraphe 5.11.1, 5.11.2 et 5.11.4 • -‐ Fonctionnalité "accéder aux données arclink", (5.10.3.2.) Il est fait référence au noeud EIDA

de RESIF. De quoi s'agit-‐il ? Le but est d’expliquer comment se connecter via le protocole ArcLink au nœud EIDA de RESIF

Paragraphe 5.11 : Afficher la sismicité

• -‐ Etablir un lien vers le BCSF le plus haut possible dans l'arborescence. Rendre possible la recherche dans le catalogue par région administrative (région, département, commune), ainsi que la représentation sur carte des limites administratives.

Pour le moment cela n’est pas prévu dans le webservice d’accès aux différents catalogues de sismicité

• -‐ Lien vers l’interface de récupération des données: Est-‐ce qu’il y aura la possibilité de revenir sur la carte des évènement pour ajouter des évènements dans la requête ?

Oui cela sera possible. Paragraphe 5.11.1 • -‐ Tableau avec la liste des évènements : rajouter la possibilité de le télécharger en format

ASCII. Oui cela sera ajouté. Paragraphe 5.11.1 et 5.12.1 • -‐ Fonctionnalité "Séismes d'un intérêt particulier" : difficile à nourrir... mais nécessaire.

Incruster la mention RESIF en transparence dans chaque document, pour s’assurer que les sources soient correctement citées .

A discuter cette notion de séisme d’intérêt particulier avec le COPIL. -‐

Paragraphe 5.13 : Les modalités de contact • -‐ Le document ne précise pas comment seront traitées les questions des utilisateurs : une

seule personne receptionne les messages et redirige vers l’interlocuteur RESIF le plus compétente en fonction du type de question ? Peut être qu’il faut prévoir un panel de questions types ou des critères pour trier le type de questions ?

Oui cela reste à définir, une section de type FAQ sera ajoutée : Paragraphe 5.15 • -‐ Est-‐ce que RESIF s’engage sur un délai de réponse ?

68

A voir avec le COPIL

69

Anne Paul : CS du nœud SISMOB Voici un retour sur la proposition de portail SI-‐RESIF de l'IPGP. J'ai 2 remarques (critiques) majeures et une série de mineures. 1) Ce document est beaucoup trop généraliste et ne tient aucun compte des spécificités/besoins de chacune des composantes de RESIF-‐SI.Il n'est fait qu'une description très générale des fonctions d'un portail de distribution de données sismologiques large-‐bande continues issues de stations permanentes. Il n'est pas adapté à la distribution de données d'expériences temporaires. Je pense d'ailleurs qu'il est encore moins adapté à la distribution de données accélérométriques, ou issues des observatoires volcanologiques. • Mon avis est qu'il faut, dans le portail, séparer la distribution des données des réseaux permanents RF et RD, de celle des données Géoscope (mondiales), de celles des données Sismob, RAP ou des obs. volcanologiques. Je verrais bien un onglet par type de donnée.Pour Sismob, il me semble que les requêtes portent le plus souvent sur une manip (=un code réseau) complète, ce qui n'est probablement jamais le cas pour les réseaux permanents. Je mets d'autres remarques de détail sur ces spécificités plus loin.

On créera une fonctionnalité spécifique à l’accélérométrie : Paragraphe 5.11.4 2) Le document ne décrit qu'une suite de fonctions. Il ne ressemble en rien à un cahier des charges et ne pourrait pas être transmis tel quel à un sous-‐traitant.Par exemple, les rôles respectifs du portail et du noeud B ne sont pas explicités. Pour la distribution de données, le portail n'est qu'une série de pages web permettant d'acceder à des fonctionnalités installées au noeud B.Le portail doit aussi donner des informations sur le projet.Il y a dès la p. 6 une erreur dans la fonction principale du portail. Le noeud B fait l'archivage et la distribution, et le portail est la page web d'accès aux données du noeud B et aux informations sur RESIF.Le document n'est en rien technique. La conclusion que je tire de ces 2 premières critiques est que le boulot est à reprendre intégralement. Il aurait par exemple au moins fallu reprendre les pages web de distribution des données qui existaient dans Fosfore + celles du site du RAP.

Par définition, ce document présente un cahier des charges fonctionnelles dont le but n’est pas d’être transmis à un sous-‐traitant mais de définir en détail les différentes fonctionnalités du portail et de donner un plan de développement.

Oui il manque des informations nécessaires pour l’accélérométrie. Une fonctionnalité

spécifique à l’accélérométrie sera ajoutée : Paragraphe 5.11.4 Autres remarques génerales: -‐ il devient urgent de développer tout cela, ou au moins un 1ère version, très rapidement; Ou sont les deadlines, délivrables etc?

A la demande du COPIL cela avait été supprimé du cahier des charges, mais ce planning avec les délivrables sera ajouté dans la nouvelle version du cahier des charges

-‐ il manque une hiérarchisation des taches; pourtant, certaines fonctions sont beaucoup plus importantes que d'autres (l'accès aux données). C'est une priorité pour RESIF et il ne va pas falloir attendre que le développement du portail soit terminé pour rendre les données accessibles. -‐ comment sont testées les 1ères versions du portail? par des utilisateurs-‐tests? -‐ développer simultanément les pages en français et en anglais est important; il ne va pas falloir développer le site dans tout son détail en français puis laisser trainer la traduction en anglais pendant des années Remarques mineures: -‐ p. 13: bizarre cet affichage de la description des OSU qui oublie les autres fournisseurs de données de RESIF-‐SI comme le LDG. La liste des fournisseurs de données est certes importante, mais là, c'est peut-‐être un peu lourd (et incomplet de surcroit).

Oui il faudra inclure la description des autres fournisseurs de données : Paragraphe 5.7

70

-‐ p. 15-‐16: "visualiser les stations": la fiche descriptive de station n'a pas de sens ni d'utilité pour une station temporaire. Elle en a plus pour un réseau temporaire donné, et on pourrait alors imaginer indiquer au moins les noms, instituts, emails des PI, comme je le fais quand je demande un code fdsn.

Ces infos seront disponibles dans la description du réseau -‐ p. 23: visualisation des données en accès restreint. Je pense que ça ne concerne que Sismob non? Il est proposé d'afficher les stations dont les données sont en accès retreint de manière différente des stations en accès ouvert; Mais pour Sismob, c'est un dataset complet qui est en accès restreint ou ouvert, avec un code FDSN particulier. Pas besoin d'affichage par station.

D’autres fournisseurs des données potentiels ont exprimé le possible besoin d’avoir un accès restreint (par exemple les campagnes OBS). Il est aussi envisageable d’avoir des jeux des données mixtes ou seulement une partie sera restreinte. Il est donc préférable de définir cette fonctionnalité d’une manière assez générale.

-‐ p. 38: l'affichage des statistiques par OSU ne me semble pas avoir beaucoup de sens pour un projet collectif comme RESIF. De plus, il n'en a aucun pour les réseaux temporaires

Ce besoin des statistiques par OSU a été exprimé. Sa pertinence doit être discutée avec le COPIL

-‐ p. 42: je comprends peut-‐être rien, mais je m'étonne de ne pas voir là les connexions avec le noeud B. Et il y a un module webservices alors qu'un certain nombre seront installés au noeud B. peut-‐être que la réponse est p. 43?? -‐ p. 43: ça fait bizarre que la liste des web services à mettre en place au noeud B apparaisse ici; Si c'est sa place, le document doit être aussi signé par les gens du noeud B non?

Effectivement la spécification des webservices sera faite en coordination avec le nœud B. Une réunion de coordination est prévue entre le groupe de portail le nœud B et le COPIL.

71

Eric BEUCLER - Université de Nantes voici mes quelques suggestions et idées qui me sont venues en lisant le document. Il est clair et bien écrit, c'est agréable.

1. Je n'ai pas vu dans le document la possibilité d'avoir une rubrique de type "FAQ" qui serait qqch de distincte de l'aide en ligne. On pourrait y trouver, par exemple, des explications simples sur les magnitudes ou des documents de vulgarisation pour éviter trop de questions redondantes de la part du grand public. Oui cela sera ajouté son contenu sera à définir par des scientifiques. Paragraphe : 5.15

2. Ne peut-‐être pas limiter à la description détaillée des stations (partie 5.8), la possibilité d'avoir la version PDF (donc imprimable) mais la généraliser à toutes les pages de type documentation ou article. Oui, cela sera mis en place : Paragraphe 5.1

3. Pensez-‐vous qu'il serait possible de réserver une place pour les communes et les organismes

(ou particuliers) qui hébergent les stations afin qu'ils puissent, à leur tour, valoriser leur action de leur coté. Pour le moment cela n’est pas prévu dans cette première version du portail.

4. Je sais que cela prendrait du temps mais serait-‐il possible d'ouvrir le site à l'Europe frontalière ? Je veux dire par là d'avoir des traductions (au moins pour les parties grand public) en allemand, espagnol et italien ? Si RESIF veut être original par rapport aux autres réseaux cela peut peut-‐être se faire à travers la pluralité linguistique. Mais je sais que c'est du boulot !! Pour le moment seul le français et l’anglais sont prévus mais nous pouvons faire en sorte

qu’au niveau technique l’ajout dans le futur d’autres langues soit facilement intégrable. Par contre, la traduction demandera des moyens supplémentaires ; à voir avec le COPIL si c’est réaliste

5. Serait-‐il possible d'avoir une interface avec les organismes de publications (ISIweb ??) pour voir les articles parus avec les data de RESIF (histoire de simplifier les procédures d'évaluations dans le futur) ? Ca dépasse ce que a été proposé dans le document des spécification techniques

6. Sera-‐t-‐il possible d'utiliser le SeismiQuery en shell comme cela est possible avec IRIS via un

terminal et des scripts (voir http://www.iris.edu/SeismiQuery/bin/sql.pl) Pour le moment cela n’est pas prévu dans cette première version du portail.

7. Pour les membres des OSU serait-‐il possible d'interfacer le portail avec le logiciel de base de

données de Martin Dutil ? Histoire d'avoir tout l'historique en se connectant, mais c'est peut-‐ être déjà prévu (je n'ai pas forcément réussi à trouver l'info). Là non plus ce n’est pas prévu, mais la plupart des infos présentes dans le logiciel développé

par Martin serviront à construire le StationXML et se retrouveront au final au nœud B et donc seront présentées dans la fiche de la station sur le portail.

8. Peut-‐être penser à obliger les gens à s'authentifier pour poster une question et faire en sorte que la procédure d’authentification soit suffisamment lourde pour dissuader les simples visiteurs mais pas les chercheurs ni les utilisateurs réguliers. C'est juste pour éviter d'avoir 10000 questions lorsqu'il y aura un séisme de magnitude 4 quelque part en France. Afin de simplifier l’utilisation du portail et de faciliter l’accès aux données, il avait été décidé que les utilisateurs n’auraient pas à s’identifier sur le portail web RESIF. Les portails et sites

72

web nécessitant une authentification rebutent bien souvent les utilisateurs. Bien entendu

cela aura pour conséquences des requêtes ou des questions d’utilisateurs un peu farfelues… Mickael Langlais : CT du CLB Voici mes commentaires/remarques concernant le document que tu nous as transmis. J'ai laissé en copie les personnes d'ISTerre et j'ai ajouté Nathalie Cotte et Gael Janex a qui j'ai diffusé ton document. Paragraphe 3, page 8 : * Accès aux données / données validées : peut être préciser données continues et événementielles.

=> Oui cela sera précisé :Paragraphe 3 Paragraphe 5.8, page 16 : * Onglet Information sur le site : le type de sol est utile pour le RAP

Oui cela sera ajouté : Paragraphe 5.10.1 * Onglet Acquisition : avoir accès au numéros de série capteur et numériseur est utile

Oui cela sera ajouté si cette information est disponible au nœud B : Paragraphe 5.10.1

Paragraphe 5.9.1, page 18 : * selection des informations : pour le RAP ajouter type de sol et sous réseaux (ie : RAP-‐EOST, RAP-‐ UBO...)

Oui cela sera ajouté dans la fonctionnalité d’accès aux données accéléromètriques : Paragraphe 5.11.4

Paragraphe 5.10.2, page 22 et 23: * une pré-‐selection d’événements récents pourrait etre proposé en plus (cf BDsis) * dans la partie sélection des stations, une sélection par sous réseaux serait appréciable pour le RAP

A voir comment gérer les sous-‐réseaux avec le nœud B. Mais cela ne devrait pas poser de problèmes, il faudra sans doute créer des réseaux virtuels pour chaque sous-‐réseaux.

* format des données : il faut préciser si le SAC et le ASCII sont convertis (m/s2, cm/s2, nm/s ?) ou pas. Et si les entetes seront renseignés.. Bien entendu il faudrait que cela soit le cas pour les données accéléro.

Il faudra voir avec le nœud B comment préciser cela dans la fonctionnalité d’accès aux données accéléromètriques : Paragraphe 5.11.4

Paragraphe 5.11.1, page 29 : * pour la récupération des catalogues, n'y a t il pas également un web service LDG ?

Pour le moment il n’y a pas de webservice du catalogue LDG directement disponible au format QuakeML. Cependant je pense que le catalogue du CSEM inclut les évènements du catalogue LDG.

Mais si toutefois le LDG propose un webservice de son catalogue au format QuakeML, celui-‐ci pourra être facilement intégré au portail.

Paragraphe 6.3, page 45 : * ws-‐event : seulement le catalogue du Renass ? Cela ne me semble pas compatible avec les besoins du RAP qui utilisent des catalogues différent (RSSP, Sismalp, Antilles, IRSN/Magnitude....). L'aspect accès aux données événements est essentiel pour le RAP (Mathieu me corrigera le cas contraire). Il faut donc préciser et détailler cet aspect. Les catalogues d’évènements pouvant être intégrés dans le portail dépendent le leur disponibilités. Afin d’etre accessibles via le portail RESIF ceux-‐ci devront être accessibles par webservice au format

73

QuakeML. Pour le moment les catalogues d’IRIS (NEIC), du CSEM et prochainement du RéNass sont disponibles. Mais il faudra faire en sorte que le portail RESIF puisse proposer l’accès via ses interfaces aux catalogues type (RSSP, Sismalp, Antilles, ) * beaucoup de webservices à monter au noeudB ??

Il y a 3 webservices principaux respectant les « normes » FDSN qui vont être installés au nœud B. Ces webservices permettront de fournir la plupart des informations nécessaires au fonctionnement du portail, cependant d’autres webservices qu’il reste à définir devront être

implémentés. Les remarques concernant l’accès aux données événements pour le RAP correspondent en partie je pense à un besoin pour les stations sismologiques OMIV (puisque OMIV utilise aussi BDsis). Sinon vivement la mise en ligne de ce portail, car cela semble prometteur.

74

Gael Janex Un des besoins d'OMIV est de distinguer, dans le réseau MT, les différents glissements de terrain étudiés. Spécifiquement nous aurions besoin d'un lien direct par site vers le portail RESIF, focalisant sur les stations du site choisi. En en parlant avec Mickaël, je me rends compte que le meilleur moyen de faire ça (et qui en tous cas serait utile pour d'autres réseaux) est d'avoir un filtrage géographique des stations. Ce filtrage géographique pourrait être inclus dans l'adresse http, ce qui permettrait de tomber directement sur les stations du glissement de Séchilienne par exemple. Mickaël m'a montré que le portail webdc.eu permet ça... et il m'indique que cette demande rejoint une des demandes du RAP pour isoler le RAP-‐Alpes du réseau FR...

Il semble que cela pourra se régler avec le mécanisme des réseaux virtuels. Il suffira de créé des réseaux virtuels pour chaque site d’OMIV. Sinon, cette demande devrait être spécifié plus précisément.

75

Philippe Guéguen : CS du nœud B Ci-‐joint en complément des remarques de Mickael quelques points supplémentaires directement en note dans le texte. Une remarque générale: rien n'est prévu pour le RAP, mais je suis persuadé aussi que rien n'est prévue pour des données volcanologiques.

Les besoins spécifiques des observatoires volcanologiques dépassent largement ce qui peut se faire dans RESIF. Pour l’instant, il est prévu de distribuer à travers le SI RESIF les données sismologiques provenant de ces observatoires. Pour les données accélérométriques, ça se fera comme pour le RAP. Pour les données vélocimétriques, les fonctionnalités générales prévues dans le portail seront suffisantes.

J'avais déjà mentionné le besoin d'avoir des requêtes possibles spécifiques au RAP sur des événements locaux/régionaux: dans le document portail, dans le questionnaire et rien n'a été pris en compte. Voici donc encore une fois les mêmes remarques.

Oui il manque des informations nécessaires à l’accélérométrie. Une fonctionnalité spécifique à l’accélérométrie sera ajoutée : Paragraphe 5.11.4

Il n'y a pas non plus de fonctions claires sur certaines relations portail noeud B ou portail noeud A: je ne sais pas si c'est le document où cela doit être discuté.

Nous ne comprenons pas ce qu’est « une fonction claire sur certaines relations portail noeud B ou portail noeud A »

76

Mathieu Causse : CS du nœud A RAP Le document « Portail Web RESIF : Cahier des charges fonctionnel » a été diffusé aux membres du bureau scientifique du RAP, aux responsables des réseaux RAP régionaux, ainsi qu’aux sismologues de l’équipe Risque d’ISTerre. Les commentaires qui suivent inclus une synthèse des réponses obtenues. 1. Commentaires d’ordre général • • Le document actuel est plus orienté sismologie d’observatoire que mouvements forts. Les besoins spécifiques à l’accélérométrie ne sont pas bien pris en compte (Cf. fonctionnalités du portail de distribution actuel BDsis). Le RAP à pour vocation de distribuer en particulier des données événements accélérométriques, en des formats spécifiques (SAC, ASCII) et en unité S.I. (cm/s2). Le RAP s’inquiète de la visibilité des réseaux régionaux, qui constituent l’ossature du réseau et assurent la maintenance des stations.

Oui nous allons prendre en compte ces remarques et ajouter une fonctionnalité dédiée à l’accélérométrie : Paragraphe 5.11.4

2. Commentaires spécifiques • Page16,§5.8: o Pour la sélection des stations, rajouter le critère suivant : réseau régional RAP.

A voir comment gérer les sous-‐réseaux avec le nœud B. Mais cela ne devrait pas poser de problèmes, il faudra sans doute créer des réseaux virtuels pour chaque sous-‐réseaux.

o Fiche descriptive du site : pour les métadonnées sur le site, rajouter au minimum ce qu’il y a actuellement sur le site du RAP (type de sol ; classe de site ; champ libre ou non, certaines stations étant en forage ou dans des bâtiments), et à moyen terme ce qui sera préconisé dans le cadre des initiatives actuelles (groupe de travail RAP caractérisation des sites, USGS, Orfeus/EMSC/GFU/ETH).

Ces informations seront indiquées dans la fiche station. Toutes les informations fournies par le nœud B via le format StationXML seront visibles dans la fiche station : Paragraphe 5.9

o Fiche descriptive du site : rajouter le réseau régional en charge de la station pour les stations RAP.

Oui nous allons essayer de rajouter cette notion de sous-‐réseau, surement en créant des réseaux virtuels pour ces sous-‐réseaux. A voir avec le nœud B comment faire.

• Pages 17-‐18, § 5.9.1 : o « Visualiser l’inventaire des stations » : inclure une recherche sur les conditions de site pour les stations RAP (type de sol, classe de sol, champ libre, stations en forage ou bâtiments), et par réseaux régionaux.

Oui nous allons essayer de rajouter ces critères : Paragraphe 5.10 • Pages 19-‐20, § 5.9.2 : o « Visualiser l’inventaire des données » : ajouter un critère d’affichage en fonction des conditions de site, de la distance épicentrale, et des mouvements du sol enregistrés (PGA).

Oui nous allons essayer de rajouter ces critères : Paragraphe 5.10 • Page 21-‐23, § 5.10.2 Commentaire général : de nombreuses stations du RAP ne sont pas en mode continu et fonctionnent en mode « déclenché ». Ainsi, le terme « accès aux données validées » peut prêter à confusion pour les utilisateurs des données RAP, qui vont principalement rechercher des données événements.

77

Pour les données accélérométriques RAP, les données événements (SAC, ASCII) doivent être en unité S.I. (cm/s2), avec les entêtes des fichiers SAC renseignées.

A discuter avec le nœud B et le COPIL, mais ca devrait être le cas. « Première étape : sélection du mode de récupération des données » : la base de données événements actuelle du RAP comporte des données triées et non triées (Cf. protail de distribution BDsis). Plus précisément, l’utilisateur doit pouvoir choisir les données événements accélérométriques selon 3 critères : « données non triées », « données triées incomplètes », « données triées complètes ». Une présélection d’événements récents peut également être proposée.

Oui nous ajouter ces critères dans une fonctionnalité dédiée à l’accélérométrie : Paragraphe 5.11.4

Les critères suivants peuvent être ajoutés : type de sol, classe de site, distance épicentrale, valeurs de paramètres du mouvement du sol (PGA), réseau régional, et type de capteur (qui doit être un critère de l’étape 1).

Oui nous allons prendre en compte ces remarques et ajouter une fonctionnalité dédiée à l’accélérométrie : Paragraphe 5.11.4

78

Avis de l’EOST concernant le Cahier des charges fonctionnel Du Portail WEB RESIF(v1.0) Préambule Ce document synthétise les avis des personnes de l’EOST mentionnées ci dessous. Ces remarques ont été émises à titre individuel ou en tant que Responsable d’une composante Du SNO Sismologie (BCSF, RéNaSS, RLBP). Alessia Maggi, Marc Schaming, Fabien Engels, Maxime Bes de Berc, Cécile Doubre, Sophie Lambotte,Marc Grunberg, Christophe Sira, Antoine Schlupp, Jérôme Vergne Malgré les remarques formulées ci dessous, nous souhaitons mettre en exergue la qualité du document fourni. Rôle et place du portail WEB Le document ne nous semble pas suffisamment précis quant au(x) public(s) visé(s) et aux objectifs de Ce portail vis-‐à-‐vis de chacun de ces publics.(§2.2) Nous considérons que le portail WEBRESIF doit répondre prioritairement, et quasi exclusivement, aux Besoins des scientifiques désireux de récupérer des données fournies par les instruments de l’IR RESIF. Et en particulier, le portail WEBRESIF ne se destine pas à des «utilisateurs divers (passionnées, curieux,...)» et les «centre de données et centres de détection/alerte des séismes» seront surtout utilisateurs des web services développés au noeudB. D’une manière plus générale, le portail WEB RESIF doit répondre à un besoin auquel ne Répondent pas déjà d’autres pages/portail web existants ou en cours de développement. Notamment :

• • Le portail WEB RESIF n’a pas vocation à distribuer des catalogues de sismicité. Cette distribution est du ressort des services/organismes en charge de leur création. Pour la France métropolitaine cette activité est une des missions du BCSF/RéNaSS en collaboration avec le CEA-‐-‐-‐LDG (en charge de l’alerte).

Le portail web ne distribuera aucun catalogue de sismicité mais utilisera dans ses interfaces les catalogues d’évènements disponibles par webservice au format QuakeML.

• • Il faut éviter de dupliquer trop d’informations entre le portail WEB RESIF et les pages/portails des différents services d’observations impliqués dans RESIF (notamment pour faciliter les mises à jour). Il faut se poser la question de la nécessité de maintenir des pages pour chacun de ces réseaux. Les informations qui y sont contenues pourraient être intégrées dans la page WEB RESIF et le portail WEB RESIF. Le responsable du RLBP est favorable à une telle évolution (pour le RLBP) mais l’aval de tous les autres responsables est nécessaire. Cette question dépasse les « compétences » de l’équipe du portail et doit être tranché par le COPIL et/ou le Comité Directeur de RESIF. Le contenu de ce document de cahier des charges

fonctionnel du portail accès aux données a été cadré par le « document de spécification de besoin portail web » validé par le COPIL en mai 2012. Nous ne pouvons pas ici nous

prononcer sur le futur des autres sites web associés à différents éléments de RESIF. Comme il est écrit dans la réponse précédente, ce portail ne distribuera pas l’information sur

la sismicité mais utilisera l’information fournie par des organismes habilités, dont le BCSF. Il n’y aura donc pas de duplication avec le BCSF.

79

Nous synthétisons dans le tableau ci-‐dessous notre vision du rôle des principales pages web associées à RESIF:

Page WEB RESIF Portail WEB RESIF Portail BCSF/RéNaSS* Sites des services / réseaux

www.resif.fr www.resif.fr/portal www.franceseisme. fr et renass.u-‐ strasbg.fr

Sites du RAP, Sismob, Geoscope, RLBP ...

Fournir des informations d’ordre général sur l’IR RESIF, ses composantes ses partenaires, ses objectifs, son fonctionnement ...

Faciliter l’accès aux données des instruments de l’IR RESIF

Fournir des données et de l’information sur la sismicité et ses effets (intensité) en France.

Fournir des informations détaillées sur les réseaux comme composantes des SNO (objectifs scientifiques, partenaires, équipement, ...)

Scientifiques, décideurs, grand public

Scientifiques travaillant sur la forme d’onde

Scientifiques travaillant sur les catalogues et les intensités, décideurs, grand public

Scientifiques, décideurs, personnel des réseaux

• NB :Des informations sur la sismicité, en particulier les localisations rapides, sont également disponibles sur la page web du CEA-‐DASE (www-‐dase.cea.fr)

Interaction portail WEB RESIF et portail BCSF/RéNaSS Note : Le site central du RéNaSS édite depuis plusieurs années un bulletin de la sismicité métropolitaine. D’autre part, le BCSF a pour mission de produire le catalogue de référence sur la sismicité à l’échelle nationale (en intégrant les bulletins RéNaSS et LDG en particulier). Une évolution est en cours pour réunir les activités du site central du RéNaSS et du BCSF, avec notamment comme objectif de proposer un unique portail fournissant une information complète sur la sismicité en France (données paramétriques et macrosismiques, catalogues, informations générale sur la sismicité, information scientifique sur certains séismes, ...). -‐ Affichage de la sismicité (§5.11.1) : o Le localisations BCSF/RéNaSS doivent être proposées pour la sélection d’évènements en France métropolitaine. Le bulletin édité par le BCSF/RéNaSS sera rapidement disponible au format quakeMl. o La sélection d’un événement sur le portail WEB RESIF doit proposer un lien vers la page de cet événement sur le site du catalogue correspondant (BCSF/RéNaSS, CSEM, NEIC, ...), qui sont, eux, en mesure de fournir le quakeMl associé et d’autres informations.

Oui ce lien sera proposé dans la description de chaque événement : Paragraphe 5.11.1 et 5.12

o Il faudra sans doute définir une notion de localisation préférentielle entre les différents catalogues. Il est proposé de définir cette localisation en fonction de la zone d’occurrence du séisme : France métropolitaine DOM-‐TOM Zone Euro-‐Med (hors France) Reste du monde BCSF/RéNaSS A définir CSEM NEIC

80

-‐ Séisme d’un intérêt particulier (§ 5.11.2): Le BCSF/RéNaSS rassemble déjà des informations

disponibles pour de tels évènements en France, notamment via des liens vers des documents scientifiques fournies par différents organismes (dont OSU). Il est prévu d’améliorer cette fonctionnalité dans le futur. Un lien vers le portail WEB RESIF pourra être ajouté pour récupérer les volumes de données préfabriqués pour ces évènements.

Pour les séismes d’un intérêt particulier concernant la France peut être que le portail RESIF pourrait présenter la même liste de séismes que le BCSF/RéNaSS. Il faudra définir ca avec le COPIL.

Description des OSU et des réseaux (§5.7)

• -‐ La présentation des partenaires est trop restrictive. Certains réseaux intégrés à RESIF (RLBP et RAP notamment) impliquent d’autres organismes que les OSU (CEA, BRGM, ...) qui ne sont évoqués nul part.

Oui cela sera corrigé : Paragraphe 5.7

• -‐ (§5.7.1) La présentation des différents partenaires (OSU, autres organismes) n’est elle pas plutôt à faire sur la page de RESIF et/ou sur les pages des réseaux?

On mettra sur le portail d’accès aux données la description des partenaires fournisseurs des données. C’est important pour la visibilité des ces partenaires mais aussi pour les utilisateurs pour connaître la provenance des données.

• -‐ Il faut faire la distinction entre OSU responsable du fonctionnement d’un réseau et OSU opérateurs d’un ensemble de stations pour le compte d’un ou plusieurs réseaux.

Oui cela sera à préciser dans les fiches de description : Paragraphe 5.7 Visualisation des stations (§5.8)

• -‐ Concernant le RLBP, l’ensemble des informations sur les stations seront incluses dans la base de données des équipements et des stations actuellement développée dans le cadre du projet CLB. Le nœud B ne disposera pas forcement de l’ensemble de ces informations. Il faut donc prévoir une interaction entre le portail WEB RESIF et cette base de données.

Le rôle de portail est de distribuer l’ensemble des données et des métadonnées disponibles dans le nœud B dans les formats et standards internationaux (Station XML). Interfaçage avec les bases des données hors le nœud B n’est pas prévu et sera difficile à maintenir à long terme sans des moyens supplémentaires. Cependant, comme il l’a été discuté récemment, la plupart des informations de la base de données des équipements seront finalement nécessaires pour créer le StationXML d’une station et donc ces informations devront être transmises au nœud B. -‐ Est ce opportun de proposer une sélection des stations en fonction des OSU (ou plus généralement des organismes) opérateurs de stations ?

A discuter avec le COPIL. • -‐ Permettre la récupération du dataless d’une station aux formats seed dataless et

stationxml La récupération du dataless d’une station au format StationXML sera ajouté. Des outils

seront proposés pour convertit un stationXML en DataLESS Paragraphe 5.9 • -‐ La « classe » d’un site est une notion variable suivant les réseaux. Pour le RLBP/CLB cette

classification n’est actuellement utilisée que pour définir le niveau de bruit attendu aux sites prospectés.

81

A discuter avec le COPIL.

• -‐ Eviter de mettre en évidence des éléments pouvant « inciter » au vandalisme des stations (zoom sur la carte, photo de panneaux solaires, ...). Si le portail WEB RESIF est à destination principale de scientifiques, cet aspect est moins critique.

Les informations sur la description des stations seront fournies par les operateurs. A eux de voir ce qu’il faut et ce qu’il ne faut pas montrer. SeismicQuery / Inventaire des données (§5.9)

• -‐ D’où proviendront les commentaires sur l’absence (ou la qualité) de données à une station/canal ?

Fournir ces commentaires pour toutes les futures stations peut devenir une mission insurmontable pour le nœud B et le portail. Leur rôle est plutôt fournir les données disponibles avec une variété des interfaces selon les différents besoins des utilisateurs. A voir avec le COPIL si ce genre de commentaires sera nécessaire.

• -‐ Données validées (§5.10.2) : Il faudra préciser à l’utilisateur ce que sous entend la notion de validation (M ou Q). Cette étape de validation étant à la charge des nœuds A, il faut présenter ces nœuds A pour chaque réseau (localisation, contact, ...) et leur autoriser la mise en ligne d’informations « qualité ».

Oui ces informations sur la qualité des données seront précisées dans la description des données : Paragraphe 5.6

Accès aux données (§5.10)

• -‐ La sélection des données par événement devrait être possible même sur des données non validées

Oui c’est ce qui se passera, lorsque les données validées ne seront pas disponibles les données non validées seront renvoyées. Mais le mécanisme devra être discuter avec le nœud B et le COPIL.

• -‐ Rajouter comme filtre de sélection des évènements le type d’événement (séisme, tir de carrière, rockfall, ...).

Oui ces infos seront ajoutées Paragraphe 5.12 et 5.11.1

• -‐ Données restreintes (§5.10.5) : les PI des données impliquées doivent être consultés Concernant les données restreintes je rappelle qu’il a été précisé que les métadonnées serait

libres et que finalement seules les données en elle meme seraient restreintes. C’est directement avec le nœud B qu’il faudra voir quelles sont les données restreintes.

Statistiques (§5.18.3) • -‐ Est il opportun de présenter les statistiques par OSU/organisme (en tant qu’opérateur de

stations) ? Il faut plutôt privilégier la présentation par réseau. A discuter avec le COPIL

• -‐ Les statistiques doivent être accessibles aux nœuds A et à tous les organismes impliqués

dans un réseau. Oui cela sera le cas

82

Mise en oeuvre • -‐ Quel est le planning d’implémentation du portail WEB RESIF et des différents webservices ? • -‐ Il serait souhaitable d’avoir une mise en opération séquencée du portail WEB RESIF

permettant de disposer, dans un délai relativement court, d’une première version minimaliste. Cet aspect nous paraît crucial pour assurer la visibilité des données RESIF auprès de la communauté scientifique.

Le planning de développement sera présenté dans la version revue du cahier des charges. Dans la mesure du possible on essaiera de livrer le portail sous forme de module : Paragraphe 7

83

Catherine Péquenat : CT RAP et SISMOB Remarques générales Si la réalisation du portail faisait l'objet d'un appel d'offre extérieur à RESIF, les candidats auraient beaucoup de mal à construire une réponse :

• − peut-‐on préciser quel (sont) le où les versions de cahier des charges 'portail RESIF' dont le présent document constituent les spécifications fonctionnelles ?

version 1 • − Il n'y a aucun diagramme des tâches, aucun plan de livaison partiel ou total. A la demande du COPIL celui-‐ci a été enlevé. Le planning de développement sera présenté

dans la version revue du cahier des charges. Dans la mesure du possible on essaiera de livrer le portail sous forme de module. Paragraphe 7

• − Il faudrait peut-‐être identifier plus clairement les parties dont le contenu vont faire l'objet d'un développement collectif (typiquement, tout ce qui sera géré pas un CMS) et les applications typiquement portail (ex stations, seismiquery, ...) car ces fonctionnalités différentes auront des plan de développement différents.

Dans le planning de développement nous distinguons cela. Pour ce qui est donc du contenu nous n’avons pas mis de planning précis pour le moment, car la rédaction des contenus est un travail collectif (nous avons juste précisé que celui-‐ci s’étalera sur toute la durée de projet). Dans le planning de réalisation nous identifions et planifions les applications typiquement portail qui seront réalisées par l’équipe du portail web.

• − Les composants qui existent déjà ne sont pas identifiés comme tels (exemple : l'application 'station') bien que ce qui est proposé soit très largement inspiré de l'existant sur le portail FOSFORE ou sur l'actuel portail temporaire RESIF par exemple. Il faudrait peut-‐être décrire ce qui va être repris.

Rien ne sera repris, le fonctionnement et les technologies utilisées seront complètement différents.

• − Il faut faire attention aux “raccourcis” tels que ceux de l' introduction : les candidats pourraient supposer que le prestataire doit implémenter tous les moyens d'accès aux données, tous les moteurs de requêtes et tout le support de la distribution -‐ ce qui n'est pas le cas. Le noeud B fait cela. Cette articulation est précisée par des schémas page 42 et 43, mais avant, les choses sont assez floues. Il n'est pas non plus précisé que l'infrastructure du noeud B RESIF prend en charge l'infrastructure matérielle et logicielle de base nécessaires aux développements du portail et à sa mise en exploitation – une partie des items de la page 42 ne sont pas à la charge du portail RESIF: gestion des sauvegardes, gestion de l'infrastructure logicielle de base (OS, SGBD, VM, etc) gestion de la sécurité (à préciser), gestion des sources (à préciser?), webservices (le portail les exploite, il n'a pas à les réaliser), certaines interfaces d'accès aux données (arclink, netdc, ...)

Ce sont des choses qu’il faudra discuter à la réunion entre le groupe portail le nœud B et le COPIL.

• − Indépendamment du cahier des charges portail RESIF, les différents réseaux qui constituent RESIF ont à ce jour des portails d'accès à leur données. Le portail RESIF proposé engloble les fonctionnalités des portails FOSFORE et GEOSCOPE, mais pas celles des portails RAP, SISMOB et OMIV.

Nous avons rajouté ces fonctionnalités spécifiques. Paragraphe 5.11.4 Réseaux

84

o Les Observatoires de Sciences de l’Univers o Les réseaux permanents o Les réseaux temporaires o Les réseaux virtuels je ne comprends pas ce découpage : les Observatoires ne sont pas des réseaux.

Oui ce découpage a été revu paragarhe 5.7 et 5.8 Accès aux données o données temps rées continues (non validées) o données continuées validées o Autres interface ==> accès aux données événements ? Les portails actuels des réseaux RAP, de SISMOB, des Observatoires des mouvements de terrain proposent des interfaces d'accès aux données événements et des formulaires de recherche croisées (stations x évenements x réseaux et/ou site) multicritères. Le portail RESIF doit au moins offrir les mêmes fonctionnalités. L'utilisateur doit pouvoir croiser les critères : reseau (site, réseau réginal) x station x événements x type de données.

C’était le cas dans le cahier des charges version 1.0, cela se faisait en passant d’abord par la fonctionnalité sismicité afin de sélectionner des évènements. Cependant afin que cela soit plus clair la structure a été remaniée, l’accès se fait via l’entrée « Accès aux données par évènements » : Paragraphe 5.11.

Webservices : qu'est-‐ce que ca vient faire ici ? Cela ne me semble pas être au même niveau que le reste. Pour un utilisateur, les webservices ne seront pas forcément une interface d'accès aux données: le portail devra construire des accès de haut niveau qui abstraient les couches webservices, arclink, netdc, etc... (sinon, on n' a pas besoin de portail – mais juste d'une doc.)/

Si cela a sa place ici, bien que le portail ait pour fonction principale de présenter des fonctionnalités interactives, les webservices sont des moyens d’accéder directement aux données. Il est important de bien les décrire afin que les utilisateurs comprennent leur fonctionnement et comment les utiliser dans leurs scripts. Voir : http://www.iris.edu/ws

Cette fonctionnalité sera à discuter avec le Nœud B. 5.7 : description des OSU Il ne suffit pas de décrire les OSU. Pour rendre visibles les OSU au mieux, il devra être possible d'accéder via le portail sélectivement aux données et aux métadonnées des points de mesure qui sont sous la responsabilité d'un OSU, quels que soient les réseaux (au sens FDSN) auxquels ils appartiennent. Cette fonctionnalité existe par exemple dans le portail actuel du RAP, qui permet de sélectionner des données par «réseaux régional». La notion de réseau virtuel est bien adaptée pour cela.

Voir avec le nœud B comment gérer les sous-‐réseaux. Surement en utilisant la notion de réseaux virtuels

5.8 Visualiser les stations L'application STATION présente des inventaires. Mais l'application SEISMIQUERY décrite ensuite aussi. Et les objets inventoriés sont les mêmes. Pourquoi ces deux applications ? La description des deux applications n' établit pas clairement leur différence.

• − Des façon générale : les informations qui sont affichées pour chaque station sont au moins l'ensemble des informations décrites dans le modèle station.xml proposé par la FDSN. Ce modèle inclut des attributs qui permettent de décrire des paramètres importants pour tous les types de réseaux/données.

85

• − Il faut présenter toutes les données disponibles par années, validées ou non. Plus spécifiquement : la sélection géograpique des réseaux, des stations, ... doit être matérialisée par une possibilité des définir un rectangle sur une carte (cf par exemple l'interface du portail EIDA webdec.eu).

L’application Station a pour but de présenter sur une carte les différents réseaux et stations de manière interactive et conviviale. Avec pour chaque station une fiche descriptive complète de la station. L’application SeismiQuery permet d’effectuer un inventaire des méta-‐données selon de multiples critères.

Accéder aux données Certains réseaux distribuent actuellement des données en accélération via leur portail. Cette fonctionnalité devra être prise en charge (de même que la possibilité d'accéder aux données en vitesse...) La liste des critères de sélection des événements doit être précisées (et doit au moins englober celles des portails actuels RAP, SISMOB, OMIV).

Une fonctionnalité dédia à l’accélerometrie sera ajoutée. Mais les catalogues utilisés par les portails RAP, SISMOB, OMIV sont ils accessibles au format QuakeML ? Paragraphe 5.11.4

Accès aux données restreintes. Est-‐ce vraiment au COPIl de décider qui sont les personnées autorisées au fournir les accès aux données restreintes ? (Pas aux PI des manips?)

A discuter Les bases de données et mécanismes gérant le controle d'accés aux données restreintes sont implémentees au noeud B et non au portail.

Oui Sismicité : On ne voit pas bien si on pourra définir des critères de recherche pour un semble d'événements puis accéder à toutes les données correspondants à ces évenements.

Oui cela a été changé, bien entendu il devra être possible de sélectionner plusieurs évènements afin de récupérer les données. Paragraphe 5.11.1

Attention : il y a bien d'autres catalogues que le Renass ou le CSEM – il y a toutes les localisations faites par exemple par les réseaux régionaux RAP....

Oui ces catalogues seront intégrés quand ils seront disponibles par webservice au format QuakeML.

86

Pierre Volcke : CT noeud B Section 2 Il faudrait enrichir la partie étude des besoins et « public cible ». Un tour d’horizon des portails existants serait utile

Une liste des portails existants a été ajoutée : Paragraphe 2.2 Section 5 Sur principe, beaucoup de choses me semblent ok Certaines portions, essentiellement rédactionnelles, me semblent d’ores et déjà réalisables à peu de frais, à partir du moment où un CMS est mis en place, où une chatte graphique est adoptée et intégrée, et où le projet se dotent de rédacteurs « investis. En revanche, certaines portions demandant des développements informatiques spécifiques necessiteront, en *amont de tout développement* : de préciser les réalisations attendues, de faire du travail de maquettages visuel, et du travail de définition d’interfaces avec le nœud B. La direction de projet doit indiquer quelles priorités elle souhaite donner à chaque fonctionnalité et organiser des tranches de livraison de maquettes et de produits finaux.

Suite à la demande du COPIL le planning des taches avec les ressources humaines associées avait été supprimé. Ce planning sera disponible dans la prochaine version du cahier des charges

1 : présentation du travail Ce n’est pas complet. Le nœud B distribue les données, grâce à plusieurs dispositifs, dont un « portail web ». Il faut préciser, pour les relecteurs extérieurs au projet que c’est le nœud B qui portent les données.

OK, cela sera clarifié : Paragraphe 2.1 1.1 but du document : Deux réponses au questionnaire, c’est léger. Je suggère que l’étude soit enrichie par un tour d’horizon des fonctionnalités présentes dans les autres portails déjà existants.

Une liste des portails existants a été ajoutée : Paragraphe 2.2 1.2 les interlocuteurs précisez que peut être le rôle de chacun des interlocuteurs.

2. 2 : Objectifs du projet Je pense qu’il y a d’autres objectifs secondaires à lister : rôle vitrine, communication vers les institutions, vers les scientifiques, vers le grand public. Public visé J’ai l’impression qu’on va un peu vite ? Quelque soient les groupes retenus au final, il serait intéressant de mettre en regard ce que chaque groupe attend du portail. Ensuite, à partir de cette « matrice des besoins », le COPIL détermine des priorités d’implémentation. On peut alors en déduire une première arborescence comme celle décrite en section 3 ci-‐dessous.

3. 3 : arborescence Pourquoi cette rubrique « web services » isolée du reste ? Il faut la mettre dans la rubrique « accès aux données » ? Il peut exister dans ce portail un volet d’accès similaire à ce que les boites privés appellent « accès corporate ». Exemple : documents internes, procédures internes, documents à accès restreintes, outils de monitoring/supervision, base de données matériels, ...

87

4 : charte graphique Avant les développements, la plupart des pages mériteraient d’être maquettees de cette façon afin de les valider auprès d’utilisateurs beta.

Cela est prévu dans le plan de développement 5.2 langues supportées. Nos « obligations » institutionnelles : http//fr.wikipedia.org/wiki/Loi_Toubon 5.5 : afficher les actualités p12 Une newsletter pourrait être écrite à partir de cette rubrique, ce qui impliquerait de gérer une liste d’abonnées.

La newsletter RESIF existe déjà, et la fonctionnalité d’incription a la newsletter aussi sur le site www.resif.fr

5.10 accéder aux données validées p22 Après le tableau, Il faudrait aborder la question du catalogue d’évènements utilisé. L’Implémentation du webservice »event » au nœud B (non planifié à ce jour) pourrait fournir un support au portail pour implémenter la sélection par évènements. In pourrait imaginer que les paquets « pré-‐construits » automatiquement soient disponibles pour les évènements majeurs. Le nœud B pourrait générer ces paquets et les mettre à disposition du portail.

En ce qui concerne les catalogues d’évènements utilisés je pense qu’il faut mettre plusieurs catalogues à la disposition des utilisateurs (Rénass/BCSF, CSEM, LDG ?) mais c’est à ces différents instituts de proposer leurs catalogues au format quakeML, c’est ce que fait le CSEM et ce que prévoit de faire le RéNass. Cependant si il faut un ou des catalogues orientés accélérométrie il faudrait proposer un webservice le(s) distribuant.

P24 : après le tableau de la fin de la page, on peut aussi renvoyer vers le webdc.eu qui propose un formulaire web pour faire des requêtes arclinck. P26 : Nous devons agir pour que les formats (par ex stations XML) portent de l’information sur les citations.

Oui cela est une bonne idée d’inclure cette information dans le StationXML mais cela dépasse les compétences du portail web (Cela doit plutôt être fait au nœud B).

5.18 p 41 Sauvegarder et restaurer le site : A coupler avec les procédures de sauvegardes/archivage présentes au nœud B (le portail étant physiquement hébergé sur les infrastructures du nœud B).

Oui cela sera à voir avec le nœud B et donc à discuter lors de la future réunion portail-‐nœud B-‐COPIL

88

Guilhem Barruol : Université de Réunion Le sentiment général à sa lecture est qu'un travail très sérieux et professionnel a été mené à bien pour décrire toutes les fonctionnalités de ce futur site. Les descriptions sont claires et exhaustives et le site tel qu'il est proposé dans ce document semble vraiment être à la hauteur des standards internationaux auxquels les utilisateurs sont habitués (je pense à IRIS, Geoscope et autres réseaux internationaux). De mon expérience d'utilisateur, j'ai retrouvé dans le descriptif tous les outils et modes de requêtes que j'utilise et qui représentent les standards internationaux et mes commentaires sont donc très limités. Quelques points généraux: -‐ OBS & gestion des données de fond de mer: Dans ce cahier des charges, il n'est nulle part fait allusion que des données sismologiques pourraient provenir de stations de fond de mer (OBS). Même si pour le moment la structure RESIF n'englobe pas les OBS (peut être je me trompe?), il me semble important que cet aspect soit pris en compte dans l'archivage et la mise en ligne des données. En effet, on commence à faire des expériences scientifiques mi-‐terrestres et mi-‐océaniques (par exemple actuellement dans le projet RHUM-‐RUM et c'est également proposé dans les idées de projet AlpArray), et cela sera à terme utile de pouvoir archiver les données indépendamment de leur origine, pour un accès aisé et transparent pour les utilisateurs. Même si la gestion des parc instrumentaux sont séparés car ayant des logistiques et des technologies propres à chacun, la mise en ligne et l'archivage des données devrait a terme être mise en commun.

La gestion des données des manips OBS est en train de se discuter au sein de l’INSU. Pour le moment, nous n’avons pas l’information nécessaire ni d’interlocuteur identifié au sein de RESIF pour discuter des besoins spécifiques pour ce type de données. Dès qu’un interlocuteur sera nommé, ces besoins pourront être discutés plus précisément.

-‐ Bruit et qualité de la station: Il est vraiment utile d'avoir une idée de la qualité d'un site rapidement après son déploiement et lors de la mise en ligne de donnée ou bien lorsque l'on souhaite faire des requêtes dans les archives. Pour cela, l'outil PQLX est vraiment très utile et permet de faire des analyses relativement poussées de la qualité d'une station, dans ses différentes bandes de fréquences, sur les différents canaux et durant les différentes périodes de fonctionnement. Dans le cahier des charges WEB-‐RESIF, je n'ai pas trouvé de trace de PQLX mais simplement d'un "ws-‐seismicnoise". Ce service web n'est pas vraiment détaillé mais il me semble important que les services offerts doivent être au moins de la qualité de ceux fournis par PQLX. Peut-‐être que ce ws est basé sur PQLX? Il serait donc nécessaire d'expliciter ce qui se cache dérrière ce ws-‐seismicnoise et/ou intégrer la possibilité d'accéder aux PSD via un PQLX server, ce qui est actuellement mis en oeuvre à Sismob et qui est un outil à préserver.

Les graphiques de bruit seront générés par le nœud B (à priori en utilisant le logiciel PQLX). Il faudra en effet bien définir avec le nœud B les informations et graphiques concernant le bruit qui pourront être mis a la disposition du portail.

-‐ dans la rubrique "afficher les citations": il serait peut être utile de mettre à disposition les logo RESIF et autres images à insérer dans les présentations (logos des organismes, des OSU, de l'INSU, etc). C'est un détail mais il est important si l'on veut avoir une visibilité et un retour. Cette fonctionalité est par exemple proposée sur le site Geoscope.

Nous proposons d’ajouter cela comme décrit dans Paragraphe 5.11.6. A valider par le COPIL.

Réponses aux questions précises du formulaire concernant les besoins du portail: 1. Autres rubrique? peut -‐être que les données OBS pourraient apparaitre dans une rubrique indépendante?

89

Voir la réponse à la page précédente.

2. critère de sélection? le lot de critères proposé me semble tout à fait pertinent. 3; Format Les données seront distribuée dans les formats standards (seed, SAC), ce qui est nécessaire, mais peut-‐ être faudra-‐t-‐il mettre à disposition des programmes de traduction de format.

Tout a fait une rubrique dédiée aux divers outils/librairies/logiciel sera mis en place Paragraphe 5.13

4. Autre moyen d'accès. Non, ce qui est proposé me semble déjà complet. 5. métadonnées 6. Qualité des données il me semble nécessaire de donnée accès à un outil (PQLX ou autre) permettant une analyse approfondie de la qualité d'une station, d'un canal, pour une période donnée. Ne pas négliger cet aspect car c'est un critère important dans l'exploitation scientifique des données.

90

Laurent Frobert : CSEM Fonctionnalités nécessaires du portail :

• multi-‐langue • création de contenu statique par un utilisateur non informaticien (actualités, descriptions

réseaux ...) gestion de droits utilisateurs avec différent rôle (pour création de pages, modifications ...) flux RSS du fil d'actualité export en PDF d'un contenu

• pages statiques créées par les utilisateurs eux mêmes : -‐ Actualités -‐ description des OSU -‐ description des réseaux -‐ description des stations ? pages statiques divers : -‐ contact -‐ aide -‐ mentions légales -‐ plan du site -‐ recherche sur le site

• Formulaires avec sauvegarde : -‐ avis utilisateurs Administration des utilisateurs Statistiques d'accès au site * affichage des stations : -‐ sur une carte et sous forme de liste -‐ système de recherche -‐ fiche descriptive (exportable en PDF) Le CDC précise que les infos des stations seront disponibles sur les Noeuds B via des web service question : les fiches descriptives des stations sont-‐elles néanmoins créées par les utilisateurs ou bien générées dynamiquement par le système ?

Il est prévu qu’elles soient générées dynamiquement par le système Partie dynamique du portail : * SeismiQuery recherche et affichage des métadonnées (inventaire des stations, inventaire des données) le CDC précise que ce service sera basé sur un web service du nœud B * Accès aux données paragraphe 5.10.2 : assez flou on parle d'accès aux données avec choix du format mais stationXML et full Seed non rien a voir l'un et l'autre

Oui cela a été clarifié : paragraphe 5.11.1, 5.11.2 * Affichage de la sismicité remarque sur le point 6.4 Conformité aux standards : il faut préciser les versions des navigateurs minimales (le terme deux dernières versions est trop flou) et cautionne beaucoup des technologies pouvant être utilisées

Tout à fait, ces informations seront précisées. Paragraphe 6.4 Répartition du travail : je recommande une 'livraison' par lot des développements pour permettre l'ouverture des services le plus tôt possible exemple : l'accès au CMS même partiel pour permettre aux utilisateurs de créer les pages statiques 1) partie CMS : évaluation de différents CMS correspondant aux fonctionnalité souhaité, le langage de programmation pour l'étendre, la facilité d'utilisation pour un non informaticien 2) accès web services : spécifications techniques plus précise nécessaire !

91

=> Oui, il est prévu dans le plan de développement de faire une tache dédiée à la spécification des webservices 3) outils spécifiques (= pages de statistiques) 4) partie dynamique (accès aux données ) Le CMS choisi doit être assez souple pour permettre le développement des outils spécifiques => Tout a fait, et cela n’est pas si simple de trouver un CMS qui ne soit pas trop envahissant Prévoir une structure de données pour les informations (stations par exemple) très souples car les utilisateurs vont demander de plus en plus d'informations => Oui, c’est aussi l’objectif en utilisant pour les fonctionnalités du portail exclusivement des webservices récupérant les informations au format XML. -‐> prévoir peut être une base de données NoSQL => Le portail ne stockera pas d’informations sur les données et métadonnées. Ces informations proviendront exclusivement du nœud B et seront accessibles pardes webservices. Toute fois il utilisera une base de données pour le fonctionnement du CMS, des statistiques et peut être d’autres infos propres au fonctionnement du portail. Mais cela pourrait peut-‐être être utile au nœud B d’utiliser des bases de données NoSQl. Il me semble que le RéNass utilise une base de données NoSQL (MongoDB) pour gérer son catalogue d’évènements au format QuakeML et utilise cette base pour le webservice distribuant le catalogue du RéNass au format QuakeML. Est ce le cas au CSEM ?

9.2 Annexe 2 : Réponses au questionnaire concernant le document sur les besoins du portail

Ce questionnaire était disponible sur le site resif.fr, nous avons reçu deux réponses, les voici :

Questions générales 1. Avez-vous une autre rubrique à proposer ? Oui Non Si oui, laquelle Réponse 1 (Jérôme Vergne) : Accès aux données de capteurs environnementaux scientifiques (ex : pression, température, ...); notamment pour les stations LB. On doit pouvoir sélectionner les stations en disposant. Réponse 2 (Philippe Gueguen) : Informations sur les mises à jour, le suivi des actions, les nouvelles intégrées, les arrêts de machine (expliquer pourquoi on n'a pas accès), la disponibilité des données (comprendre pourquoi si on fait une requête si on n'a pas les données auxquelles on s'attend) Questions sur l'accès aux données 2. Avez-vous un autre critère de sélection des données à proposer ? Oui Non Si oui, laquelle

92

Réponse 1 (Jérôme Vergne) : Pour la sélection par "séismes", possibilité de sélectionner le type d'évènement (séisme, tir de de carrière, avalanche, ...) Réponse 2 (Philippe Gueguen) : Données accélérométriques: pouvoir classer en fonction de critères autres que sismologiques (dan le document il y a par événement "......," il faudra donc détailler ce que signifie ".....") 3. Souhaitez-vous avoir des données distribuées sous un autre format? Oui Non Si oui, laquelle Réponse 1 (Jérôme Vergne) : Le format SAC avec header pour les événements est nécessaire (pour l'enseignement par exemple) Réponse 2 (Philippe Gueguen) : ASCII, SAC 4. Souhaitez-vous un autre moyen d’accès aux données ? Oui Non Si oui, laquelle Réponse 1 (Jérôme Vergne) : non Réponse 2 (Philippe Gueguen) : Que signifie moyens? En fonction de critères ou en fonction d'outils? Pour les outils, afin d'être sur que des données existent et ne pas avoir de retours de requêtes vides, il faut pouvoir accéder aux données en fonction de leur disponibilité. Questions sur l'accès aux métadonnées 5. Souhaitez-vous plus d’information sur les métadonnées ? Oui Non Si oui, laquelle Réponse 1 (Jérôme Vergne) : non Réponse 2 (Philippe Gueguen) : Classe de site (A+, A, B etc....) Qualité de la station en fonction du nombre de requêtes effectuées dessus. Pour la partie accelero, type de sol, champ-libre ou autre etc..... Il faudra définir cela au moyen du cahier des charges. Questions sur les informations sur la qualité des données 6. Souhaitez-vous plus d’information sur la qualité des données ? Oui Non Si oui, laquelle Réponse 1 (Jérôme Vergne) : qualité de l'horloge Réponse 2 (Philippe Gueguen) : Déjà mentionné plus haut

93

Autres questions 7. Commentaire libre Réponse 1 (Jérôme Vergne) : Réponse 2 (Philippe Gueguen) :