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

Le Passé: les contraintes, il y a plusieurs décades : 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 Avant les codes météorologiques étaient vus! CONSIDÉREZ LE FLUX DE DONNÉES DE LA VEILLE MÉTÉOROLOGIQUE MONDIALE (LE PASSÉ!): Papier télétype Pointage manuel Prévisioniste Observateur qui encode sur un télétype

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 35 TEMP FM 13 SHIP 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 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 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 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é)

qui encode sur un télétype 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évisioniste Observateur qui encode sur un télétype

Décodage 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 : Décodage automatique programme de visualisation Prévisioniste Programme d’encodage Observateur

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

Les Codes Définis par des Tables ont en général cette structure 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ÕTDÈ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ÌPD2h˜‚¦@ úlô”aˆ_ÊÁ›{"ër_4Îÿÿþÿàþ_àþ_é hˆ)ëH¨*扊* *H"d:LAX }6zJ@ÂÀdPž”ØCB~D¿ÿÿÿð_ð_õDt•4TÅD__Tµ_Eu¤__&¡§ >›=$ò\8M_;‡@k’ _}¿ÿÿÿ¿ø?ƒø?ƒúʪ_¢ÊÊ ŠÂ"Š:ªª’_†N‘U_ _Mž‘_º__´'_eAoD_ÿÀ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_è_¸Åÿü_%ÿÁü_Áü_Ô_Œ_”ÒVTSL••”ҐDdtš¦ @ úlô‰ý¥ù_«`_ µœ_•bÿÿÿþÿàþ_àþ_ê F Ji+H*)¦JÊÊiH"2:MSP }6zH~Ò¤‡ò)_‚üE€>пÿÿÿð_ð_õ%UD4TĤ_t„¤Ã5%$__"¦(_ >›=%?_œ;_J‡ÊÏ_Á!_Ÿÿÿÿ¿ø?ƒø?ƒúZ2ª__‚¢‰ª Á‰šŠÒ_†NU__ _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 301013 Sequence: HOUR/MINUTE/SECOND -1e+09 MGG HOUR 18 NGG MINUTE 20 MSEC SECOND 14 301023 Sequence: LATITUDE/LONGITUDE, COARSE ACC -1e+09 MLALA LATITUDE (COARSE ACCURACY) 26.88 MLOLO LONGITUDE (COARSE ACCURACY) -77.03 MPN PRESSURE (VERT.LOCATION) 19680 MQARA AIRCRAFT ROLL ANGLE QUALITY -1e+09 MPHAI PHASE OF AIRCRAFT FLIGHT 3

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 Lcnt000 Loop Counter 2 Lcnt000 Loop Counter 3 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 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

SECTION DE DESCRIPTION DES DONNÉES: 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éorologie 02 = Numéro d’édition de CREX 04 = Numéro d’édition de BUFR 12 = Numéro de version des tables BUFR/CREX // = Pas de table locale A007001 = 007 = Caractéristique synoptique 001 = Ligne de grains P00012000 = 00012 = Centre d’Origine = Dakar 000 = Pas de centre secondaire U00 = 00 = Numéro de séquence (de mise à jour) du message = 0 = premier S001 = 001 = Nombre de sous-série de données = 1 Y20050823 = Date du message = année, mois, jour H1830 = Heure du message = heure, minute D16060 = 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

SECTION DES DONNÉES (Partie 1): 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ée 08 = Mois 23 = Jour D01012 Heure: 17 = Heure 50 = Minute Position du centre de la ligne de grains: B05002 Latitude: 1500 = 15 deg. Nord B06002 Longitude: -01000 = 10 deg. Ouest B19005 Direction (vers) du déplacement: 070 = 070 degrés B19006 Vitesse de déplacement: 00010 = 10 m/s

Evolution du phénomène 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. Nord B06002 Longitude: -00840 = 8 deg. 40 Ouest Côté Sud: 1100 = 11 deg. Nord -01220 = 12 deg. 20 Ouest B20048 Evolution: 02 = Intensification B11041 rafale maximum attendue: 0038 = 38 m/s B13055 intensité des précipitations attendues: 0300 = 300 mm/h 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é

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 52026 69942 70262 83540 333  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 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é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???