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ÉESLE 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

Système Mondial

de Traitement des Données et

de Prévision

SMTDP

Observateurqui encode

sur un télétype

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 13 SHIPFM 42 AMDARFM 41 CODAR

FM 35 TEMP FM 88 SATOBFM 87 SARADFM 86 SATEMFM 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 représentation SYNOP (à moins d’avoir appris par cœur le code SYNOP). Ce faisant, nous trouvons que les deux groupes ci-dessus ont la forme symbolique suivante:

• 32325 11027 = Nddff 1snTTT

32325 11027 = Nddff 1snTTT • dans laquelle N = nébulosité totale, dd = direction du

vent, ff = vitesse du vent, 1 est un indicateur de groupe, et TTT = température de l’air, dont le signe est indiqué par sn.

• 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 à cette forme symbolique que l’on peut 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 oC.

Nddff 1snTTT

• 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 1snTTT),

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 utilisées pour décrire les données sont intégrées dans les logiciel de traitement et non incluses dans le message lui-même. C’est la raison pour laquelle les formes de représentation alphanumériques traditionnelles sont incapables d’accueillir de nouveaux types de données, sans lourdes modifications des logiciels (et de formation des personnels).

Exemple d’une forme de code traditionelle

SATOB (FM 88-XI)

MiMiMjMj YYMMJ GGggwi I6I6I6// F3F3F3F4F4F4

222 B1B2B3nn ULaULoULaULo/ PCPCTCTCTa dddff … … … … … … ...• MiMiMjMj = YYXX (SATOB)• YYMMJ = Jour, mois, année• GGggWi = Heures et minutes, type de vent (IR, WV, VIS)• I6I6I6 = Identificateur SatelliteLes 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 :

Décodage et pointage

automatique programme de visualisation PrévisionisteObservateur

qui encode sur un

télétype

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

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 :

Décodage automatique

programme de visualisation Prévisioniste

Programme d’encodageObservateur

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

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 (ENTIÈREMENT AUTOMATISÉ):

Station Météorologique Automatique,

encodage automatique

Décodage automatique

programme de visualisation Prévisioniste

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

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: garder le format (si standard OMM) pour la transmission internationale ou coder dans un autre système de représentation des données: standard international OMM nécessaire

– 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: décoder la forme de représentation des données pour rentrer dans une base de données ou d’autres types d’applications

– 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:

une représentation des données qui offre: – CAPACITÉ D’EXPANSION (ajouter

facilement de nouveaux paramètres, changer facilement la précision)

– AUTO-DESCRIPTION (description interne du contenu)

– FLEXIBILITÉ (pouvoir varier le contenu) – DURABILITÉ (pouvoir lire les archives)– CONDENSATION (COMPRESION) (pour

l’échange efficace de données binaires numériques)

SOLUTION:

une représentation des données qui offre: • CAPACITÉ D’EXPANSION (ajouter facilement de

nouveaux paramètres, changer facilement la précision) 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 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 Alphanumérique (CTA) et quand BUFR ne peut être utilisée – Utilisée pour l’échange opérationnel des données d’ozone, des données 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 laquelle sont définis le type et la forme des données contenues dans le message.

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

Dans le MESSAGE:La 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 desdescripteurs 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

• 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”

Les Codes Définis par des

Tables ont en général

cette structure

• 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 _é³ÒPåµ__#Øl¿ü._Pùÿÿÿûÿƒø?ƒø?§£«¢-#) _©$¡˜¥

ˆdé5_`€_ôÙé'2º1û’W6V<D_XïÿÿÿýÿÁü_Áü_Ö”’PÐŒ_RP”RPÕTDÈh„ž’@ úlô”9¡hÇTwŸ_å _çÿÿþÿàþ_àþ_éª&hŠ� � �©Ê)«HI†jjH"_:HRL }6zJ&´ ´“-8_V?ÿÿÿð_ð_õe•„_U4¤_%_E”4å$__&¤  >›=$^Z’MìâqC__€‘a¿ÿ€_¿ø?ƒø?ƒú²ÊÂ�� � � � � � � �

• ªšR• ’Š¢Ê_r’_†N“RPH _Mž’9-K&ôm_¡ ']¯OÿÀ__ü_Áü_ÁýYea_UM)_IEQe�• 9I_C'I©($ _¦ÏI"–¦“xµ”PßSˆ)WGÿà_/þ_àþ_àþ¬²°‚ª¦”‚¤¢¨²†œ¤‚!“¤Ô”_ _Óg¤“ËSÉ»š(qÁÄ_«—ÿð —ÿ_ð_ðVYXAUSJARQTYCNRA_ÉÒjJ� � �

_é³ÒK%ª$Ýl÷”;ÈØ µ·ÿø Kÿƒø?ƒø?™&+¡ !™¨ªš¤¤¡ª ‰Ñ)_,€_ôÙé&ë3"˜È”>_k%_ÛVÿÿÿýÿÁü_Áü_Ô_ŒÐÔ_Q_LÓÐ’PÌPD2h˜‚¦@ � �úlô”aˆ_ÊÁ›{"ër_4Îÿÿþÿàþ_àþ_é�

• hˆ)ëH¨*扊* *H"d:LAX }6zJ@ÂÀdPž”ØCB~D¿ÿÿÿð_ð_õDt•4TÅD__Tµ_Eu¤__&¡§ >›=$ò\8M_;‡@k’ _}¿ÿÿÿ¿ø?ƒø?ƒúʪ_¢ÊÊ� � � � � �• ŠÂ"Š:ªª’_†N‘U_ _Mž‘_º__´'_eAoD_ÿÀr_ü_Áü_ÁýeU� � �• Qee_Ea_E_UUI_C'HHª„ _¦ÏH¿Ý__“ˆ2 ¸ ªFÿà9/þ_àþ_àþ²ª†¨²²‚¢°ˆ¢Žªª¤‚!“¤$UB _Óg¤wîTÉÄ_P\ Vc?ÿð_—� � ��

ÿ_ð_ðYUCTYYAQXDQGUURA_ÉÒ_*¡ _é³ÒG÷H ´¤áŒ¨9æ$_ƒÿø_Kÿƒø?ƒø?¬ª¡ª,¬ ¨¬"(£ªª© ˆdé� � _P€_ôÙé)û¥@_‚pÆT_è_¸Åÿü_%ÿÁü_Áü_Ô_Œ_”ÒVTSL••”ÒDdtš¦ @ úlô‰ý¥ù_«`_� �

• µœ_•bÿÿÿþÿàþ_àþ_ê F• Ji+H*)¦JÊÊiH"2:MSP }6zH~Ò¤‡ò)_‚üE€>пÿÿÿð_ð_õ%UD4TĤ_t„¤Ã5%$__"¦(_ >›=%?_œ;_J‡ÊÏ_Á!_Ÿÿÿÿ¿ø?ƒø?ƒúZ2ª__‚¢‰ª� � � �• Á‰šŠÒ_†NU__ _Mž’Ÿ±I%ä,ëäÏ/ðÔŸÿÿÿßü_Áü_ÁýEai_=i)_Í-!%_Å)_L†ˆJé$ _¦ÏIG˜¬_óíòÙèÐlEwÿÿÿïþ_àþ_àþžž„¦Œ‚„‚„š†˜f¤� �

´‚!“¤4…2 _Óg¤°ëìŠ_GSÙ‰…8;a{ÿÿÿ÷ÿ_ð_ðRJOBV4BAQ11ZMQJA_!¢"*q _é³ÒR_NCÛ_¨|¬òª_qÕÿÿÿûÿƒø?ƒø?¥¥ ¡"¨' ¢"£&_©% � �ˆdéQU0€_ôÙé'³_r

• 2 vZÿZ_èÌÿÿÿýÿÁü_Áü_ÍVQQ_U’M_Ô_T_D2t˜‚¦@ úlô’ý‰ðÊT&_BN€_Ïÿÿþÿàþ_àþ_æ«(¨ˆªÉH&‰j_*FˆH"_:LAS }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++7777

SECTION DE DESCRIPTION DES DONNÉES:T00020412// = 00 = Numéro de la table principale (« Master ») = pour la

météorologie02 = Numéro d’édition de CREX

04 = Numéro d’édition de BUFR12 = Numéro de version des tables BUFR/CREX

// = Pas de table localeA007001 = 007 = Caractéristique synoptique

001 = Ligne de grainsP00012000 = 00012 = Centre d’Origine = Dakar

000 = Pas de centre secondaireU00 = 00 = Numéro de séquence (de mise à jour) du message

= 0 = premierS001 = 001 = Nombre de sous-série de données = 1Y20050823 = Date du message = année, mois, jourH1830 = Heure du message = heure, minuteD16060 = 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:D01011 Date:

2005 = Année08 = Mois23 = Jour

D01012 Heure: 17 = Heure50 = Minute

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

1500 = 15 deg. NordB06002 Longitude:

-01000 = 10 deg. OuestB19005 Direction (vers) du

déplacement:070 = 070 degrés

B19006 Vitesse de déplacement:00010 = 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 éloignés du centre:Côté Nord: B05002 Latitude:

1900 = 19 deg. NordB06002 Longitude:

-00840 = 8 deg. 40 OuestCôté Sud: B05002 Latitude:

1100 = 11 deg. NordB06002 Longitude:

-01220 = 12 deg. 20 OuestB20048 Evolution:

02 = IntensificationB11041 rafale maximum attendue:

0038 = 38 m/sB13055 intensité des précipitations attendues:

0300 = 300 mm/h

Table de Code B 20 048

Evolution du phénomène

Chiffre duCode 0 Stabilité 1 Diminution 2 Intensification 3 Inconnue 4-14 En réserve14-99 Non utilisé

EXEMPLE POUR SYNOP:Un message SYNOP d’une station en haute altitude de la Région VI - la station VAN (Turquie): SMTU10 LTAA 230600AAXX 2306417170 11665 60907 10025 21030 38444 48605 52026 69942 70262 83540 333  21035 3/105 42002 70025 83635 86359=

KSMDii LTAA 230600CREX++T000104 A000 D07222++17 170 1 2005 11 23 06 00 3845 04332 16690 16620 08444 ///// 0026 02 08500 01605 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éesRepré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???