.. _custom_data_base: ============================ 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. .. admonition:: 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 .. code-block:: text 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. .. code-block:: yaml 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 : (?PJA3)_[A-Z]{3}_2P(?P[A-Z,a-z])P(?P\d{3})_(?P\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. .. code-block:: yaml # Description of the CTOH DATA BASE # common absolute path prod_name_pattern : (?P[a-z,0-9]*)_(?P[a-z]{1})_(?P[a-z]*)_(?P[a-z,0-9]*|%)_(?P[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 ... .. Ajout d'un sous produit personnel à la base de données CTOH (SAF) .. ################################################################# .. Dans une première étape au niveau de la base SAF, il faut que le nouveau .. grdtype de l'utilisateur : .. * soit installé dans un espace de travail local de l'utilisateur et qu'il .. respecte: .. 1- la même :ref:`db_structure_ref` que dans la base de données .. du CTOH .. 2- la convention de nommage définit dans la base de données et .. notamment dans le :ref:`fichier de description du produit .. ` (paramètre ``file_postfix``). .. 3- la conformité avec les variables de dimensions (nommage et taille) .. avec le :ref:`produit de référence ` (gdr ou .. sgdr) mais également contenir les mêmes paramètres de temps et .. de coordonnées. .. * soit associé à un nouveau nom de produit dans un catalogue personnel de .. l'espace de travail local de l'utilisateur avec également son fichier de .. description produit : .. 1- Copier le catalogue de la base de données du ctoh. .. 2- Modifier le nom du produit auquel sera ajouter le nouveau gdrtype. .. Ce nom doit être unique et respecter la convention de nommage défini .. dans le :ref:`fichier catalogue ` (expression regex .. du paramètre ``prod_name_pattern``). .. 3- Copier, renommer (conformément à 2-) et Modifier le :ref:`fichier de .. description du produit ` en ajoutant au .. paramètre ``gdrtype_prefix`` le gdrtype et son chemin absolue vers le .. nouveau gdrtype. 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". .. code-block:: console └── 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 :ref:`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`` : .. code-block:: console > alt_metadata -pja3_a_cnes_f_sgdr clone /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 : .. code-block:: console > alt_metadata -pja3_a_cnes_f_sgdr -c user_catalogue.yml -m /custom_metadata/metadb insert ales