Utilisation de Erddap

Utiliser ERDDAP consiste uniquement à renseigner un code XML de description de fichiers de données, dans le fichier ~tomcat/content/erddap/datasets.xml

Accès à des datasets distants : EDDGridFromErddap

Le fichier datasets.xml initial qu’on a téléchargé (dans ErddapContent.zip) contient un certain nombre de jeux de données de la NOAA, accessibles à distance grâce à l’interopérabilité de erddap. Ces fichiers sont accessibles a distance grace aux balises suivantes :

  • Avec le type "EDDGridFromErddap", on peut accéder à des datasets distants gérés par des serveurs Erddap, et ainsi constituer un réseau de données via des serveurs Erddap

    <!-- Aquarius Sea Surface Salinity, Global, 3-Month -->
    <dataset type="EDDGridFromErddap" datasetID="jplAquariusSSS3MonthV5" active="true">
        <sourceUrl>https://coastwatch.pfeg.noaa.gov/erddap/griddap/jplAquariusSSS3MonthV5
        </sourceUrl>
    </dataset>
    
  • Autre exemple : si je rajoute dans le fichier datasets.xml un jeu de données qui est sur le serveur de l'OSU Pytheas à Marseille cela donnera :

      <!-- EMSO Ligure ouest MIO OSU Pytheas-->
      <dataset type="EDDTableFromErddap" datasetID="Emso_Ligure_Ouest_Albatross_Aquadopp_NetCDF_2021" active="true">
             <sourceUrl>https://erddap.osupytheas.fr/erddap/tabledap/Emso_Ligure_Ouest_Albatross_Aquadopp_NetCDF_2021
             </sourceUrl>
     </dataset>
    

Activer/Désactiver un jeu de données

Pour désactiver un jeu de données (i.e ne plus les faire apparaitre) dans la liste du catalogue ERDDAP, il suffit de :

  • soit enlever le code XML de ces datasets, du fichier datasets.xml
  • soit de mettre l'option "active=false" dans la balise <dataset>

  • Mettons un jeu de données ci dessous à "false"

    <dataset type="EDDTableFromErddap" datasetID="Emso_Ligure_Ouest_Albatross_Aquadopp_NetCDF_2021" active="false">
          <sourceUrl>https://erddap.osupytheas.fr/erddap/tabledap/Emso_Ligure_Ouest_Albatross_Aquadopp_NetCDF_2021
          </sourceUrl>
     </dataset>
    

Prise en compte des modifications

Pour faire prendre en compte toute modification (modification dans le code XML, ou bien modification dans les données brutes des fichiers) dans un jeu de données dans ERDDAP plusieurs solutions s'offrent à nous :

  • soit on attend la durée inscrite dans le tag reloadEveryNMinutes du code XML, et la mise à jour se fait automatiquement sans aucune action au bout de la durée inscrite (par défaut 10080 mn = 7 jours)
    <reloadEveryNMinutes>10080</reloadEveryNMinutes>
    

bien entendu il faut adapter la fréquence de mise à jour avec la fréquence d'arrivée de nouvelles données.

  • soit on utilise le systeme de flag qui indique à ERDDAP de recharger un jeu de données à partir de son identifiant :

Il suffit juste de créer un fichier portant le nom de l'identifiant du dataset qu'on a créé , dans le répertoire ~tomcat/content/erddap/flag/

Le fichier "flag" déposé dans ce répertoire indique à ERDDAP de recharger "ce" dataset immédiatement.

exemple pour mettre à jour le dataset Emso_Ligure_Ouest_Albatross_Aquadopp_NetCDF_2021 après avoir mis la balise active="false"

    $ touch ~tomcat/content/erddap/flag/Emso_Ligure_Ouest_Albatross_Aquadopp_NetCDF_2021

il devrait disparaitre de l'affichage

TP1 : charger un dataset ASCII au format CSV

Chargement de fichiers au format CSV : type de données assez commun rencontré en sciences de l'Environnement

  • des lignes, et des colonnes séparées par un séparateur
  • les mesures sont en lignes, les parametres en colonnes

Dans ERDDAP ce formats de fichiers est géré par le type :

Nous allons charger un jeu de données qui représente une série temporelle (y=f(time)) de différentes variables (température, salinité, ...) provenant de capteurs situés a 2400m de profondeur (projet EMSO)

  • les fichiers de 3 mois de données sont dans le répertoire /home/jres22/ de la VM
    DATA_EMSO-microcat-2021-11/
    DATA_EMSO-microcat-2021-12/
    DATA_EMSO-microcat-2022-01/
    

Ce sont des fichiers journaliers d'un capteur appelé Microcat situés à 8 profondeurs différentes

    $ ls  DATA_EMSO-microcat-2021-11/2021-11/
        10025_1250m  13017_2000m  13375_2400m  9464_1000m
        10325_500m   13018_2200m  9463_750m

Dans cet exemple :

  • la premiere ligne contient les libellés des colonnes,
  • la 2eme ligne contient les unités, et
  • les données elles-même commencent à la 3eme ligne
        1. date,Sensor_serial_number,Sensor_Depth_Theoric,Temp_insitu,Conductivity,Pressure,Oxygen,Depth,Salinity,Temp_Pot,O2 saturation,SigmaTheta
        2. date,sensor_serial_number,meter,degree_C,S.m-1,dbar,mL.L-1,meter,PSU,degree_C,%, kg.m-3
        3. 2022-01-15T22:00:01,37-9464,1000,13.3625,4.54978,977.475,-999.99,967.46,38.55762,13.2173,258.02,29.1075
    

Génération du code XML

On place un mois de données (2021-11) dans le répertoire de travail DATA_EMSO/

        $ cd ~jres22/
        $ cp -a ./DATA_EMSO-microcat-2021-11/ ./DATA_EMSO/
  • Nous allons maintenant insérer les données de ces fichiers dans le serveur ERDDAP. On lance le script GenerateDatasetsXml.sh
    $ cd /opt/tomcat/webapps/erddap/WEB-INF
    $ ./GenerateDatasetsXml.sh
    

On répond maintenant aux différentes questions du script :

Question Reponse Commentaire
Which EDDType ? EDDTableFromAsciiFiles Ascii en Colonne
Starting Directory /home/jres22/DATA_EMSO/ le répertoire source
File Name regex ".*\.csv" pour prendre les .csv files
Full file name of one file default "" Pour le cas ou on aurait des fichiers de noms différents
Charset ISO-8859-1 or UTF-8 default "" retour=default=ISO-8859-1
Colums names row 1 la premiere ligne sert d'entete
First Data row 3 les données commencent à la 3eme ligne
Colum Separator ',' séparateur des colonnes , au clavier
ReloadEveryNMinutes (e.g., 10080) (default="") intervalle pour recharger le jeu de données
questions suivantes ...  default "" taper "entree" pour le reste des questions
... les 4 dernieres questions fournissent les métadonnées ...
infoUrl ? http://www.emso-fr.org /  mettez l'URL d'un site d'information sur ce projet
Institution ? OSU Pytheas service d'observation UMS3470 votre Institut
Summary ? EMSO Ligure ouest capteur Microcat résumé de ce dataset
Title ? EMSO Ligure Ouest capteur Microcat un titre du dataset

Une fois terminé le script affiche à l'écran tout le code XML... On peut aussi récupérer ce code XML de sortie dans le fichier ~tomcat/content/erddaplogs/out.xml

  1. Il faut récupérer/copier ce code XML issu de la commande, de la ligne <dataset> jusqu'à </dataset>
  2. l' insérer DANS le fichier "datasets.xml"

  3. Dans une nouvelle fenêtre , on édite le fichier /opt/tomcat/content/erddap/datasets.xml qui contient les datasets

    $ cd /opt/tomcat/content/erddap
    $ gvim datasets.xml
    
  4. et on insére le code XML qui a été généré par le script (Insérer des commentaires clairs autour de votre "paste" pour vous y retrouver plus facilement...)

    • NB: les bonnes pratiques seront de sauvegarder des versions de ce fichiers datasets.xml avec un svn ou un git quelconque. Une erreur dans le code XML est vite arrivée :-\

Prise en compte dans Erddap

  • Comme vu précédemment, pour faire prendre en compte ce nouveau jeu de données dans ERDDAP : Il faut utiliser le systeme de flag qui indique à ERDDAP de recharger un jeu de données à partir de son identifiant :

on récupére l'identifiant du jeu de données qu'on vient d'insérer sur la 1ere ligne datasetID=DATA_EMSO_cce0_1caa_5727

    <dataset type="EDDTableFromAsciiFiles" datasetID="DATA_EMSO_cce0_1caa_5727" active="true">
  • et on crée un fichier "flag" portant le nom de l'identifiant du dataset qu'on a créé , dans le répertoire ~tomcat/content/erddap/flag/
    $ touch ~tomcat/content/erddap/flag/DATA_EMSO_cce0_1caa_5727
    

Le fichier "flag" déposé indique à ERDDAP de recharger "ce" dataset immédiatement.

On doit avoir un dataset supplémentaire dans le serveur Erddap, dont l'URL comporte l'identifiant du jeu de données

Aggrégation de données : cool

Une fonctionnalité puissante de ERDDAP dans la gestion de fichiers, est qu'une fois la structure XML des fichiers établie, il suffit de déposer de nouveaux fichiers (de même structure) dans le répertoire source, pour qu'ils soient pris en compte automatiquement, sans aucune action supplémentaire.

Ainsi la série de fichiers s'enrichit progressivement automatiquement

  • Exemple : rajoutons d'autres fichiers de données des mois de Décembre 2021 et Janvier 2022 dans le répertoire de la série temporelle
    $ su - jres22
    $ cp -a  DATA-EMSO-microcat-2021-12/2021-12/ ./DATA_EMSO/
    $ cp -a  DATA-EMSO-microcat-2022-01/2022-01/ ./DATA_EMSO/
    

Pour provoquer la mise à jour du dataset:

  • soit on attend la durée inscrite dans le tag reloadEveryNMinutes du code XML, et la mise à jour se fait automatiquement sans aucune action au bout de la durée inscrite (par défaut 10080 mn = 7 jours)
    <reloadEveryNMinutes>10080</reloadEveryNMinutes>
    

bien entendu il faut adapter la fréquence de mise a jour avec la fréquence d'arrivée de nouvelles données.

TP1.1 : données météo Frioul - Baie de Marseille

  • TP identique avec les données d'une station météorologique sur l'ile du Frioul dans la baie de Marseille

  • les données sont dans la VM, dans le répertoire /home/jres22/DATA_FRIOUL

Un coup d'oeil au code XML : balises intéressantes

fournir les fichiers au téléchargement

Par défaut les fichiers du dataset ne sont pas fournis au téléchargement. Pour les rendre accessibles dans l'interface Erddap, il faut rajouter une balise accessibleViaFiles dans le code XML du dataset.

<dataset type="EDDTableFromAsciiFiles" datasetID="DATA_EMSO_cce0_1caa_5727" active="true">
<reloadEveryNMinutes>10080</reloadEveryNMinutes>
<updateEveryNMillis>10000</updateEveryNMillis>
<fileDir>/home/jres22/DATA_EMSO/</fileDir>
<fileNameRegex>.*\.csv</fileNameRegex>
<accessibleViaFiles>true</accessibleViaFiles>

NB: Apres toute modification du code XML, pour le faire prendre en compte il faut réactiver le flag du dataset.

    $ touch ~tomcat/content/erddap/flag/DATA_EMSO_cce0_1caa_5727

Inscrire les unités des variables

Les fichiers CSV sont bien pratiques avec une organisation simple en lignes et colonnes, mais ils sont "pauvres" sémantiquement, car ils ne sont pas prévus pour embarquer beaucoup de métadonnées (au mieux quelques lignes d'entete)... de fait, ils ne répondent pas correctement à une problématique FAIR :

  • aucune métadonnées (parfois pauvres dans une entete)
  • libellés des parametres non normalisés
  • pas (toujours) d'unités : Une valeur sans unité ne veut rien dire, unités non normalisées, etc.

Si les unités ne figurent pas dans vos fichiers sources, il est nécessaire de les rajouter dans le code XML, pour chacune des données affichées :

Erddap possede un attribut spécial "units" pour inscrire les unités des variables dans le fichier datasets.xml ...

Rajoutons des unités pour certaines variables dans le code XML du fichier datasets.xml, pour le dataset "DATA_EMSO_cce0_1caa_5727"

NB: Si possible mentionner les unités standards référencées dans un thesaurus international comme celui de la convention CF

  • http://cfconventions.org/Data/cf-standard-names/current/build/cf-standard-name-table.html

    <att name="ioos_category">Unknown</att>
        <att name="long_name">temperature in situ</att>
        <att name="standard_name">sea_water_temperature</att>
        <att name="units">degree_C</att>
    </addAttributes>
    
    <addAttributes>
        <att name="ioos_category">Dissolved O2</att>
        <att name="long_name">Oxygen</att>
         <att name="units">ml.l-1</att>
    </addAttributes>
    
  • n'oublions pas de recharger le jeu de données par la méthode habituelle de "flag"

    $ touch ~tomcat/content/erddap/flag/DATA_EMSO_cce0_1caa_5727
    
  • Vérifiez en faisant une requête sur les données avec le "data access form" que les unités sont bien affichées sur la 2eme ligne

unites

Afficher des subsets avec la balise Subset

Erddap permet d'afficher des "subsets" qui sont des sous ensembles de données. Il se base pour cela sur une ou quelques variables qui présentent une gamme de variation faible,

  • les subsets se comportent comme des index ou des des clés primaires, qui permettent de filtrer les autres données sur les valeurs de ces variables.

Par exemple dans le jeu de données EMSO DATA_EMSO_cce0_1caa_5727 , on a 8 capteurs Sensor_serial_number à 8 profondeurs Sensor_serial_number différentes

Ces 2 variables peuvent être mises en "subset", ce qui permet de filtrer les données sur une valeur de profondeur ou du numéro de série du capteur par exemple

    http://localhost:8080/erddap/tabledap/DATA_EMSO_cce0_1caa_5727.subset

Erddap fait un choix assez subjectif, et pas tout le temps opportun des variables servant de clés pour avoir des "subsets"... dans le cas où le choix n'est pas bon, il est possible de modifier ces variables dans le code XML au niveau de l'attribut "subsetVariables" comme ci-dessous

    <att name="subsetVariables">Sensor_serial_number, Sensor_Depth_Theoric, Oxygen</att>

Quelques mots sur le format NetCDF

Le format de fichier privilégié par ERDDAP est le format netCDF

Pourquoi NetCDF? parceque c'est un format de fichier interopérable "auto-suffisant", "auto-documenté" largement utilisé dans le monde scientifique international, dans les domaines, physiques, météorologie, biologie, océanographie, atmosphère etc.

  • Un des intérets majeur est que les métadonnées sont indissociables des données, car incluses dans une entête faisant partie du fichier lui même.

NetCDF c'est :

  • Un modèle de données, un format de fichier ouvert (suffixe « .nc »)
  • Format portable : Données indépendantes de la machine
  • Format acceptant la mise en place de conventions, permettant standardisation et interopérabilité
  • Format riche (métadonnées et données) et ouvert
  • Format flexible et standardisé
  • Format bien adapté pour stocker des tableaux de nombres multidimensionnels
  • Énormément utilisé en météorologie, en océanographie, et dans le spatial.
  • Une interface de programme d'application (API) avec librairie implémentant l'API
  • Des dizaines de logiciels tiers gratuits permettent de manipuler ce format (découper, assembler, faire des moyennes, visualiser,...)

Dans le cadre de ce TP on a installé l'application "panoply" dans /usr/local/, ainsi que le package netcdf-bin qui contient les commandes pour traiter les fichiers NetCDF. Comme par exemple la commande ncdump qui permet d'afficher le contenu d'un fichier NetCDF

    Exemple : avec l'option -h pour affiche le header du fichier
    $ ncdump -h  ~jres22/DATA_IBIROOS/20170320-EUR-L4-CHL-ATL-v01-fv01-OI.nc
    ou
    $ panoply  ~jres22/DATA_IBIROOS/20170320-EUR-L4-CHL-ATL-v01-fv01-OI.nc

TP 2 : charger un dataset NetCDF 2D "gridded"

Nous allons commencer par rentrer des fichiers 2D (données selon des dimensions Latitude/Longitude au format NetCDF.

Des fichiers NetCDF 2D de données sont disponibles :

  • dans le répertoire ~jres22/DATA_IBIROOS/
    • données surfaciques de chlorophylle en Atlantique Nord.
  • dans le répertoire ~jres22/DATA_CHARM
    • données satellite MODIS chlorophyll, à 555nm reflectance côte de l'Oregon

Génération du code XML par le script GenerateDatasetsXml.sh (sous l'identité tomcat)

$ cd /opt/tomcat/webapps/erddap/WEB-INF
$ ./GenerateDatasetsXml.sh | tee out.xml

Ces fichiers représentent des concentrations surfaciques en des points Latitude/Longitude. C'est donc une grille 2D au format NetCDF (on le sait en regardant le header du fichier NetCDF).

  • Nous allons donc choisir le format EDDGridFromNcFiles

  • La 1ère question basique du script à laquelle il faut répondre, est d' indiquer le type du jeu de données à traiter (format grid ou tabulaire)

Répondons aux différentes questions du script :

Question Reponse Commentaire
Format EDDGridFromNcFiles Grille en NetCDF
Starting Directory /home/jres22/DATA_IBIROOS ou /home/jres22/DATA_CHARM le répertoire source
File Name regex ".*\.nc" par défaut pour prendre les fichiers .nc du répertoire
First File Name "" s'il y a des fichiers différents dans le répertoire , dans notre cas réponse par \<retour charriot>

On besoin de peu d'informations supplémentairess car toutes les informations sont récupérées par le script dans le fichier NetCDF.

  • Le script étant terminé, on récupére le code XML que le script a affiché à l'écran de la ligne <dataset> jusqu'à </datasatet>

    • On peut aussi récupérer ce code XML de sortie dans le fichier out.xml
  • Dans une nouvelle fenêtre on édite le fichier /opt/tomcat/content/erddap/datasets.xml qui contient la description des datasets

    $ cd /opt/tomcat/content/erddap
    $ vim datasets.xml
    
  • on insère le code XML qui a été précédemment généré (en fin de fichier avant la balise de fermeture)

  • Récupérer l'Identifiant du jeu de données ibiroos sur la 1ere ligne datasetID=DATA_IBIROOS_1142_f13b_2929

    $ grep ibiroos datasets.xml
    
    <dataset type="EDDGridFromNcFiles" datasetID="DATA_IBIROOS_1142_f13b_2929" active="true">
    

on enregistre le fichier et on sort de l'éditeur...

  • Rechargement du jeu de données

Après avoir inséré le code XML dans le fichier datasets.xml, comme vu précédemment Il faut faire prendre en compte cette modification à ERDDAP avec le système de flag.

On créé un fichier portant le nom de l'identifiant du dataset qu'on a créé , dans le répertoire ~tomcat/content/erddap/flag/

    pour le dataset IBIROOS
    $ touch ~tomcat/content/erddap/flag/DATA_IBIROOS_1142_f13b_2929

    pour le dataset CHARM
    $ touch ~tomcat/content/erddap/flag/DATA_CHARM_e438_91f2_1a6d

La prise en compte est alors immédiate par le serveur ERDDAP. S'il n'y a pas eu d'erreur, le nouveau jeu de données doit apparaitre dans erddap avec toutes les metadonnées, et les accès aux données brutes et au graphe.

TP3 : fichier NetCDF 1D : profil vertical

  • les données proviennent d'une sonde CTD qu'on immerge. Elles évoluent avec la profondeur.
  • les données au format NetCDF, sont dans la VM, dans /home/jres22/DATA_JULIO

: juste fais le

TP4 : Simple diffusion de fichiers de données

On a parfois simplement le besoin de mettre des fichiers de formats différents (images .jpg, .png, fichiers excel etc...) et fournit un simple accès en mode "transfert de fichiers".

Par exemple pour mettre à disposition un ensemble de fichiers hétérogènes, identifiés (ou pas) par un D.O.I

Pour cela Erddap propose un type de données particulier EDDTableFromFileNames qui permet de fournir basiquement les fichiers de données au téléchargement... mais sans affichage graphique ni requetage sur les données brutes à l'intérieur des fichiers, comme on a vu précédemment.

Ce type permet de traverser récursivement (ou pas) tous les sous répertoires, de filtrer et de mettre à disposition tous les fichiers de différents formats qu'il trouve , avec la balise "recursive" positionnée à true ou false

    <recursive>false</recursive>

On va par exemple mettre à disposition plusieurs fichiers texte .csv et des fichiers .xls et une image .png d'un jeu de données

  • Comme à l'accoutumée, lançons le script GenerateDatasetsXml.sh
    $ cd /opt/tomcat/webapps/erddap/WEB-INF
    $ ./GenerateDatasetsXml.sh | tee out.xml
    

Répondons maintenant aux différentes questions du script :

Question Reponse Commentaire 3
Which EDDType ? EDDTableFromFileNames -
Starting directory /home/jres22/DATA_VRAC/ -
File name regex (e.g., ".*.nc") .* pour filtrer tous les type de fichiers
Recursive [true, false] true pour traverser tous les répertoires
ReloadEveryNMinutes default -
infoUrl http://monprojet.fr une URL d'information
institution OSU pytheas UMR 3470 CNRS texte libre
summary divers fichiers de sonde ctd solemio  texte libre
title le titre du jeu de données texte libre
  • Comme à l'accoutumée maintenant, récupérez le code XML produit par la commande GenerateDatasetsXml.sh et placez le à la fin du fichiers /opt/tomcat/content/erddap/datasets.xml

  • Après insertion du code XML, il faut faire prendre en compte cette modification à ERDDAP. Comme on l'a vu précédemment en créant un fichier portant le nom de l'identifiant du dataset, dans le répertoire ~tomcat/content/erddap/flag/

    $ touch /opt/tomcat/content/erddap/flag/DATA_VRAC_b91d_19b7_8cbd
    
  • Vérification dans le serveur Erddap : Vous devez avoir un dataset supplémentaire dans votre serveur Erddap, dont l'URL comporte l'identifiant du jeu de données

    http://localhost:8080/erddap/files/
    http://localhost:8080/erddap/files/DATA_VRAC_b91d_19b7_8cbd/
    

Erddap vs jupyter-notebook

Erddap est un middleware efficace en tant que serveur de données On peut donc y accéder avec de multiples logiciels scientifique "clients" et interroger et extraire les données que l'on veut, pour les travailler dans un environnement logiciel scientifique.

L'interfacage avec un jupyter-notebook est particulièrement aisée et efficace

JupyterLab est un environnement de développement interactif basé sur le Web. Jupyter Notebook est une application serveur-client. Elle permet d’éditer et d’exécuter des notebooks par le biais d’un navigateur web. Cette application peut être exécutée sur un PC sans accès internet, ou peut être installée sur un serveur distant sur lequel il est possible d’accéder via internet.

En quelques lignes de python (ou de R) on peut extraire les données que l'on veut et les grapher

Protéger un jeu de données

La "philosophie" FAIR de l'Open Science est : ouvert autant que possible, fermé autant que nécessaire

par défaut les jeux de données intégrés dans Erddap sont publics et accessibles sans protection. Mais dans certains cas de projets on peut vouloir protéger un jeu de données par des identifiants login/passwd

Erddap propose plusieurs méthodes d'authentification, parmi lesquelles

  • custom
  • google
  • orcid
  • oauth2

Erddap recommande "google" et "orcid" qui sont les plus sûres, et qui permettent de ne pas avoir à gérer de comptes et de mots de passe en interne. Mais cela demande d'avoir un compte "google" ou "orcid"

Dans la communauté scientifique nous privilégions la méthode "orcid" qui permet d'identifier des personnels scientifiques de manière univoque avec un identifiant numérique.

L'objectif d'ORCID est de résoudre les confusions de noms d'auteurs dans les publications scientifiques en attribuant un identifiant unique à un scientifique, et en reliant cet identifiant aux publications et aux autres produits dont il est l'auteur.

Authentification avec le mode "custom"

Dans quelques cas de figure une authentification "custom" c'est à dire interne à Erddap sera utile et facile à mettre en oeuvre

Pour cela il faut :

  • 1. modifier le fichier "setup.xml" : On indique dans setup.xml quel est le type d'authentification qu'on met en place

Rajouter :

         <authentication>custom</authentication>
         <passwordEncoding>UEPSHA256</passwordEncoding>
         <listPrivateDatasets>true</listPrivateDatasets>

Pour la méthode "custom" le codage UEPSHA256 est à privilégier !

  • 2. modifier le fichier "datasets.xml"

en début de fichier, en dehors des dataset, il faut créer :

  • les "users" nécessaires à une authentification
  • avec un password
  • et un identifiant de "rôle"
   <user username="emso"
    password="973edebee7f857d2d7dfdef14b2c39151bf30568"
     roles="emso_role" />

Le password est créé avec la commande sha256sum

   echo -n 'emso:ERDDAP:monpassworddifficile' | sha256sum
  973edebee7f857d2d7dfdef14b2c39151bf30568

on peut rajouter "emso:ERDDAP" une graine devant le mot de passe pour complexifier le chiffrement

Il faut relancer le serveur tomcat pour que les modifications soient prises en compte :

  • on voit alors apparaitre un item "log in" en haut à droite de la page ERDDAP

3. Pour protéger un jeu de données particulier DATA_EMSO_cce0_1caa_5727

  • le rôle est utilisé pour lier un "user" avec un "dataset". On va donc retrouver le "role" dans un dataset qu'on veut protéger avec la balise <accessibleTo>.

Par exemple pour le dataset "DATA_EMSO_cce0_1caa_5727" ci dessous, on indique que ce dataset sera accessible par le rôle "emso_role"

    <dataset type="EDDTableFromAsciiFiles"                   datasetID="DATA_EMSO_cce0_1caa_5727" active="true">
               <reloadEveryNMinutes>10080</reloadEveryNMinutes
               ...
               <accessibleTo>emso_role</accessibleTo>
          ....
    </dataset>

Il faut activer la mise à jour du dataset par le systeme de flag pour que la modification du dataset soit prise en compte.

  $  touch ~tomcat/content/erddap/flag/DATA_EMSO_cce0_1caa_5727

on voit alors un label "log in" devant le jeu de données à protéger

  • NB: la transaction de login passe automatiquement en httpS:// il faut donc que votre serveur tomcat réponde sur le port https: 443

Authentification avec le mode "orcid"

Dans ce cas on reporte l'authentification sur le système "orcid" d'identification

i) Il vous faut un compte "orcid" : http://orcid.org

et récupérer votre orcidClientID et orcidClientSecret sur le site orcid (dans le menu Developper Tool)

ii) On indique dans setup.xml quel est le type d'authentification qu'on met en place

Rajouter ces tags dans setup.xml

    <authentication>orcid</authentication>
    <orcidClientID>APP-JEEPF97UHGJ4D1AF</orcidClientID>
    <orcidClientSecret>99996fakeaf65b-3177-45a4-86ed-b11fake614daa</orcidClientSecret>

iii) dans datasets.xml

en début de fichier, en dehors des dataset, il faut créer:

  • les "users" nécessaires à une authentification
  • pas besoin de password (puisque celui ci est donné par orcid)
  • et un rôle

Dans la méthode "orcid", le user est le numéro d'identification du compte orcid

        <user username="0000-0003-0537-256X"
          roles="Rohtmnet" />

Pour toutes ces modifications dans setup.xml et datasets.xml il faut penser à relancer le serveur à chaque modification.

Apres restart du serveur, i

  • on voit apparaitre un login en haut a droite de la page de garde de Erddap
  • le dataset protégé est visible, mais non accessible

et pour le jeu de données qu'on a voulu protéger, dans la liste des datasets, on voit que le jeu de données est visible... mais pas accessible sans qu'on se soit authentifié

après authentification, le dataset sera accessible.

Annexes

Choix du type EDD pour les fichiers NetCDF

Il est parfois difficile de bien trouver le type de Erddap a fournir pour analyser un fichier NetCDF.

Il faut commencer par bien lire la documentation :-) , mais les grandes lignes sont que Il faut savoir si le fichier NetCDF suit les recommandations de la convention CF

tels que définies par les "discrete sampling geometries" (DSG) des conventions CF -climate forecast :

Selon les conventions CF DSG, les données sous la forme d'une suite discrète de points, doivent être définies avec l'attribut featureType selon les type suivants :

FeatureType Description
points isolés (simples points sans coordonnées ni relations avec d'autres points)
 série temporelle : série de point avec coordonnée fixe pris à des temps croissants
trajectoire :  série de point le long d'un tracé géographique, pris à des temps croissants
 profil (profil vertical, profil horizontal) : série de mesures ordonnées le long d'une ligne verticale à un point fixe et temps fixe
profil de série temporelle : series of profile features at the same horizontal position with monotonically increasing times
profil de trajectoire : a series of profile features located at points ordered along a trajectory

Erreur courante dans les fichiers NetCDF

il arrive qu'un jeu de données en NetCDF ne soit pas chargé par Erddap !!!

Il y a donc eu une erreur... il faut donc essayer de comprendre ce qui s'est passé en localisant l'erreur dans le fichier de logs (en cherchant error ou l'id du dataset)

Exemple ci dessous :

    datasets.xml error on line #2067
    While trying to load datasetID=sirta_0a02_7b55_3c35 (after 608 ms) 
    java.lang.RuntimeException: datasets.xml error on or before line #3120: 
    cdm_timeseries_variables #0=??? isn't one of the data variable destinationNames.
    at gov.noaa.pfel.erddap.dataset.EDD.fromXml(EDD.java:417)
    at gov.noaa.pfel.erddap.LoadDatasets.run(LoadDatasets.java:336)
    Caused by: com.cohort.util.SimpleException: cdm_timeseries_variables #0=??? 
    isn't one of the data variable destinationNames.

Il semble y avoir une sorte d'erreur qui incrimine cdm_timeseries_variables

On va donc aller voir le code XML produit dans le fichier datasets.xml, on se rend compte que l'attribut cdm_timeseries_variables n'a pas été renseigné correctement par erddap

   <addAttributes>
    <att name="cdm_data_type">TimeSeries</att>
    <att name="cdm_timeseries_variables">??? </att>

La documentation de erddap indique que :

indique que l'attribut cdm_timeseries_variables est obligatoire et qu'il doit contenir le nom de la variable qui a cf_role=timeseries_id

    TimeSeries - for data from a set of stations with fixed longitude,latitude(,altitude).

    The dataset MUST include the globalAttribute cdm_timeseries_variables, where the value is a comma-separated list of the variables which have the information about each station. Thus, for a given station, the values of these variables will be constant.
    One of the variables MUST have the variable attribute cf_role=timeseries_id to identify the variable that uniquely identifies the stations.

Dans le header du fichier de vente du sirta, profilvent_1a_Lmat10mLz1PventR5sN5n_v01_20170302_000005_1440.nc c'est la variable station_name qui possede le "cf_role"

            char station_name(strlen) ;
            station_name:long_name = "station name" ;
            station_name:cf_role = "timeseries_id" ;
  • dans le fichier datasets.xml, il faut donc modifier cet attribut de la maniere suivante
    <addAttributes>
    <att name="cdm_data_type">TimeSeries</att>
    <att name="cdm_timeseries_variables">station_name, longitude, latitude</att>
    

Apres modification, rechargeons le jeu de données

    $ touch /opt/tomcat/content/erddap/flag/sirta_0a02_7b55_3c35

et... Vérifions.... le dataset maintenant a bien été chargé par erddap

    http://localhost:8080/erddap/tabledap/sirta_0a02_7b55_3c35.graph

    http://localhost:8080/erddap/tabledap/sirta_0a02_7b55_3c35.graph?time,ws_040,time_bounds&.draw=markers&.marker=3%7C5&.color=0x0000FF&.colorBar=%7C%7C%7C%7C%7C&.bgColor=0xffccccff&time%3E=2017-03-01T00:00:00Z&time%3C2017-03-03T00:00:00Z&.timeRange=2,day(s)

Quelques recommandations pour le type EDDTableFromAsciiFiles

Le type "EDDTableFromAsciiFiles" peut provoquer pas mal d'erreurs, si les fichiers ne sont pas bien conformes à ce qu'attend erddap. Voici quelques recommandations pour le contenu des fichiers ascii :

  • Attention à ne pas avoir des colonnes portant un même nom !!
  • Mettre les Dates au format ISO 2015-01-10T12:00:00Z
  • Mettre les valeurs réelles avec un format anglais d.ddd et pas avec la virgule "," d,ddd
  • bien choisir la précision utile des valeurs réelles,

    • exemple ca ne sert a rien d'avoir 2 latitudes différentes 4.4933 4.4938 à la 3eme décimale, car erddap va les afficher différentes
  • Bien choisir son caracteres de séparation : colonnes séparées par virgule, ou tabulation pour les export en CSV

  • Mettre les profondeurs en valeur négatives de -1 à -56 par exemple, si on veut tracer un profil vertical
  • Attention des caractères spéciaux dans les labels des colonnes peuvent poser probleme : enlever tout caractère spécial comme ( ) [ ] / % ^ : micron

  • Ne pas mettre les unités g/l dans les noms de colonnes... erddap a un attribut spécial pour placer les unités donc exemple Oxygene et pas Oxygen_SBE_43_ml_l (Oxygen, SBE 43 [ml L])

  • tous les fichiers d'un dataset doivent être strictement identiques... mêmes noms et ordre de colonnes, même format

  • pour les valeurs manquantes enlever NaN et mettre une valeur numérique -999.0 par exemple qui permettra a erddap de les repérer

Exemple d'erreurs dans les logs

Exemple d'un jeu de données qui ne s'est pas chargé dans Erddap Il faut consulter le fichier ~/tomcat/content/erddap/logs/log.txt

Les erreurs ne sont pas facile à localiser, il faut fouiller !!

On voit ci dessous que erddap signale un erreur sur un caractère invalide sur la variable FlC_Fluorescence_Aug_l:

at gov.noaa.pfel.erddap.LoadDatasets.run(LoadDatasets.java:336) Caused by: java.lang.RuntimeException: ERROR in Test.ensureSomthingUnicode(): datasets.xml/EDD.ensureValid error for datasetID=solemio_c63e_3ab7_aebf: for dataVariable #6=FlC_Fluorescence_Aug_l:

datasets.xml/EDV.ensureValid error for variable destinationName=FlC_Fluorescence_Aug_l: sourceName has an invalid Unicode character (#130) at position=20 [#] in "FlC: Fluorescence [[195][130][194][181]g_l][end]" at com.cohort.util.Test.error(Test.java:41)

la solution a été de réécrire le libellé de cet attribut dans le fichier de données