Systèmes de gestion des données climatologiques : propriétés souhaitables

 Modèle de base de données

Toute base de données climatologiques reposera sur un modèle de données sous-jacent, très important pour la qualité du système qui sera développé, en particulier pour sa maintenabilité (rappelons que plus de 50% des efforts mis en œuvre pour l’élaboration d’un logiciel sont consacrés à la maintenance et à l’amélioration du système au fil des années). Si le modèle n’est pas adapté, le système sera plus difficile à maintenir. En général, une base de données conçue en priorité pour des travaux météorologiques en temps quasi-réel sera principalement accessible de manière « synoptique », puisque les extractions répondront généralement au besoin de « rassembler toutes les données de quelques endroits ou zones donnés, ceci pendant une période définie et relativement courte ». En revanche, les applications climatologiques impliquent généralement l’extraction de données d’une ou plusieurs stations, sur une longue période. Ainsi, une approche plus vaste du stockage de données climatologiques implique de stocker ensemble (pour des données quotidiennes) toutes les données liées à une station donnée et à un jour précis. On peut procéder de la même façon pour des données horaires et mensuelles. Une autre approche consiste à stocker séparément des données de type différent, avec un tableau (dans le cas de bases de données relationnelles) contenant toutes les données de température de l’air pour toutes les stations et toutes les dates, etc. Voir paragraphe 5.2 pour plus de détails. Outre la qualité naturelle de la conception, les autres critères à prendre en compte sont notamment la façon dont le modèle de données est documenté et sa facilité d’extension par des programmeurs. L’une des exigences clés d’un modèle de données est qu’il doit être capable de représenter les données transmises par tous les formats de messages standards de l’OMM : TEMP, PILOT, METAR/SPECI, CLIMAT, CLIMAT_TEMP et SYNOP. Des considérations similaires s’appliquent au « modèle de métadonnées ». Dans un sens, il s’agit d’un domaine plus complexe car les structures de métadonnées peuvent être plus complexes que les structures de données. Il conviendra de définir en temps utile un modèle standard de métadonnées pour les données climatologiques (élargissant les travaux déjà réalisés sur la norme de l’OMM relative aux métadonnées de base). À ce moment-là, il sera souhaitable que la capacité d’intégration dans ce modèle de données soit un critère de sélection pour les systèmes climatiques.

Principales caractéristiques de saisie

La qualité fondamentale d’un système de saisie de données est de ne pas introduire de défauts évitables dans le processus de saisie. Le personnel chargé de ce travail est généralement très compétent en la matière et mérite qu’on lui assure des conditions de travail productives à tout moment. Cela signifie que le système de saisie de données ne doit pas comporter de défauts agaçants, pouvant ralentir l’opérateur de saisie. De manière idéale, les formes affichées à l’écran pourront être personnalisées de manière à optimiser la saisie de données. Le système doit également, dans la mesure du possible, valider les données à mesure de leur saisie, c’est-à-dire repérer les erreurs et, si possible, proposer des valeurs de remplacement. Il est possible aussi de définir des valeurs par défaut pour certains éléments, ce qui évite des combinaisons de touches inutiles. L’autre caractéristique utile est la double saisie, qui permet de limiter les erreurs (toutes les données sont saisies deux fois, celles saisies par le deuxième opérateur étant automatiquement comparées à celles saisies par le premier).

Options d’entrée électronique des données

Comme mentionné précédemment, il est souhaitable que le système de gestion des bases de données climatologiques soit en mesure de représenter tout le contenu des messages de format standard de l’OMM (SYNOP, CLIMAT, etc.). Un autre avantage serait qu’il puisse décoder des messages directement dans la base de données climatologiques. Dans certains cas (notamment pour les messages mensuels CLIMAT et CLIMAT TEMP), il est également souhaitable d’avoir des systèmes capables de générer ce type de messages à partir des informations contenues dans la base de données. Parmi les autres options d’entrée électronique utiles, on note la capacité d’entrer des données provenant des stations météorologiques automatiques et la capacité d’incorporer des données exportées du système CLICOM. En général, cette dernière option devrait être réalisée en une seule fois, au moment du changement de système (voir paragraphe 5.4).

Éléments liés à la qualité et métadonnées associées

Une donnée météorologique doit être accompagnée de toute une série d’informations sur sa qualité : qualité attribuée à la donnée en elle-même (commentaires du type « apparemment correcte », « suspecte », « incohérente avec d’autres données », etc.), nature de l’essai ou des essais réalisés pour générer l’indicateur de qualité, etc. Ces informations relatives à la qualité constituent un large éventail de métadonnées, portant, par exemple, sur l’instrument utilisé pour l’observation, sur la piste d’audit des observations faisant état de tous les changements opérés depuis la première saisie des données, sur des informations complètes concernant le site, sur les programmes d’observation en vigueur, etc. À plus long terme, le système sera pleinement en mesure de représenter tout l’historique de la station.

Étendue des contrôles de qualité effectués sur les valeurs observées

Les contrôles appliqués pour déterminer la qualité d’une observation peuvent aller du plus simple au plus complexe. Ces contrôles portent notamment sur les points suivants, présentés ici approximativement par ordre croissant de complexité :
• contrôles syntaxiques (ex : la température de l’air doit être exprimée par une valeur ayant au plus un chiffre après la virgule) ;
• plages numériques (ex : la température doit se situer entre -90 et +70) ;
• contrôles de l’éventail de climats (ex : est-ce que les données sont cohérentes avec la climatologie ?) ;
• cohérence entre les relevés (ex : la température de l’air ne doit pas être inférieure au point de rosée) ;
• cohérence des séries chronologiques (ex : la différence entre deux températures observées successivement sur le même site doit être « plausible ») ;
• cohérence spatiale (ex : les limites d’une différence plausible entre les températures d’une station et de ses environs ne doivent pas être dépassées).

Extraction de données

Un aspect important d’un système de gestion des bases de données climatologiques est à la fois l’étendue et la puissance des fonctions d’extraction et d’analyse des données. De manière idéale, les données peuvent être extraites via une interface graphique utilisateur ou bien via une interface en ligne de commande, selon le cas. Il sera préférable de fournir une interface graphique pour l’immense majorité des utilisateurs, les fonctions liées au langage d’interrogation étant réservées à une poignée d’utilisateurs plus avancés qui ont besoin d’effectuer des extractions non standard. Les utilisateurs qui en sont capables doivent avoir la possibilité de spécifier leurs propres critères d’extraction (généralement via l’interface graphique), et le système doit être correctement documenté afin de leur donner le maximum d’informations pour ce faire. Le système doit également proposer un large éventail d’options permettant de déterminer la structure de l’extraction et la présentation des résultats et de spécifier une extraction grâce à une personnalisation des stations, de l’horaire et des détails de présentation. Ces options doivent permettre d’accéder à des listes de données, de résumés tabulaires, d’analyses statistiques (simples et complexes) et de présentations graphiques.