POURQUOI DES CODES DETERMINES PAR DES TABLES? Niamey, 29 mars – 2 avril 2004 (Joël Martellet, OMM, Veille Météorologique Mondiale, Systèmes de Traitement des Données.

Download Report

Transcript POURQUOI DES CODES DETERMINES PAR DES TABLES? Niamey, 29 mars – 2 avril 2004 (Joël Martellet, OMM, Veille Météorologique Mondiale, Systèmes de Traitement des Données.

POURQUOI DES CODES DETERMINES PAR DES TABLES?

Niamey, 29 mars – 2 avril 2004

(Joël Martellet, OMM, Veille Météorologique Mondiale, Systèmes de Traitement des Données et de Prévisions)

Pourquoi des codes déterminés par des tables

?:

Plan

• Le passé:

codes alphanumériques fixes

• Le présent: évolution rapide de la science et des technologies • Solution:

codes déterminés par des tables

• Objectifs de ce séminaire • Qu’est-ce qui est différent?

• Quelques aspects généraux

des codes déterminés par des tables

• • •

POURQUOI DES CODES A L’OMM?

Un “code” OMM est une manière de représenter les données qui sont échangées internationalement entre les pays = une forme de représentation des données L’objectif est l’échange global des données météorologiques (ou associées à la météorologie ou l’hydrologie - e.g. marine, océanographie) sans ambiguïté, et de la manière la plus efficace pour leur utilisation par de nombreuses et différentes applications= INDISPENSABLE = transport de LA MATIERE PREMIÈRE DE LA MÉTÉOROLOGIE Le développement des Codes doit tenir compte des contraintes opérationnelles

LA REPRÉSENTATION DES DONNÉES

LE DÉVELOPPEMENT D’UN SYSTÈME DE REPRÉSENTATION DES DONNÉES POUR L’ ÉCHANGE ET LE TRAITEMENT EN TEMPS RÉEL DOIT TENIR COMPTE DES CONTRAINTES D’EXPLOITATION

• Le Passé : les contraintes, il y a plusieurs décades : – Des lignes de télécommunication avec une faible capacité (50 Bits/s) nécessitaient: • Des codes transmis par jeux de caractères • Des groupes de caractères standards (5 caractères) • Des systèmes de codage abrégés • Des valeurs de paramètre souvent traduites par un code plutôt que la valeur elle-même – Exploitation manuelle: • Lisibilité • Pas trop fréquent

Solution:

DES CODES À CARACTÈRES ALPHANUMÉRIQUES

Avant les codes météorologiques étaient vus!

CONSIDÉREZ LE FLUX DE DONNÉES DE LA VEILLE MÉTÉOROLOGIQUE MONDIALE (LE PASSÉ!)

Système Mondial d’Observation

SMO

:

Système Mondial de Telecommunication

SMT

Observateur

qui encode sur un télétype

Système Mondial de Traitement des Données et de Prévision

SMTDP

Papier télétype Pointage manuel

Prévisioniste

• Les anciens “codes” OMM étaient développés par type de données, TEMP, SYNOP, SATOB,

et c.

FM 42 AMDAR FM 41 CODAR FM 13 SHIP FM 35 TEMP FM 88 SATOB FM 87 SARAD FM 86 SATEM FM 85 SAREP

Aujourd’hui: une évolution technique rapide

• • • • • •

Les besoins croissent constamment pour les différentes applications météorologiques et environnementales: e.g. PNT et études globales du climat Augmentation constante du volume des données (e.g. satellite) et de la complexité des observations Plus grande précision exigée des mesures Plus grande résolution requise pour les observations (e.g. radiosondages, station automatiques de surface):

Dans le temps (plus fréquent)

– –

Dans l’espace (résolution verticale) Pour les modèles à très haute résolution non-hydrostatiques, toutes les observations de la radiosonde sont demandées (vol de la sonde, comme celui d’un avion) Nouveaux types de données observées et échangées (e.g. ozone, radiologie, niveaux de la mer, chimie de l’atmosphère, etc…) Des changements aux codes, impliquant de nouveaux types de données, sont demandés plus fréquemment

CODES OMM FIXES ALPHANUMERIQUES :

• • • •

Comment savons-nous ce que signifie la chaîne de caractères suivante dans un code alphanumérique ?:

:

98025 32325 11027??

PPPTT DDFFF LA POSITION ET LA CONVENTION DE CODAGE (EXPRIMÉE PAR LA FORME SYMBOLIQUE) DÉFINISSENT LES DONNÉES: DDDFF or FFDDD or FFFDD?

Groupes du code :

32325 11027 ? Comment savons nous ce que signifie cette chaîne de caractères?

• • •

Tout d’abord, il nous faut savoir dans quelle forme de représentation cette chaîne de caractères s’inscrit. Nous supposons qu’elle provient d’un bulletin de messages d’observations synoptiques; la forme de représentation est donc FM 12 SYNOP. En deuxième lieu, il nous faut connaître la position de ces deux groupes dans le message SYNOP: deuxième groupe et troisième groupe.

Troisièmement, il convient de se référer au Manuel des codes de l’OMM, Volume I.1 (Codes internationaux), Partie A (Codes Alphanumériques) pour y trouver la description de ces deux groupes dans la forme de la forme symbolique suivante: représentation SYNOP (à moins d’avoir appris par cœur le code SYNOP).

Ce faisant, nous trouvons que les deux groupes ci-dessus ont

32325 11027 = Nddff 1s n TTT

32325 11027

= Nddff 1s

n

TTT

• dans laquelle N = nébulosité totale, dd = direction du vent, ff = vitesse du vent, 1 est un indicateur de groupe, et TTT = est indiqué par s n .

température de l’air, dont le signe • Toutefois, ce n’est qu’en étudiant plus avant le Manuel des codes pour trouver la signification complète et les conventions de codage correspondant peut à cette forme symbolique que l’on déterminer alors que la couverture nuageuse du ciel est de 3/8, que le vent souffle de la direction de 230 degrés à 25 nœuds et que la température de l’air est de – 2,7 o C.

Nddff 1s

n

TTT

La position dans le message d’observation et la convention de codage attribuée à cette position dans la forme symbolique (soit dans le présent exemple Nddff 1s

n

TTT), définissent les données contenues dans les formes de représentation alphanumériques traditionnelles.

• • •

Et comment modifier un code traditionnel fixe, si, par exemple, on veut insérer un nouveau groupe?

S’il fallait insérer un nouveau groupe d’information avant les deuxième et troisième groupes à caractère obligatoire de la Section 1, les positions de ces deux groupes changeraient.

Une telle modification nécessiterait une actualisation correspondante de tous les programmes de codage ou de décodage de ces messages sinon le logiciel donnerait des valeurs erronées ou échouerait totalement.

En effet les conventions de codage les données sont intégrées dans les logiciel de traitement et non incluses dans le message lui pour laquelle alphanumériques d’accueillir de nouveaux types de données, sans lourdes modifications personnels).

des les formes traditionnelles logiciels (et utilisées pour décrire même. C’est la raison de sont de représentation incapables formation des

Exemple d’une forme de code traditionelle

SATOB (FM 88-XI) M i M i M j M j YYMMJ GGggw i I 6 I 6 I 6 // F 3 F 3 F 3 F 4 F 4 F 4 222 B 1 B 2 B 3 nn U La U Lo U La U Lo / P C P C T C T … … … C T a dddff … … … ...

• M i M i M j M j = YYXX (SATOB) • YYMMJ = Jour, mois, année • GGggW i • I 6 I 6 I 6 = Heures et minutes, type de vent (IR, WV, VIS) = Identificateur Satellite Les lettres symboliques sont définies dans le Manuel des Codes Alphanumériques et sont partagées par tous ces codes (e.g. SYNOP, TEMP, GRID, PILOT, RADOF, …)

Difficultés, sinon impossibilités:

• • • Les besoins évoluent mais les codes sont fixes Les changements nécessitent une longue préparation et ont un coût important car l’automatisation est venue!: – On doit modifier les logiciels à toutes les étapes des chaînes de traitement des données (de la station automatique à la base de données des archives, en passant par le décodage, le pré-traitement, etc..) – Les équipements sont faits par les industriels – Il faut faire aussi de la formation du personnel,

etc

.

– Les modifications aux Codes doivent être approuvées par un corps officiel de l’OMM: la Commission des Systèmes de Base, et puis la mise en œuvre par les Pays Membres peut prendre deux à quatre ans ou même plus Ceci est incompatible avec l’évolution moderne rapide de la science et des technologies

Alors on est bloqué !

• Le maintien des codes alphanumériques traditionnels empêcheraient l’échange d’informations critiques sur l’environnement entre les Services Météorologiques et Hydrologiques Nationaux et la diffusion à leurs usagers.

• Les contraintes pour l’échange des données deviendraient trop complexes. Les échanges deviendraient trop coûteux et demanderaient trop de ressources.

Donc, pourquoi des codes déterminés par des tables

?

Parce-que la météorologie opérationnelle évolue:

• Plus d’automatisation: – plus de traitement par ordinateur – Lignes à haute capacité (64kb/s, 1 Mb/s…) • Plus fréquemment: de nouveaux paramètres (e.g. satellite, océanographie) • Plus grande résolution – Dans le temps (plus fréquent (minute, seconde)) – Dans l’espace (balayage des satellites, énorme volume des données de satellite, vol de radiosonde avec les paramètres transmis à toutes les positions) • Plus grande précision des paramètres (e.g. température au centième de degré)

Puis, seulement les observateurs et les programmeurs voient réellement les codes météorologiques

CONSIDEREZ LE FLUX DE DONNÉES DE LA VEILLE MÉTÉOROLOGIQUE MONDIALE

:

Système Mondial d’Observation

SMO

Système Mondial de Telecommunication

SMT

Système Mondial de Traitement des Données et de Prévision

SMTDP

Observateur

qui encode sur un télétype Décodage et pointage automatique programme de visualisation

Prévisioniste

Et puis, dans beaucoup de cas le code météorologique n’est pas vu!

CONSIDEREZ LE FLUX DE DONNÉES DE LA VEILLE MÉTÉOROLOGIQUE MONDIALE

:

Programme d’encodage

Observateur Système Mondial d’Observation

SMO

Système Mondial de Telecommunication

SMT

Système Mondial de Traitement des Données et de Prévision

SMTDP

Décodage automatique programme de visualisation

Prévisioniste

Finalement le code météorologique n’est pas vu du tout!

CONSIDEREZ LE FLUX DE DONNÉES DE LA VEILLE MÉTÉOROLOGIQUE MONDIALE

Système Mondial d’Observation

SMO

(ENTIÈREMENT AUTOMATISÉ):

Système Mondial de Telecommunication

SMT

Système Mondial de Traitement des Données et de Prévision

SMTDP

Décodage automatique programme de visualisation

Prévisioniste

Station Météorologique Automatique, encodage automatique

Mais il faut considérer différentes fonctions au sein du flux des données

• Il faut distinguer les fonctions successives: – D’acquisition des données – De collecte des données – De transmission des données – De réception des données – De visualisation des données • Le format utilisé pour représenter les données peut être différent a chaque étape, si cela est plus efficace.

Le format utilisé pour représenter les données peut être différent a chaque étape, si cela est plus efficace.

Ne pas confondre les fonctions:

– – – – – –

D’acquisition des données: format des valeurs des capteurs de stations automatiques ( ou que l’observateur utilise pour noter l’obs.) De collecte des données: coder le messages contenant les obs. dans un format pour la collecte nationale De transmission des données: international OMM nécessaire garder le format (si standard OMM) pour la transmission internationale ou coder dans un autre système de représentation des données: standard Processus de transmission internationale : si possible ne pas changer le système de représentation des données choisi (« le format »), mais juste transmettre une »enveloppe » De réception des données: types d’applications décoder la forme de représentation des données pour rentrer dans une base de données ou d’autres De visualisation des données: visualiser les valeurs des données pour lecture par une personne (ex. prévi,) = convertir dans le meilleur format pour cet usage visuel.

• L’OMM est concernée par l ’Echange International des données et par les formats agrées pour ces échanges de données entre les pays.

• • Les formats nationaux peuvent être différents des standards recommandés par l’OMM si cela est plus approprié.

Nous avons besoin de nouveaux formats plus efficaces pour les échanges internationaux.

SOLUTION:

u

ne représentation des données qui offre:

– – – –

CAPACITÉ D’EXPANSION (ajouter facilement de nouveaux paramètres, changer facilement la précision)

AUTO-DESCRIPTION interne du contenu) (description FLEXIBILITÉ (pouvoir varier le contenu) DURABILITÉ (pouvoir lire les archives)

CONDENSATION (COMPRESION) l’échange efficace de données binaires numériques) (pour

• • • • •

SOLUTION:

u

ne représentation des données qui offre:

CAPACITÉ D’EXPANSION précision) (ajouter facilement de nouveaux paramètres, changer facilement la C’est ce que BUFR offre (et aussi CREX) et GRIB Edition 2 (GRIB 2) AUTO-DESCRIPTION (description interne du contenu) BUFR, CREX, GRIB 1 et GRIB 2 FLEXIBILITÉ (pouvoir varier le contenu) BUFR, CREX et GRIB 2 DURABILITÉ (pouvoir lire les archives) BUFR, CREX, GRIB 1 et GRIB 2

CONDENSATION (COMPRESION) (pour l’échange efficace de données binaires numériques) possible avec BUFR, GRIB 1 et GRIB 2

BUFR: Binary Universal Form for the Representation of (meteorological) data

conçue au début des années quatre-vingt- approuvée pour la mise en œuvre opérationnelle en novembre 1988-

Utilisée pour l’archivage de tous les types de données et pour l’échange opérationnel des données de satellite, des ASDAR, AMDAR , des données de profileur de vent, des données des cyclone tropicaux, des données ARGOS: bouées, XBT, XCTD, des SHIP japonais, des stations automatiques européennes AWS, des Radiosondes des États-Unis

CREX: Character form for the Representation and Exchange of data

Alphanumérique (CTA) et quand BUFR ne peut être utilisée –

pour l’échange opérationnel des données d’ozone, des données

conçue dans les années quatre-vingt dix (c’est l’image de BUFR en caractères) – approuvée pour la mise en œuvre opérationnelle en mai 2000- conçue pour les types de données à qui ne correspond pas de Code Traditionnel

Utilisée radiologiques, du niveau de la mer, des données hydrologiques, des températures du sol et d’information sur les cyclones tropicaux (c’est aussi un bon outil pour comprendre BUFR) – ce peut être une solution intérimaire avant BUFR si l’on ne peut pas transmettre des données en format binaire.

Objectifs du séminaire

• • • • • • •

Comprendre comment fonctionnent les Codes Déterminés par des Tables (CDTs)! : CREX et BUFR Apprendre comment gérer les programmes d’encodage et de décodage Les additions aux Codes Déterminés par des Tables : comment çà marche?

Comprendre comment convertir des Codes Alphanumériques Traditionnels (CATs) en CREX et BUFR Comprendre comment utiliser et mettre en oeuvre dans les chaînes de traitement les logiciels d’encodage et de de décodage Comprendre comment organiser la migration internationale vers les CDTs (Plan de Migration) - Que faire pour la Région I?

Comprendre ce qu’il faut faire pour démarrer opérationnellement la migration au sein du Système de la Veille Météorologique Mondiale

CODES DETERMINES PAR DES TABLES

• L’intention est d’échanger l’information efficacement et sans ambiguïté • Le format doit permettre la transmission de toute l’information (pas d’arrondi ou de saut de données) • Le format doit permettre l’addition de nouveaux types de données • Le format sera général, indépendant du type de données

• • CODES DETERMINES PAR DES TABLES

Dans une forme symbolique déterminée par des tables il existe également des règles en matière de position mais elles ne s’appliquent qu’à la forme du « conteneur » (ou de la structure du code) plutôt qu’à son contenu. Ces règles définissant la structure sont les mêmes quelles que soit le type des données: « une structure physique unique pour tous les types de données ». La présence et la forme des données sont décrites dans le «conteneur» lui-même. C’est ce que l’on appelle le concept d’ AUTO DESCRIPTION.

Pour ce faire, il existe dans les messages BUFR et CREX (et GRIB) une section (la SECTION DE DESCRIPTION DES DONNÉES dans le message. ) dans laquelle sont définis le type et la forme des données contenues

LA SECTION DE DESCRIPTION DES DONNÉES Cette Section contient en fait une suite de descripteurs de données qui font office « d’indicateurs » désignant des éléments dans des TABLES prédéfinies et convenues au plan international (inscrites dans le document officiel intitulé Manuel des codes de l’OMM). Chaque descripteur définit comment un paramètre doit être codé, et également, comment il peut être décodé, quand on lit le message.

• •

D’où la définition de CODES DÉTERMINÉS PAR DES TABLES Toutes les données à transmettre doivent donc être au préalable définies dans les Tables du Manuel de l’OMM (ex.: nom, unité, (Température, deg. K), taille: 9 bits,…)

Descripteurs dans la Section de Description des Donnes La Dans le MESSAGE: Section de Description des Données : j’y vois la Liste des Descripteurs Dans le Manuel de l’OMM: Ensemble des TABLES contenant l’Ensemble des Descripteurs Chaque Descripteur définit comment un paramètre (un élément) doit être codé: si je sais ça, je peux décoder la donnée correspondante et l’ensemble des données de la Section des Données (bien évidemment, les données doivent y être encodées dans le même ordre que celui des descripteurs de la Section de Description des Données, et le décodeur (programme ou humain) doit avoir accès aux Tables du Manuel)

CODES DETERMINES PAR DES TABLES •

Une fois la Section de description des données lue, la section suivante, qui contient les données à proprement parler: LA SECTION DES DONNÉES, peut être comprise. Comme on l’a dit, les caractéristiques des paramètres à transmettre doivent déjà être définies dans les tables du Manuel des Codes de l’OMM avant que les données contenant ces paramètres puissent être échangées dans des messages BUFR ou CREX (ou GRIB).

Structure Générale

Les Codes Définis par des Tables ont en général cette structure  • • • • • •

Indicateur:

GRIB/BUFR/CREX

Identification:

Date, heure, origine, numéro d’édition, numéro de version des tables ...

Section facultative:

e.g. plus de Metadonnées, données privées …

Section de description des données :

Quelle sorte de données suit (pointeurs vers les Tables du Manuel qui identifient les données transmises)?

Section des données :

les données sont ici

Fin:

“7777”

• • • •

Lorsqu’il est nécessaire de transmettre de nouveaux paramètres ou de nouveaux types de données, il suffit d’ajouter de nouveaux éléments aux tables BUFR et CREX de l’OMM, après approbation par la CSB (Commission des Systèmes de Base de l’OMM). Etant donné que les formes de représentation des données déterminées par des tables peuvent décrire de nouveaux paramètres par simple adjonction d’un nouvel élément dans la table de code appropriée, elles présentent la flexibilité voulue pour transmettre une variété infinie d’informations = FLEXIBILITÉ totale .

Il n’est donc plus nécessaire de définir de nouvelles « formes symboliques ». L’expansion des tables officielles OMM suffit = EXPANSION possible . Le numéro d’édition du format (structure du message) et le numéro de version des tables sont transmis dans le message lui même ce qui permet de traiter d’anciennes données archivées = DURABILITÉ .

• • •

DANS LA SECTION DES DONNÉES:

DANS BUFR, LA VALEUR TRANSMISE D’UN ÉLÉMENT (PARAMÈTRE) SERA CONVERTIE EN REPRÉSENTATION BINAIRE ET DONC EXPRIMÉE PAR UN ENSEMBLE DE BITS. DANS CREX, LA VALEUR TRANSMISE DE L’ ÉLÉMENT RESTERA EN REPRÉSENTATION DÉCIMALE ET DONC SERA EXPRIMÉE PAR UN ENSEMBLE DE CARACTÈRES (BYTES). CREX EST L’IMAGE EN CARACTÈRES DE BUFR. AINSI, IL EST TRÈÈS FACILE ET SIMPLE DE LIRE UN MESSAGE CREX.

DANS BUFR ET CREX LES VALEURS DES PARAMÈTRES SONT SIMPLEMENT CODÉES DANS L’ORDRE QUE L’UTILISATEUR VEUT. LES VALEURS SONT COMME DANS UNE LISTE: LES UNES APRÈS LES AUTRES.

Caractéristiques des Codes Déterminés par des Tables (1)

• Flexibles et dynamiques • Amendés par des révisions des Tables OMM officielles (Manuel des Codes) qui contiennent les éléments normalisés qui sont le « standard » • Les Tables des Codes sont coordonnées globalement par l’OMM • Les Tables « globales » des Codes de l’OMM sont mises à jour tous les ans, mais plus souvent en version pré-opérationnelle. • Des tables « locales » (c’est-à-dire nationales) sont autorisées mais pas pour les échanges globaux.

Caractéristiques des Codes Déterminés par des Tables (2)

• Les messages s’auto-décrivent: – Type – Contenu – Numéro d’ édition du Code OMM – Numéro de version des Tables du Code OMM – Longueur des sections • Les données d’en-tête sont toujours à des positions fixes pour un accès rapide sans décodage = structure fixe • La section facultative peut contenir n’importe quoi

• •

BUFR-CREX

BUFR a un avantage par rapport à CREX: il offre la compression, donc les données volumineuses (ex. satellites, ACARS, profileurs de vent) nécessiteront moins de volume pour la transmission et le stockage. Mais le grand inconvénient, c’est que personne ne peut le lire (facilement!!) et il nécessite absolument un logiciel encodeur et un logiciel décodeur

Exemple de Message BUFR

UN MESSAGE TEMSI DE JET (SMPA)

• JUWD96 EGRR 171200 • BUFR**J’$%…”£ 5--..>>%^&12&12)) ++$$mM…>R3%^£^)IUYG)£$Y+___56^ ^..= • +>>7777

• • • • • • • • • • • • • • •

Message décodé

14 25.4 -117.0 -9999999.0 -9999999.0

27.0 -111.9 -9999999.0 -9999999.0

27.3 -110.9 -9999999.0 100.0

28.6 -103.0 -9999999.0 -9999999.0

28.4 -96.7 -38000.0 110.0

28.1 -91.6 -9999999.0 -9999999.0

28.5 -84.6 -9999999.0 -9999999.0

30.8 -77.9 -9999999.0 -9999999.0

32.0 -75.1 -9999999.0 -9999999.0

35.5 -67.6 -37000.0 120.0

38.6 -60.8 -9999999.0 -9999999.0

39.0 -53.8 -9999999.0 -9999999.0

38.6 -51.7 -9999999.0 100.0

35.8 -45.6 -9999999.0 -9999999.0

• • • • • • • •

Un message BUFR de 100 AMDARs

0306301824LFPW_ 374 IUAX02 KARP 301820 BUFR _ú_ _ 8 _________ _ ! ÁAÁBË_ _!_!___C__ †__ë _¾ FNETYTBAFNMEISJA_ÉÒjJ  “-8 >›=$^Z’MìâqC__€‘a¿ÿ€_¿ø?ƒø?ƒú²Ê ªšR • • • • • • • • • • • ÿ_ð_ðVYXAUSJARQTYCNRA_ÉÒjJ _é³ÒK%ª$Ýl÷”;ÈØ µ·ÿø Kÿƒø?ƒø?™&+¡!™¨ªš¤¤¡ª hˆ)ëH¨*扊* _}¿ÿÿÿ¿ø?ƒø?ƒúʪ_¢ÊÊ ‘U_ _Mž‘_º__´'_eAo _ÿÀr_ü_Áü_ÁýeU Qee_Ea_E_UUI_C'HHª„ _¦ÏH¿Ý__ ÿ_ð_ðYUCTYYAQXDQGUURA_ÉÒ_*¡ _é³ÒG÷H ´¤áŒ¨9æ$_ƒÿø_Kÿƒø?ƒø?¬ª¡ª,¬ ¨¬"(£ªª© ˆdé _P€_ôÙé)û¥@_‚pÆT_è_¸Åÿü_%ÿÁü_Áü_Ô_Œ_”ÒV Ddtš¦ @ úlô‰ý¥ù_«`_ TÉÄ_P\ Vc?ÿð_— µœ_•bÿÿÿþÿàþ_àþ_ê F >›=%?_œ;_J‡ÊÏ_Á!_Ÿÿÿÿ¿ø?ƒø?ƒúZ2ª__‚¢‰ª _¦ÏIG˜ _Óg¤°ëìŠ_GSÙ‰…8;a{ÿÿÿ÷ÿ_ð_ðRJOBV4BAQ11ZMQJA_!¢"*q _é³ÒR_NCÛ_¨|¬òª_qÕÿÿÿûÿƒø?ƒø?¥¥ ¡"¨' ¢"£&_©% ˆdéQU0€_ôÙé'³_r f¤´‚!“¤4…2 M_Ô_T D2t˜ }6zI~Äìe!úÿ„_6Àjß¿ÿÿÿð_ð_óU”TDUd¤_Dµ_•#D$__ >›=$ÿbn2ŠêïÂÈ_€5j?ÿÿÿ¿ø?ƒø?ƒùªÊ*"*²R ¢Z‚Ê‘¢__†N“_TÈ _Mž’Ÿ±1_>lÓᯰ€_²oÿÿÿßü_Áü_Áý]ee MEI_A8Á_%II_C&Š j_ _¦ÏIKXvŒ‡_w²gwØCK?ÿÿÿïþ_àþ_àþª° ¤²Šf‚¨œ‚`’Š”‚!“¤$ä_ _Óg¤§ìNI}ÌÝù_4_2fSÿÿÿ÷ÿ_ð_ðH44RSUEQKX1GXFJA_ÉÒ¢‚ _é³ÒR_·ÄÂs¸t_¸¸ _Ñÿÿÿûÿƒø?ƒø?¡_7777=

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • Premier AMDAR décodé ( partie 1) Buffer Nummer: 1 Untermeldung 1 (mit 54 Elementen): 301065 Sequence: ACARS IDENTIFICATION -1e+09 YXXNN AIRCRAFT FLIGHT NUMBER FNETYTBA YAIRN AIRCRAFT REGISTRATION NUMBER FNMEISJA NIX TYPE OF STATION 0 NIW TYPE OF INSTRUMENT.FOR WIND MEASUREMENT 4 MPOTO PRECISION OF TEMPERATURE OBSERVATION 0.25

NADRS TYPE OF AIRCRAFT DATA RELAY SYSTEM 3 NOSLL ORIGINAL SPECIF. OF LATITUDE/LONGITUDE 10 YAGRS ACARS GROUND RECEIVING STATION MIA End Seq End Sequence -1e+09 301066 Sequence: ACARS LOCATION -1e+09 301011 Sequence: DATE -1e+09 MJJJ YEAR 2003 MMM MONTH 6 MYY DAY 30 End Seq End Sequence -1e+09 301013 Sequence: HOUR/MINUTE/SECOND -1e+09 MGG HOUR 18 NGG MINUTE 20 MSEC SECOND 14 End Seq End Sequence -1e+09 301023 Sequence: LATITUDE/LONGITUDE, COARSE ACC -1e+09 MLALA LATITUDE (COARSE ACCURACY) 26.88

MLOLO LONGITUDE (COARSE ACCURACY) -77.03

End Seq End Sequence -1e+09 MPN PRESSURE (VERT.LOCATION) 19680 MQARA AIRCRAFT ROLL ANGLE QUALITY -1e+09 MPHAI PHASE OF AIRCRAFT FLIGHT 3 End Seq End Sequence -1e+09

• • • • • • • • • • • • • • • • • • • • • • • • • Premier AMDAR décodé ( partie 2) 311003 Sequence: ACARS STANDARD REPORTED VARIAB -1e+09 MIAA INDICATED AIRCRAFT ALTITUDE 11887 NDNDN WIND DIRECTION 23 NFNFN WIND SPEED 22.6

MTN TEMPERATURE/DRY BULB TEMPERATURE 217.2

MMIXR MIXING RATIO -1e+09 End Seq End Sequence -1e+09 MUUU RELATIVE HUMIDITY -1e+09 MAIV ACARS INTERPOLATED VALUES -1e+09 MMRQ MIXING RATIO QUALITY -1e+09 NGGTI TIME INCREMENT -1 Loop000 Start of Loop - 103004 12 Lcnt000 Loop Counter 0 NGGTM DURAT.OF TIME RELAT.TO FOLLOWING VALUE 1 011235 Unknown Descriptor -1e+09 Lcnt000 Loop Counter 1 NGGTM DURAT.OF TIME RELAT.TO FOLLOWING VALUE 1 011235 Unknown Descriptor -1e+09 Lcnt000 Loop Counter 2 NGGTM DURAT.OF TIME RELAT.TO FOLLOWING VALUE 1 011235 Unknown Descriptor -1e+09 Lcnt000 Loop Counter 3 NGGTM DURAT.OF TIME RELAT.TO FOLLOWING VALUE 1 011235 Unknown Descriptor -1e+09 EndLoop End Loop -1e+09

Compression

• BUFR permet une compression des données efficace par: –

l’Usage d’échelle et de valeur de référence pour les descripteurs d’élément;

– –

la combinaison de plusieurs descripteurs d’élément en un seul descripteur (séquence commune); la“compression BUFR” qui fait partie des spécifications (règles) de BUFR.

La compression est réalisée par un algorithme défini dans les règles du code. Pour BUFR (et GRIB), des algorithmes de compression ont été définis dans le Manuel.

• CREX ne permet pas de compression efficace (pourtant zip?); il n’est évidemment pas fait pour les données volumineuses (e.g. données des satellites)

• • • • •

BUFR-CREX

CREX

procure flexibilité et lecture humaine directe.

Mais pour la transmission de beaucoup ou de gros messages, Il nécessite un volume substantiel de caractères.

(cependant, si on le considère comme un paquet de bits, en appliquant des algorithmes de compression, il peut être compressé comme tout fichier d’information)

.

Les Tables de CREX ont les mêmes paramètres que les Tables de BUFR, les règles sont similaires, mais CREX est plus simple.

Il n’y a pas de compression, ni la possibilité d’associer des données type indicateurs de qualité (« flags ») ou valeurs de substitution. CREX est l’image de BUFR et offre un standard (pas nécessairement le meilleur) pour la visualisation (lire et décoder) l’information de BUFR.

UN EXEMPLE TRES SIMPLE DE CREX

CREX++ T000101 A000 B05002 B06002 B11001 B11002++ 5504 -00510 260 0246++ 7777

• CREX Table maîtresse OMM, édition 1 du code, version 1 de la Table • Données de Surface: latitude, longitude, direction et vitesse du vent • Coordonnées: 55°04 Nord, -5°10 Ouest ,Vent: direction 260 degrés, vitesse 24.6 m/s

CODER EN CREX LES LIGNES DE GRAINS: Observations (3 points), trajectoire et évolution: CREX++ T00020412// A007001 P00012000 U00 S001 Y20050823 H1830 D16060 ++ 2005 08 23 17 50 1500 –01000 070 00010 1900 –00840 1100 –01220 02 0038 0300++

SECTION DE DESCRIPTION DES DONNÉES:

7777 T00020412//

= 00 = Numéro de la table principale (« Master ») = pour la météorologie 02 = Numéro d’édition de CREX

A007001 P00012000 U00 S001

= =

Y20050823 H1830 D16060

= = = = = 04 = Numéro d’édition de BUFR 12 = Numéro de version des tables BUFR/CREX // = Pas de table locale 007 = Caractéristique synoptique 001 = Ligne de grains 00012 = Centre d’Origine = Dakar 000 = Pas de centre secondaire 00 = Numéro de séquence (de mise à jour) du message =

0 = premier

001 = Nombre de sous série de données = 1 Date du message = année, mois, jour Heure du message = heure, minute

Numéro de séquence commune définissant les descripteurs pour une ligne de grains (type 1) (voir le Manuel):D01012, D01011, B05002, B06002, B19005, B19006, B05002, B06002, B05002, B06002, B20048, B11041, B13055

CODER EN CREX LES LIGNES DE GRAINS: Observations (3 points), trajectoire et évolution: CREX++ T00020412// A007001 P00012000 U00 S001 Y20050823 H1830 D16060++ 2005 08 23 17 50 1500 –01000 070 00010 1900 –00840 1100 –01220 02 0038 0300++ 7777

SECTION DES DONNÉES (Partie 1):

Date et heure de l’observation: 2005 08 D01011 Date:

= Année = Mois

23 17 50

= Jour

D01012 Heure:

= Heure = Minute

Position du centre de la ligne de 1500 grains: B05002 Latitude:

= 15 deg. Nord

-01000 070 00010 B06002 Longitude :

= 10 deg. Ouest

B19005 Direction (vers) du déplacement:

= 070 degrés

B19006 Vitesse de déplacement:

= 10 m/s

CODER EN CREX LES LIGNES DE GRAINS: Observations (3 points), trajectoire et évolution: CREX++ T00020412// A007001 P00012000 U00 S001 Y20050823 H1830 D16060++ 2005 08 23 17 50 1500 –01000 070 00010 1900 –00840 1100 –01220 02 0038 0300 ++ 7777

SECTION DES DONNÉES (Partie 2):

Amplitude: points les plus Côté Nord: éloignés du centre: B05002 Latitude: 1900

= 19 deg. Nord

B06002 Longitude: -00840

= 8 deg. 40 Ouest

Côté Sud: B05002 Latitude: Table de Code B 20 048

Evolution du phénomène

Chiffre du Code 0 Stabilité 1 Diminution 2 Intensification 3 Inconnue 4 14 En réserve 14 99 Non utilisé

1100 -01220

= 12 deg. 20 Ouest

02

=

0038 0300

= = = 11 deg. Nord

B06002 Longitude: B20048 Evolution:

Intensification

B11041 rafale maximum attendue:

38 m/s

B13055 intensité des précipitations attendues:

300 mm/h

EXEMPLE POUR SYNOP: Un message SYNOP d’une station en haute altitude de la Région VI - la station VAN (Turquie): SMTU10 LTAA 230600 AAXX 23064 17170 11665 60907 10025 21030 38444 48605 333 52026 69942 70262 83540 21035 3/105 42002 70025 83635 86359= KSMDii LTAA 230600 CREX++ T000104 A000 D07222 ++ 17 170 1 2005 11 23 06 00 3845 04332 16690 16620 08444 ///// 0026 02 08500 0160 5 14 090 0035 025 -030 067 1500 002 06 02 075 07 03 0105 35 24 10 0002 01 03 06 0105 02 06 03 0270 12 -052 00002 00025 -0012 00004 00205 -0012 //// -0012 -0350++ 7777 Note: Les groupes soulign é s dans la section des donn é es Repr é sentent des informations additionnelles (m é tadonn é es) (qui sont importantes et) qui ne sont pas incluses dans un message SYNOP.

• • • • • • • •

EN RESUMÉ:

LES CODES DÉTERMINÉS PAR DES TABLES, COMME BUFR, CREX ET GRIB 2 OFFRENT

:

AUTO-DESCRIPTION FLEXIBILITÉ EXPANSION FACILE DURABILITÉ

CONDENSATION (COMPRESSION) POUR BUFR LECTURE FACILE POUR CREX

ILS OFFRENT DES DONNÉES DE MEILLEURE QUALITE QUI PERMETTRONT DE GÉNÉRER DES PRODUITS MEILLEURS AU 21ème SIÈCLE, ILS DOIVENT ÊTRE UTILISÉS POUR LES PROGRÈS DE LA MÉTÉOROLOGIE, DE L’HYDROLOGIE, DE L’OCÉANOGRAPHIE ET DES ÉTUDES CLIMATIQUES

MERCI POUR VOTRE ATTENTION Questions???