Aller au contenu
Les Forums d'Infoclimat

Ce tchat, hébergé sur une plateforme indépendante d'Infoclimat, est géré et modéré par une équipe autonome, sans lien avec l'Association.
Un compte séparé du site et du forum d'Infoclimat est nécessaire pour s'y connecter.

Ogimet - Comment s'en servir ?


mottoth
 Partager

Messages recommandés

Posté(e)
Décines (69), Aeroport St Exupery (69)

En marge de mon sujet où je présente des climats d'ici et d'ailleurs à l'aide de stats maison faites à partir des données d'Ogimet, on m'a demandé comment je faisais... Voici donc un petit tuto pour exploiter les données issues des pages d'Ogimet afin de réaliser un joli bilan mensuel, et ensuite, éventuellement, commencer un travail de climato plus approfondi.

J'utilise firefox et excel 2010, mais les manipulations - toutes simples - montrées ici se transposent facilement sur d'autres logiciels.

1. Le canevas.

D'abord il faut un joli canevas, voici donc le template que j'ai mis au point sous excel.

La formule utilisée en F3 pour retrouver une approximation du Td à l'aide de la Tm (D3) et de l'HR (E3) est:

=POWER(E3/100;1/8)*(112+0.9*D3)+0.1*D3-112

Tuto_001.png

2. Selection des données sur le site Ogimet.

Dans ce tuto on veut le bilan mensuel de Pune (stn 43063, en Inde) pour octobre 2007. Le plus délicat va être de choisir des heures de prise de tn, tx, et RR. Essayons de donner le plus de sens possible à ces valeurs:

- La tn intervient généralement au lever du jour, en moyenne vers 6h solaire. Pour l'encadrer au mieux sur une période de 24h il faut donc prendre la tn définitive d'un jour J à 18h solaire, 12h plus tard.

- On décale le tout de 12h pour la tx : on essayera de prendre la tx définitive d'un jour J à 6h solaire J+1.

- Genéralement les RR affectées à un jour J sont aussi relevées en même temps que la tx, soit 6h solaire J+1.

On va essayer de respecter ces principes en fonction des contraintes des synops compilés par Ogimet. Il nous faudra au moins ouvrir 2 pages: une pour les tn, une autre pour les tx et les RR.

Dans le menu de gauche du site Ogimet, section "TEXT INFORMATION", on clique sur "Daily summaries". Puis on paramètre notre mois d'octobre 2007 en arrêtant nos journées à 12hTU (bien penser à renverser l'ordre, "oldest first"):

Tuto_002.png

Le résultat renvoyé par cette requête se lit dans le tiers gauche de la capture d'écran ci-dessous. Dans le tiers central se trouve une requete où les jours finissent à 0hTU J+1, puis dans le tiers droit 3hTU J+1:

Tuto_003.png

En choisissant 12hTU, on obtient des résumés quotidiens qui courent jusqu'à 16h55 heure solaire: nous ne sommes qu'à 1h05 de l'heure idéale de prise de tn -> 12hTU semble tout indiqué pour notre tableau de tn. 13hTU serais idéal, mais on verra que ce n'est pas possible.

De même 0hTU J+1 correspond à 4h55 J+1 en heure solaire, pas si mal pour nos tx et nos RR.

Alors pourquoi afficher une 3e page avec des résumés quotidiens qui se terminent à 3hTU, soit 7h55 solaire ? La prochaine étape va répondre à cette question: l'examen détaillé des synops.

En cliquant sur les liens fournis dans les résumés quotidiens affichés on obtient la liste des synops décodés des dernières 48h. Par exemple si dans la page de droite (la 3hTU J+1) je clique sur le 1er novembre (11/01) voici le résultat:

Tuto_004.png

Dans la barre d'adresse on modifie le nombre de jours pour afficher le mois entier (le '31' encadré en rouge). On obtient une longue liste de synops qu'il convient d'étudier un peu.

Premièrement on constate que l'on a qu'une observation toute les 3h. On ne dispose pas de synop à 13hTU ou 1hTU... donc exit les prises de tn/tx idéales à ces heure là, on va devoir s'en tenir à 12hTU et 0hTU.

Voyons en détail le plages horaires sur lesquels on va déterminer nos differents paramètres:

Tuto_005.png

On voit que les tn nocturnes sont reportée à 3hTU le jour J. Pour le 31/10, en choisissant 12hTU comme heure de prise de tn, les scripts d'Ogimet vont considerer les 8 synop encadrés en bleu et la tn explicitée le 31/10 à 3hTU, puis choisir la valeur la plus basse: 19.5°c dans cet exemple.

Même chose pour la tx: ogimet va determiner la plus haute valeur dans le cadre rouge, en tenant compte aussi de la tx explicitée à 12hTU: 30.7°c pour le 31/10.

Mais si on considère les RR, on découvre que celle ci sont cumulées chaques jour de 3hTU à 3HTU J+1.

Pour le 31/10:

- à 6hTU le cumul provisoire de la journée est de 0mm en 3h.

- à 18hU le cumul provisoire de la journée est de 0.9mm en 15h

- à 21hTU le cumul provisoire de la journée est de 4mm en 18h (on en déduit qu'il est tombé environ 3mm les 3 dernières heures).

- à 3hTU J+1, le cumul définitif en 24h est de 5mm.

Il faut donc arrêter les résumés quotidiens à 3hTU J+1 pour obtenir les bonnes valeurs de RR. L'encadré vert montre les synops qui contiennent les infos relative aux RR de cette journée du 31/10.

Voilà pourquoi j'ai affiché 3 pages différentes. Notre bilan mensuel va être une fusion de ces 3 pages. Mais avant de faire cette opération il reste à vérifier les données.

3. Vérification des données.

Cette étape à priori fastidieuse est grandement facilité par la présentation des données, et notamment les échelles colorimétriques - une très belle idée du webmaster d'Ogimet. On passe donc en revue les 31 jours de synops, j'ai encadré en rouge les erreurs:

Tuto_006a.png

- La tn du 27 est reportée de façon erronée comme une tx. Il faudra donc corriger à la main le 16.2°c en 15.7°c.

- Même chose pour la tx du 10 qui est encodée comme une tn: on corrigera à 32.9°c au lieu de 30.5°.

- Une 2e erreur le 10: la t° de 9hTU contient une erreur de frappe, c'est probablement 31.7° et pas 21.7°c. C'est sans grande importance pour notre résumé mais ça conforte l'idée que 32.9°c est une tx crédible pour cette journée.

- Encore une erreur de frappe: la pression du 26 à 21hTu est probablement de 1011.7hPa, pas 1001.7. Encore une fois sans grande importance aujourd'hui mais à corriger si on veux utiliser les données horaires pour faire d'autre stats.

Autre problème, très courant: le synop manquant. Ici on a un beau trou de 27h dans les données, il manque tout les synops du 21/10 21hTU au 22/10 21hTU. Cela explique les valeurs manquantes dans les tableaux quotidiens pour la journée du 22.

Tuto_006b.png

4. Copier / Coller.

Maintenant il est temps de construire notre bilan mensuel. On va réaliser 3 fois la même opération puisqu'on pioche nos données dans 3 pages différentes :

- exporter la page web à l'aide de notre navigateur

- l'importer sous excel

- copier/coller nos colonnes de données.

Exporter: très simple, c'est la commande "enregistrer sous". Ne pas s'embêter à renommer, sauver tel quel:

Tuto_007.png

Importer sous excel: normalement aucun problème, excel lis très bien le html:

Tuto_008.png

Ci-dessous j'ai affiché l'opération de copier/coller des tn de la pages Ogimet importée vers notre canevas:

- étape de gauche ( A ): on n'oublie pas de corriger la tn du 27. Ca doit être 15.7°c, pas 16.2°c.

- étape centrale ( B ): copier la colonne des tn

- étape de droite ( C ): coller dans notre canevas.

Tuto_009.png

On ferme la page importée ('synop report summary'), on recommence avec la page des tx (0hTU, on corrige ce faisant la tx du 10 à 32.9°c), on peut tout copier y compris les picto temps présent - faut pas hésiter excel gère tout ça très bien (à gauche çi-dessous, etape D).

On recommence avec la dernière page (3hTU) pour completer notre bilan avec les RR... à ce stade on arrive à la capture d'écran de droite ci-dessous (E):

Tuto_010.png

Quelques opérations de nettoyage et de mise en forme plus tard (quadrillage, police - calibri 10, décimale fixe, etc...) on arrive à ça:

Tuto_011.png

L'opération bonus: on imprime ça dans un fichier pdf, on fait une belle capture d'écran que l'on sauve en format png, et voici le résultat final:

Tuto_012.png

Voilà... techniquement c'est rien de compliqué. Le plus dur est de ne pas se mélanger les pinceaux en formulant les requêtes sur le site d'Ogimet, et notamment de bien choisir les heures de relevé, de bien savoir ce qu'on fait.

Je reviendrais ces jours à venir sur le vaste problème du choix de l'heure, sur les problèmes de qualité des messages synop et les erreurs d'encodage les plus courantes et les plus facilement détectables, et aussi sur les différentes manière d'encoder les RR - le paramètre le plus délicat à maitriser. En espérant que ça donnera envie à certain d'entre vous de faire votre propre climato et de partager ça sur infoclimat.

  • J'aime 2
Lien à poster
Partager sur d’autres sites

Posté(e)
Décines (69), Aeroport St Exupery (69)

J'ai remplacé quelques captures d'écrans en corrigeant les oublis d'hier soir et en essayant d'éclaircir un peu plus le truc.

Lien à poster
Partager sur d’autres sites

Posté(e)
Décines (69), Aeroport St Exupery (69)

Quelques erreurs communes dans les synops:

A. Une valeur de vent délirante. Ca fausse la moyenne du jour en question.

B. Des tx manquantes... en fait ce sont les synops de 12hTU, qui contiennent les tx en question, qui sont manquants.

C. 3 erreurs manifestes d'encodage du td... à chaque fois on a une dizaine d'erreur.

Tuto_020.png

Et un grand classique: le synop doublon, ici 2 cas rapprochés dans le temps. Facile a détecter en important la page web sous excel et en filtrant la colonne des heures - il faut supprimer tout ce qui n'est pas multiple de 3, ici 14h et 16h.

Tuto_021.png

J'enrichirai au fur et à mesure ce topic pour vous montrer tout le bestiaire des bugs et erreurs possibles.

  • J'aime 1
Lien à poster
Partager sur d’autres sites

Posté(e)
Vincennes (94) / Penta di Casinca (2B) / Quiberon (56)

Merci pour ton remarquable effort de pédagogie pour exploiter au mieux Ogimet, et bravo au passage pour tout ce que tu en extrais ! flowers.gif

Lien à poster
Partager sur d’autres sites

Je reviendrais ces jours à venir sur le vaste problème du choix de l'heure, sur les problèmes de qualité des messages synop et les erreurs d'encodage les plus courantes et les plus facilement détectables, et aussi sur les différentes manière d'encoder les RR - le paramètre le plus délicat à maitriser. En espérant que ça donnera envie à certain d'entre vous de faire votre propre climato et de partager ça sur infoclimat.

Ça, ça m'intéresse notamment pour l'international. En Europe ça passe, mais à l'étranger c'est pas forcément évident au niveau des choix pour les RR notamment.
Lien à poster
Partager sur d’autres sites

Posté(e)
Brassac les Mines (sud 63) 405m sur les bords de l'Allier

Merci pour ces explications.

Impressionant travail !

Lien à poster
Partager sur d’autres sites

Posté(e)
Décines (69), Aeroport St Exupery (69)

J’approfondis un peu le système de l'Inde qui est un cas particulier pour les RR.

On a vu qu'il faut regarder le synop de 3hTU pour avoir la RR définitive de la veille. Il va falloir donc faire très attention aux éventuels synops manquants ou mal encodés à cette heure-çi.

L'exemple ci-dessous montre le déroulement de quelques jours de mousson à Pune avec des pluies quasi quotidiennes, on voit bien comment les RR sont "remises à zéro" chaque jour entre 3h et 6hTU, et on peut facilement verifier que les bonnes valeurs sont attribuées à chaque jour dans le résumé de droite.

La journée du 8 pose problème: il manque quelques synops, notamment celui du lendemain 3hTU, qui contient la valeur finale de RR. Dans le tableau de droite Ogimet reporte 0mm, mais en fait rien ne nous garantie qu'il n'a pas plu entre 18hTU (heure du dernier synop valide) et 3hTU... il va falloir effacer ce zéro et laisser une donnée manquante. Mieux vaut une donnée manquante qu'un zéro erroné, car si l'erreur se répète trop souvent ce zéro risque de peser dans les stats - en l’occurrence de tirer la moyenne vers le bas.

On remarque aussi quelques synops mal encodés (et/ou mal décodés) avec des valeurs manquantes ou erronée de RR (le 5 à 18hTU, le 4 à 21hTU), cependant sans le moindre impact sur la valeur finale de RR prise à 3hTU.

Si l'on compte faire des stats de pression il faudra aussi corriger la valeur du 5 à 9hTU qui saute au yeux: c'est 999.1hPa, pas 1099.1.

Tuto30.png

J'en termine avec l'Inde pour cette fois çi montrer un autre problème qui survient avec certaines stations, lorsque la tx est reportée plusieurs fois en 24h. C'est le cas pour Madras ou pour Delhi... ici nous nous intéressons à Madras.

- Pour la tn c'est pareil que les cas précédents: 12hTU semble l'heure la plus indiquée puisque en heure solaire moyenne ça correspond à 17h20, très proche du 18h idéal. Dans l'exemple encadré du 6/6/2013 on voit que la tn retenue n'est pas la tn nocturne (27.5°c) mais une t° de 26.4°c relevée sous une averse tropicale en fin d'après midi à 12hTU.

- Pour les RR on prend 3hTU J+1, je passe vite car on a déjà vu cela... on voit que les 91mm du 2/06/2013 sont tombés en moins de 3h sous un bel orage.

- Pour les tx ça se corse, puisque la tx diurne du synop de 12hTU est répétée le lendemain à 3hTU.

Si l'on choisi 0hTU J+1 comme heure de prise de tn, regardons la cas encadré en gris pour voir ce qui ce passe: au tout début de la plage horaire (qui court donc de 3hTU J à 0hTU J+1) on trouve la tx de J-1...si celle ci est plus élevée que celle du jour J c'est elle qui va être retenue. Par exemple le 01/06 la tx diurne est de 34.8°c, mais celle de la veille, répétée dans le synop du 01/06 à 3hTU, fut 36.8°c -> le script d'ogimet retient le 36.8°c plutôt que le 34.8°c et l'affecte à la journée du 01/06 (résumé de droite encadré en gris).

En fixant l'heure de prise de tx à 0hTU alors que les tx de la veille sont répétés à 3hTU on aura la tx de la veille qui sera systématiquement affectée au jour courant en cas de refroidissement. Si l'on compare attentivement le tableau 'gris' de droite aux synops detaillés à gauche on remarque que seuls le 37.5° du 2/06 et le 38.4°c du 6/06 sont les bonnes tx, les 5 autres sont sur-evaluées ! 5 erreurs sur 7 jours, c'est énorme !

On doit donc faire se résoudre à choisir une heure moins idéale pour les tx mais qui nous fera éviter ce biais trop pénalisant: 3hTU J+1, soit 8h20 solaires (le jour est levé depuis bien longtemps). Le dernier tableau, en bas à droite (le rouge), montre des tx justes.

Pour synthétiser cet enseignement important: lorsque la tn (ou la tx) est reportée plusieurs fois en 24h, on est contraint de faire coïncider nos heure de prise de tn (ou de tx) avec ces heures de report. Je reviendrai dans d'autres exemples sur ce problème.

Tuto30b.png

Passons en revue un autre système, celui utilisé notamment pas la Chine où les RR sont reportées de 2 façons:

- les RR des 6 dernières heures sont reportées toutes les 6h.

- une fois par jour un cumul RR24h est reporté.

Il va donc être facile de vérifer la cohérence des RR reportées en comparant le cumul 24h à la somme des 4 cumuls de 6h qui couvrent la même période. D'ailleurs les scripts Ogimet vont ça automatiquement et gênèrent une donnée manquante dans les résumés quotidiens si il y a une incohérence.

J'ai pris une séquence du temps à Shanghai comme exemple:

- On constate que les RR24h sont reportée à 0hTU, soit 8h05 temps solaire moyen -> on va devoir arrêter nos résumés quotidiens à 0hTU J+1 pour extraires les bonnes valeurs de RR.

- On peut vérifier sur la journée particulièrement pluvieuse du 18 la concordance entre les RR6h (arrondis à l'unité) et RR24h (arrondi au dixieme): 15+29+26+2 = 72mm, conforme avec le cumul 24H de 72.4mm.

- Il manque le synop du 14 0hTU, donc pas de RR fiable qui puisse être attribuée à la journée du 13, même si on pourrait affirmer sans prendre trop de risques que cette journée n'a reçu que des traces.

Sinon on voit que j'ai choisi 9hTU (17h05 solaire) pour arrêter mes valeurs de tn et 21hTU (5h05 J+1 solaire) pour celle de Tx, valeurs les plus proches de 18h et 6h J+1 solaires. J'ai pris soin d'encadrer les synops concernés par la journée du 18:

- la tn est recherchée du 17 12hTU au 18 9hTU. A 6hTu on avait un tn nocturne de 16.6°c reportée, mais à 9hTU la t° s'était abaissée à 15.7°c dans le courant de l'après-midi sous la pluie -> On affecte 15.7°c de tn définitive pour cette journée.

- pas de lézard pour la tx qui malgré le réchauffement en fin de nuit (ca remonte déjà à 21hTU) sera le 17.5°c reportée en Tx diurne à 18hTU.

Tuto31.png

A suivre...

  • J'aime 1
Lien à poster
Partager sur d’autres sites

Posté(e)
Décines (69), Aeroport St Exupery (69)

Tout d'abord j'ai enrichi le post ci-dessus avec l'exemple de Madras qui introduit une nouvelle problématique sur les heures de relevé de certaines tx (ou tn).

Ensuite je continue dans les spécificités locales que l'on rencontre ça et là avec l'exemple de la Russie, qui utilise encore une autre système de report de RR.

J'ai pris l'exemple de Moscou, voici ce que l'on peut en dire:

- les tn sont arrêtées à 15hTU, soit 17h30 temps solaire, pas mal... On voit que la tn nocturne est explicitée à 6hTU, si elle baisse ensuite en cours de journée on n'aura donc qu'une approximation en fonction des synops tri-horaires disponibles.

- idem pour les tx: tx diurne explicitée à 18hTU, tx définitive arrêtée à 3hTU (5h30 temps solaire).

- pour les RR: 2 reports par jour, sur les 12 dernières heures, à 6hTU et 18hTU, arrondis à l'unité. On va donc devoir choisir soit 18hTU soit 6h... comme l'usage veut de prendre une heure de relevé des RR la plus proche possible de celle de la tx on va donc choisir 6hTU J+1.

Ogimet va simplement additionner les 2 lames d'eau de 12h pour avoir le cumul des 24 dernières heures.

Dans l'exemple du 6/06/2012, on a eu 12mm tombés entre 6hTU et 18hTU et 3mm entre 18hTU et 3hTU J+1, soit un total de 15mm.

C'est très simple, mais il y a 2 inconvénients: 1. pas possible de recouper les relevés entre eux pour écarter d'éventuelles erreurs d'encodage. 2. Un seul relevé manquant et c'est toute la journée que passe à la trappe.

Tuto32.png

A suivre...

  • J'aime 1
Lien à poster
Partager sur d’autres sites

Posté(e)
Nice (06)-Corniche Fleurie / parfois Saint-Félix de Lodez (34)

Tu fais un travail impressionnant, on sent la passion là dedans et c'est extra default_flowers.gif C'est très sympa ce topic backstage default_smile.png/emoticons/smile@2x.png 2x" width="20" height="20">

Un grand merci, et continue d'alimenter le topic climato que je dévore à chaque fois que je vois un de tes posts default_flowers.gif

Lien à poster
Partager sur d’autres sites

Posté(e)
Décines (69), Aeroport St Exupery (69)

Un nouvel exemple, pris en Argentine. Regardons bien les synops détaillés à gauche:

- pour les RR on retrouve le même système qu'en Chine: 4 relevés quotidiens des 6 dernières heures, complétés d'un cumul RR24h à 12hTU. C'est l'idéal puisqu'on peut facilement vérifier la cohérence des relevés - ce que les scripts d'Ogimet font d'ailleurs. On regardera donc la lame d'eau d'un jour J à 12hTU J+1.

- pour les tn: la tn nocturne est reportée à 12hTU (8h05 solaire), puis la tn diurne est reportée à 0hTU J+1 (20h05 solaire). La présence d'une tn diurne évite de recourir à des approximations pour estimer la vraie tn en cas de refroidissement important en journée, comme on a vu plus haut à Shanghai. Par contre elle nous contraint à choisir 0hTU J+1 comme prise de tn définitive, alors que l'on aurait préféré 21hTU, plus proche des 18h solaires.

Si l'on utilise 21hTU, on voit dans le 1er tableau de droite que l'on obtient 5 valeurs erronées sur 7, car on regarde en fait sur une période largement supérieure à 24h. Dans l'exemple encadré en gris, qui concerne la journée du 16/07 (0hTU à 21hTU), Ogimet prend comme tn celle qui est explicitée à 0hTU (4.7°c), mais en fait ce 4.7°c est en fait la tn diurne survenue la veille, le 15 à 12hTU, soit 33h avant le 16 à 21hTU.

Donc on est obligé de s'en tenir à 0hTU J+1, même si c'est moins idéal.

- pour les tx c'est exactement le même raisonnement... on serai tenté de l'arrêter à 9hTU J+1 (5h05 solaires J+1), mais ce faisant on va éventuellement prendre en compte la tx nocturne de la veille, qui remonte à plus de 24h, comme dans l'exemple du 18/07 encadré en mauve.

Donc on doit s'en tenir à 12hTU J+1.

Tuto40.png

C'est aussi le système utilisé en France, où les tx et tn sont reportées 2 fois par jour: nocturnes à 6hTU, diurnes à 18hTU... d'où le choix de prise de la tn définitive à 18hTU de la tx définitive à 6hTU J+1... on retrouve ce que vous saviez probablement déjà.

  • J'aime 1
Lien à poster
Partager sur d’autres sites

Posté(e)
Décines (69), Aeroport St Exupery (69)

Ici je vous montre vite fait 2 bugs que l'on trouve de temps en temps dans les synops.

NB: à partir de cet instant je vais utiliser une écriture simplifiée pour les heures TU, inspirée de ce que l'on fait en aviation: 9hTU s'écrira 09Z, le Z signifiant 'zulu time' - un synonyme de temps universel (UTC en anglais ou TU en français).

A. La tx mal encodée: une erreur de dizaine dans le synop de 09Z fait que la tx est reportée à 29.4°c au lieu de 19.4°c. On voit bien sur les t° des synops précédents que ce 29.4°c est farfelu, et l'erreur a été corrigée dans le synop de 12Z où 19.4°c est bien mentionné. Mais le mal est fait, et les scripts d'Ogimet vont retenir 29.4°c au lieu de 19.4°c (tableau de droite). il faudra donc corriger manuellement la tx de ce jour avant de l’intégrer dans une base de donnée ou un bilan mensuel.

B. Les synops en doublons - suite et fin: on avait déjà vu un exemple plus haut, mais celui-là est plus sournois:

2 synops de la journée du 1/11/2008 ont été dupliqués et ont remplacé 2 synops de la journée du 6/11/2008... vous voyez ? Le synop du 01/11 09Z a été recopié en lieu et place du 06/11 09Z, et celui du 01/11 12Z se retrouve aussi le 06/11 à 06Z.

Il y a 2 façons de détecter rapidement ce problème:

- en scannant visuellement les tx on voit assez facilement qu'il y a un pb le 06/11 puisque 2 tx contradictoires sont reportées, dont une à une heure inhabituelle (06Z)

- en scannant visuellement - grâce au échelles de couleurs - les relevés de pression au niveau de la mer on voit 2 obs qui ne s'intègrent pas bien avec les autres, les 2 relevés à 1000.8 et 1001.6hPa au milieu de 2 journées à 1008 - 1010hPa.

Une fois la suspicion installée il est assez facile de retrouver ces 2 doublons un peu plus bas à leur place originelle, et de les passer à la trappe.

Il faudra donc supprimer les synops du 06/11 06Z et 09Z si l'on compte importer la table des synops dans une base de donnée, et corriger manuellement la tx du 06/11 dans le résumé mensuel (à droite): 1.0°c au lieu de 8.4°c.

Tuto45.png

Le truc a retenir c'est que le travail de vérification des synops peut être très rapide si l'on fait bien attention aux échelles de couleur, où une valeur suspecte "flashe" par rapport aux synops voisins. Quand je passe en revue un mois complet de synops je ne regarde pas les valeurs, uniquement les couleurs ! Une fois qu'une valeur suspecte est repérée il ne reste qu'à trancher: erreur d'encodage ou synop en doublon ?

  • J'aime 1
Lien à poster
Partager sur d’autres sites

Posté(e)
Décines (69), Aeroport St Exupery (69)

Aujourd'hui on va voir pourquoi on ne peut pas bosser les pays d'Amérique du Nord sur Ogimet.

Prenons New York / La Guardia comme exemple. J'ai choisi un mois d'hiver où les variations de t° sont plus importantes qu'en été.

Observons les synops:

- première chose, qui m'énerve: les américains n'utilisent que les °F, arrondis à l'unité près. Ce qui, une fois convertis en °C, donne une précision à 0.5°c ou 0.6°c près... on a des valeurs apparemment arrondies au dixième près (-6.7°c, -7.2°c, -7.8°c...) mais dont en fait la précision est de seulement 0.5°c à 0.6°c. Pourquoi continuent-ils à travailler avec cette faible précision alors que tout le reste du monde travaille au dixième de centigrade ???

- on reconnait pour les RR le système déjà vu en Chine ou en Argentine, et à vrai dire c'est le plus répandu: 4 relevés quotidiens de RR6h complétés par un cumul RR24h, à 12Z (ou plus exactement 11:51Z, vers 7h solaires: parfait pour coupler l'heure de prise des RR avec celle des Tx).

- pour les tn: d’après le temps solaire, l'idéal est de choisir 00Z J+1 comme heure de prise des tn, soit 19h04 solaires.

Ca marche pas mal pour la journée du 23/1, où la tn est prise peu avant la limite (-7.2°c à 23h51Z, -7.8°c de tn diurne reportée à la même heure). Ca marche aussi pour le 24/1, où le -11.1°c de 12Z reste bien la tn définitive jusqu'à 00Z J+1.

Par contre comment se retrouve t-on avec la même tn de -11.1°c le 25/1 alors que la tn nocturne reportée à 12Z est de -9.4°c et que l'on n'est pas allé plus bas pendant la journée ? Parceque le synop de 06Z contient une tn qui correspond à celle de la veille (encadrée en rouge) ! Et oui, c'est comme ça aux USA: ils "remettent à zéro" la tn dans leur synop après 06Z, ou plutôt ils relèvent la tn définitive à 06Z J+1, soit 1h04 J+1 en temps solaire.

Donc si on veut faire les choses bien, prendre la tn en fin d'aprem/début de soirée soit 00Z, et bien on va se retrouver avec des tn systématiquement sous-évaluées à chaque situation de radoucissement... si on regarde bien les synops affichés à gauche on voit le même problème survenir pour les journées du 26 et du 27, hachurées sur le tableau des tn à droite: la tn affectée au 26 devrait être -7.8°c, pas -10.0°c. et pour le 27 -6.1°c au lieu de -7.8°c...

Alors pourquoi ne pas faire comme eux finalement et arrêter nos tn à 06Z J+1, finalement c'est peut-être pas si grave ? Effectivement ce serait un moindre mal car en cas de réchauffement nos tn resteraient juste. Par contre certains refroidissements pèseraient alors trop lourd, comme la journée du 22 qui se verrai affectée une tn de -10.0° survenue au milieu de la nuit suivante, au lieu du -7.8°c plus réaliste du début de soirée. Et dans un climat aussi contrasté ces situations surviennent assez souvent pour biaiser un peu la moyenne vers le bas.

Tuto46.png

- quid des tx ? Pfff c'est encore plus confus... On observant les synops il semble que la tx soit "remise à zéro" chaque jour à 12Z... excellent, ça correspond à 7h04 solaire, c'est exactement ce qu'on recherche !

Mais le problème est que le synop de 18Z contient une tx qui est recherchée dans les 12 dernières heures, jusqu'à 06Z... donc en dehors de notre fourchette qui est de 12Z à 12Z J+1.

Ici ça pose problème pour la tx du 22: le synop du 23 00Z reporte une tx diurne de -5.0°c, valeur max des 12 dernières heures. Vu le refroidissement de la nuit suivante ce -5.0°c est la tx à affecter à ce jour. Mais le synop de 18Z reporte une tx de -2.2°c, atteinte vers 06Z, avant le début de notre fourchette... ce -2.2° est repris à 06Z+1 et même corrigé à -1.7°c sur le denier synop de notre fourchette, à 12Z+1.

Donc en prenant 12Z+1 comme heure de prise de tx on se retrouve donc une tx prise dans un intervalle de 30h (06Z à 12Z+1)... mais depuis quand recherche-t-on un extrême quotidien sur 30h au lieu de 24h ???

Si on prend 18Z+1, ce qui aurait du sens si on s'était résolu à prendre nos tn à 06Z+1, on se retrouverait avec une fourchette de 36h, c'est encore pire... Bref on est piégé.

Moralité: même en étant souple et en faisant certains "sacrifices" sur l'heure de prise de tn, on ne peut rien faire pour restreindre la prise de tx sur un vrai intervalle de 24h. Les synops américains sont inexploitables avec les scripts Ogimet, il faudrait passer des heures fastidieuses à corriger à la main certaines tx. Où alors développer un algorithme spécifique pour ce cas d'espèce.

On rencontre les mêmes problèmes avec le Canada et le Mexique. Voilà pourquoi vous ne verrez jamais ces pays abordés dans mon topic consacré aux climats de monde... je sais c'est dommage, car on se prive de plein de choses.

  • J'aime 1
Lien à poster
Partager sur d’autres sites

Pourquoi continuent-ils à travailler avec cette faible précision alors que tout le reste du monde travaille au dixième de centigrade ???

Pourquoi ? Parce que ce sont les Américains, et qu'ils ne font rien comme les autres...

Ce sont les seuls, dans le monde, à utiliser le système impérial. Avec le Myanmar et le Libéria. Même les Anglais l'ont abandonné depuis un bail...

Au Québec, on utilise les deux mélangés, c'est encore pire !

Bref...

Lien à poster
Partager sur d’autres sites

Pourquoi ? Parce que ce sont les Américains, et qu'ils ne font rien comme les autres...

Ce sont les seuls, dans le monde, à utiliser le système impérial. Avec le Myanmar et le Libéria. Même les Anglais l'ont abandonné depuis un bail...

Au Québec, on utilise les deux mélangés, c'est encore pire !

Bref...

Franchement je suis déçu de se système, car sa veut dire que ont aura jamais les valeurs exacte et aussi les moyennes risque de rien à voir avec les vrais moyennes en utilisant le système normale sad.png !
Lien à poster
Partager sur d’autres sites

Posté(e)
Décines (69), Aeroport St Exupery (69)

Franchement je suis déçu de se système, car sa veut dire que ont aura jamais les valeurs exacte et aussi les moyennes risque de rien à voir avec les vrais moyennes en utilisant le système normale sad.png !

Je trouve ça "énervant" en effet, mais dans le fond des choses c'est pas si grave:

- la précision des mesures à 0.1°c n'est souvent qu'une illusion... à ce niveau de précision on est trop dépendant du matériel. Il y a quelques temps j'ai lu un comparatifs sur les stations météo amateurs (les VP2 et cie...), la plupart des fabricants indiquent eux même une précision de leurs capteurs de l'ordre de 0.5°c en général, à ne pas confondre avec la résolution qui est de 0.1°c. Je recommande la lecture attentive de ce post de ChristianP dans un autre topic, où il parle du vaste problème des mesures de t°: /topic/81915-suivi-thermique-2013/page__view__findpost__p__2186864'>C'est ici

- les pertes de précision éventuelles durant l'arrondi à l'unité de °F sont gommées par l'opération de la moyenne, du moment que l'on arrondi bien vers le plus proche entier, et non systématiquement vers l'entier inférieur. C-à-d 25.7°F doit être arrondi à 26°F, pas 25°F. Au sein d'une telle série de mesure les arrondis vers le haut compensent très vite ceux vers le bas, et la moyenne n'est pas affectée.

Lien à poster
Partager sur d’autres sites

  • 3 years later...
Posté(e)
Saint-Etienne (42), quartier de Terrenoire (alt. 500m)

Peux-tu nous expliquer comment tu fais pour nous concocter les fiches des stations des Etats-Unis?

Modifié par Peki2
Lien à poster
Partager sur d’autres sites

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !

Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.

Connectez-vous maintenant
 Partager

  • En ligne récemment   0 membre est en ligne

    • Aucun utilisateur enregistré regarde cette page.
×
×
  • Créer...