Base de donnée personnalisée

Objectif

L’objectif d’une base de données personnalisée est de permettre à l’utilisateur d’ajouter des données qu’il posséderait dans son espace de travail local, à un produit de la base de données CTOH.

L’intérêt d’une base personnelle est de faciliter, avec une interface unique, l’accès à la fois aux données altimétriques officiels de la base CTOH et à des corrections ou des paramètres complémentaires que l’utilisateur crée et gère lui même dans son espace de travail.

Création d’un sous-produit (gdrtype) personnel

Structuration des données personnel

Les données utilisateur associées à un produit de la base de données CTOH sont désigné sous-produit (gdrtype). Ces données de sous-produit doivent être structuré de la même manière que le produit dans la base du CTOH. Ci-dessous les conditions requises à respecter :

Trace

Le conditionnement des fichiers doit être conforme au produit original CTOH :

  • Les données utilisateur sont des fichiers au format NetCDF, il y en a un pour chaque trace de la mission altimétrique conformément au produit CTOH.

  • Le nom de fichier doit respecter la convention de nommage du produit CTOH qui peut être précédé d’un préfixe.

Variables des fichiers

Les coordonnées du sous produit doivent être homogène au produit de la base du CTOH. Les fichiers doivent contenir les mêmes noms de variables de coordonnées (longitude, latitude et time) en haute fréquence et basse fréquence. Mais également, être structuré avec les mêmes groupes (NetCDF) s’il y a lieu. Les dimensions et tailles de ces variables doivent être identique au produit en base CTOH.

Attributs

Les noms d’attributs de numéro de cycle et de trace des fichiers doivent être identique au produit d’origine dans la base du CTOH et avoir la même valeur.

Structure arborescente de fichier (SAF)

Les fichiers traces utilisateur doit être organisés dans un espace de travail local de la même manière que le produit dans la base CTOH :

  • Les fichiers sont structurés dans des répertoires cycle qui contiennent le sous-répertoire gdrtype.

SAF du base personnalisée du produit ja3_a_cnes_f_sgdr

Ci-dessous la structure arborescente de fichier du produit ja3_a_cnes_f_sgdr dans un répertoire local utilisateur. Plusieurs nouveaux sous-produits définis par l’utilisateur ales et rads complète ce produit.

  • convention de nommage fichier…

  • préfixe

  • cycle_xxx

ja3_a_cnes_f_sgdr # Nom du produit dans la base de données CTOH
    ├── cycle_000 # Numéro du cycle
    │   ├── ales  # Paramètres complémentaires ajoutés au produit gdr/sgdr original
    │   │   ├── ales_JA3_GPS_2PTP000_118_20160212_020721_20160212_030333.nc
    │   │   ├── ales_JA3_GPS_2PTP000_120_20160212_035946_20160212_045559.nc
    │   │   ├── ales_JA3_GPS_2PTP000_122_20160212_055212_20160212_064825.nc
    │   │   └── ...
    │   └── rads  # Paramètres complémentaires ajoutés au produit gdr/sgdr original
    │       ├── rads_JA3_GPS_2PTP000_118_20160212_020721_20160212_030333.nc
    │       ├── rads_JA3_GPS_2PTP000_120_20160212_035946_20160212_045559.nc
    │       ├── rads_JA3_GPS_2PTP000_122_20160212_055212_20160212_064825.nc
    │       └── ...
    ├── cycle_001 # Numéro du cycle
    │   ├── ales
    │   │   └── ...
    │   └── rads
    │       └── ...
    │
    ├── cycle_002 # Numéro du cycle
    │   ├── ales
    │   │   └── ...
    │   └── rads
    │       └── ...
    .
    .
    │
    ├── cycle_147 # Numéro du cycle
    │   ├── ales
    │   │   └── ...
    │   └── rads
    │       └── ...
    ├── ...
    .
    .

Mise à jour de la description du produit

Pour accéder au sous-produit utilisateur via la bibliothèque PyCTOH, il faut mettre à jour le fichier yaml de description du produit. Celui-ci doit être copié dans l’espace de travail utilisateur en gardant le même nom de fichier et modifier avec le nouveau gdrtype que l’utilisateur a créé localement.

Ci-dessous le fichier yaml de description produit ja3_a_cnes_f_sgdr de la mission Jason-3. A l’attribut gdrtype_prefix, les sous-produits nommé ales et rads sont ajouté à la description original produit de la base du CTOH. Ils correspondent tous deux à des données contenues dans des répertoires hors base de données CTOH. Ils sont définis avec des chemins absolus.

name: ja3_a_cnes_f_sgdr
mission: Jason-3
orbit_phase: A
provider: CNES
product_version: GDR-F, SGDR, ALES, RADS
doc: jason3 SGDR-F (GDR + waveforms).
product_prefix : ja3_a_cnes_f_sgdr/
cycle_prefix  : cycle_\d{3}/
gdrtype_prefix :
    sgdr  : sgdr/
    gpd  : gpd/gpd_
    ales : /ctoh/data/projects/cci/cci_db/products/ja3_a_cci_f_sgdr/cycle_\d{3}/ales/ales_
    rads : /ctoh/data/projects/cci/rads/ctoh_data_f/ja3_a_cci_f_sgdr/cycle_\d{3}/rads/rads_

#file_postfix : 2P.*P\d{3}_\d{3}_\d{4}[01]\d[0-3]\d_[0-2]\d[0-5]\d[0-5]\d_\d{4}[01]\d[0-3]\d_[0-2]\d[0-5]\d[0-5]\d\.nc
file_postfix : (?P<mission>JA3)_[A-Z]{3}_2P(?P<baseline_collection>[A-Z,a-z])P(?P<cycle>\d{3})_(?P<pass>\d{3})_\d{4}[01]\d[0-3]\d_[0-2]\d[0-5]\d[0-5]\d_\d{4}[01]\d[0-3]\d_[0-2]\d[0-5]\d[0-5]\d\.nc
ref_gdr: sgdr    # Aliases
meanpass_dir:

dims_alias:
    lf_dim : data_01/time
    hf_dim : data_20/time

wf_dims_alias :
    samples : samples

coords_alias:
    data_01/time :
        lon : longitude
        lat : latitude
        time : time
    data_20/time :
        lon : longitude
        lat : latitude
        time : time

aliases:    etc/ctoh_aliases_jason3.desc    # Gridded tracks (for regional access optimization)
tracksgrid: etc/tracksgrid/

orbit:  topex
ellipsoid:
    'name': 'TP'
    'a': 6378136.30
    'f': 1/298.257

Mise à jour du catalogue de la base de données

L’utilisateur doit également faire une copie local du catalogue de produit de la base de données CTOH. La modification du catalogue va consister à redéfinir le fichier de description avec celui mise à jour précédemment.

Ci-dessous le fichier catalogue yaml mise à jour avec le fichier de description utilisateur du produit ja3_a_cnes_f_sgdr. Le produit est redéfinit avec le fichier de description utilisateur et son chemin absolu.

# Description of the CTOH DATA BASE    # common absolute path
    prod_name_pattern : (?P<alias_mission>[a-z,0-9]*)_(?P<orbit_phase>[a-z]{1})_(?P<supplier>[a-z]*)_(?P<version>[a-z,0-9]*|%)_(?P<type>[a-z]*)
    default_path: /ctoh/data/db/products     # list of products
    metadb_path: /ctoh/data/db/catalogue_yml/metadb
    products:
        tpx_a_cash_v0220_gdr     :    catalogue_yml/current/tpx_a_cash_v0220_gdr.yml
        ja3_b_cnes_f_sgdr        :    catalogue_yml/current/ja3_b_cnes_f_sgdr.yml

        #ja3_a_cnes_f_sgdr        :    catalogue_yml/current/ja3_a_cnes_f_sgdr.yml
        # Produit ja3_a_cnes_f_sgdr avec gdrtypes personnalisés : ales et rads
        ja3_a_cnes_f_sgdr        :    /home/b/blarel/Workspace/userdb/products_desc/ja3_a_cnes_f_sgdr.yml
        ...

Création d’une base méta donnée personnalisée

Tout d’abord, il est essentiel que la base de métadonnées soit stockée dans un répertoire spécifique où les différentes versions de métadonnées de chaque produit sont conservées. Un lien symbolique appelé « metadb » doit être créé pour faire référence à la version de métadonnées utilisée.

Pour ce faire, dans le cas d’une base de données personnelle, l’utilisateur devra créer lui-même un répertoire nommé « custom_metadata » comprenant un sous-répertoire appelé « metadb_clone ». Au sein du répertoire « custom_metadata », il devra ensuite créer un lien symbolique nommé « metadb » qui pointera vers le répertoire « metadb_clone ».

<usr_path>
    └── custom_metadata
            ├── metadb -> metadb_clone
            └── metadb_clone

Une fois que les métadonnées et le sous-produit ont été correctement structurés dans le répertoire de travail, l’étape suivante consiste à mettre à jour la base de données SQLite avec le nouveau gdrtype ajouté par l’utilisateur.

Cette tâche est réalisée à l’aide de la bibliothèque PyCTOH et de son outil de gestion de méta données alt_metadata accessible en ligne de commande.

1- Clonage de la base de méta données

Il s’agit de récupérer le fichier de méta données SQLite du produit ajouté la base personnelle et de le sauvegarder dans le répertoire local.

Ci-dessous un exemple de clonage du produit ja3_a_cnes_f_sgdr :

> alt_metadata -pja3_a_cnes_f_sgdr clone <user_path>/custom_metadata/metadb

2- Mise à jour des méta données

Suite au clonage de la base de méta données SQLite du produit, une mise à jour des méta données du produit de la base personnelle doit être faite.

Ci-dessous la mise à jour du produit ja3_a_cnes_f_sgdr avec le sous-produit ales de la base personnelle local de l’utilisateur :

> alt_metadata -pja3_a_cnes_f_sgdr -c user_catalogue.yml -m <user_path>/custom_metadata/metadb insert ales