Imprécisions sur les données aux normes OMM

[lobarbot]

Bonjour,

Suite à une application que j'ai mise en ligne (/topic/86752-utilitaires-pour-obtenir-des-donnees-aux-normes-omm/'>http://forums.infoclimat.fr/topic/86752-utilitaires-pour-obtenir-des-donnees-aux-normes-omm/), j'ai voulu vérifier si mes programmes fonctionnaient correctement.

Je n'ai évidemment pas tout testé, mais j'ai remarqué des imprécisions, voire des erreurs, au niveau des Cumuls de pluies et notamment sur la fin du mois.

Par exemple sur ma station , il a été relevé chez moi et enregistré sur le site d'IC, pour 2015 :

-1,6 mm le 31 aout de 18h à 19h,

-1,0 mm le 31 aout de 19h à 20h,

-0,2 mm le 31 aout de 20h à 21h

,

-2,2 mm le 1er septembre de 6h à 7h,

-0,2 mm le 1er septembre de 7h à 8h.

Tout ceci est en heure locale et tout ceci est correct et cohérent.

Ce qui donne avec les normes OMM un cumul de 5,2 mm = 2,8 mm

+ 2,4 mm

pour le 31 aout.

Par contre sur le site d'IC dans les tableaux de climatologie

- du mois d'aout 2015, il apparaît : 2,8 mm

de pluie le 31 aout

,

- du mois de septembre, il apparaît : 0,0 mm

de pluie le 1er septembre

.

Il y a apparemment donc une double erreur : le cumul du 31aout n'est pas aux normes et les 2,4 mm du 1er septembre avant 8 h (local) se sont évaporés.

[muchistic]

Bonjour

si ce genre d’erreur se répète cela risque de fausser lourdement les cumuls réel

[lobarbot]

Bonjour,

Quand il fera moins beau, je vais me mettre un jour à vérifier manuellement les résultats. Pour essayer de voir si l'erreur est aléatoire ou répétitive et à ce moment là essayer de mettre précisément le doigt où ça coince pour pouvoir proposer une solution.

Je vous tiendrai au courant.

[lobarbot]

Bonjour,

Je viens de faire un travail un peu fastidieux mais nécessaire. J'ai vérifié un par un tous les enregistrements des données de pluviométrie du dernier jour du mois et celles du premier jour du mois suivant sur la climatologie d'Infoclimat de ma station pour l'année 2015.

A part quelques rares mesures manquantes (*), elles sont conformes aux miennes.

J'ai tout recalculé à la main. Tous les résultats obtenus sont identiques à ceux fournis par mon utilitaire OMM_un_mois

(http://www.meteo-gujan.org/Visiteurs)

Comme je l'avais supposé sur le premier message, il y a double erreur sur les résultats des climatologies mensuelles du site Infoclimat.

Cette double erreur doit bien être une erreur de programmation, car elle se répète à l'identique tous les mois.

Les pluviométries du dernier jour du mois sont de fait calculées de 6h UTC à 24h UTC, ce qui n'est pas conforme à la norme OMM.

Les pluviométries du premier jour du mois sont de fait calculées à partir de 6h UTC. Ce qui entraine la perte des données de pluie entre 0h et 6h UTC tous les premiers jours du mois.

Bon, si vous avez quelques heures, prenez une feuille, un crayon, vous pouvez vérifier.

Bon courage.

(*) Ces données manquantes n'influencent pas les résultats.

En passant, je n'arrive pas à remplir les données manquantes à la main. J'ai un message Erreur si je veux modifier.

Pour être constructif, ne serait-il pas plus judicieux que tous les membres du réseau StatIC envoient chaque mois leur fichier aaaa-mm.wlk ?

[Cyrilleb]

J'ai remarqué moi aussi qu'il y avait parfois des erreurs (et pas seulement sur la pluviométrie). De mon côté, j'utilise un fichier excel qui recalcule les valeurs au format OMM.

Tu dois être le propriétaire de la station de Gujan Mestras...

Si tu vas sur cette page http://www.infoclimat.fr/climatologie-mensuelle/000R8/septembre/2015/gujan-mestras.html , tu dois pouvoir corriger et valider tes relevés en cliquant sur le crayon à droite. Tu peux faire la même chose pour tous les autres mois. Attention cependant, les données de pluie peuvent être différentes entre la page accessible à tous, et celle où l'on modifie les données, sans doute un autre bug...

Pour l'envoi du fichier wlk, je pense que ce serait une bonne chose, pour tout corriger en une seule fois!

Si tu as des lignes manquantes dans les tableaux journaliers, tu ne peux pas les remplir à la main (ce que je trouve dommage d'ailleurs). Il faut importer ces lignes avec le fichier downld08.txt, mais cette fonction a été désactivée depuis un an maintenant, on attend qu'elle soit remise en service!

[lobarbot]

Bonjour,

Oui je sais comment modifier les valeurs avec le crayon ;-)

, mais tu confirmes ma remarque quand il manque une ligne complète il n'est pas possible de la remplir, quand on clique sur le crayon on a une page d'erreur qui s'affiche. C'est effectivement dommage, car on peut avoir une coupure Internet supérieure à une heure.

As-tu essayé OMM_un_mois

? Est-ce conforme à ta feuille Excel ?

Quant aux autres erreurs, toujours sur la pluviométrie, j'en ai notées quelques unes en faisant le travail précédent. Ce ne sont pas apparemment des erreurs type OMM, mais des valeurs inférieures ou supérieures aux valeurs : cela semble aléatoire.Je vais essayer de faire une étude plus précise, mais cela risque d'être long.

Pour l'envoi mensuel, on pourrait même fournir une "moulinette" à chaque membre du réseau, qui serait déclenchée par une tâche programmée tous les 2 du mois et enverrait un fichier simplifié et en clair avec les seules données utilisées par IC.

[lobarbot]

Re,

Voilà les cumuls mensuels de pluie de ma station de janvier à aout 2015 :

1ère ligne : selon mes calculs suivant la norme OMM en bleu

2ième ligne : selon les exports NOAA faits dans Weartherlink (les cumuls sont faits par jours en heures légales) en violet

3ième ligne : les statistiques de ma station dans le tableau climatologie 2015 d'InfoClimat théoriquement aux normes OMM en vert

114.2+98.0+55.2+20.8+24.2+26.2+43.2+116.6 = 498.4

​

108.9​+95.8+62.6+18.2+26.4+26.0+43.8+114.1=495.8 +2.6

(1er septembre avant 8h) = 498.4

(NB : il n'y a pas de pluie le 1er janvier avant 7h)

103.6+​90.2+53.2+17.8+21.8+26.2+41.6+106.8=462.0

Les totaux des deux premières lignes sont identiques, par contre le total d'IC marque un déficit de 7,3%

sur seulement les ​2/3 de l'année.

Je rentrerai dans d'autres détails plus tard, mais une bonne partie de l'erreur provient des cumuls des premiers et derniers jours du mois.

A vos calculatrices !

[lobarbot]

Re,

Confirmation de l'avant dernière phrase du message précédent, les erreurs sur les autres jours que le premier et le dernier jour du mois

sont globalement insignifiantes.

Néanmoins sur la même période de janvier à aout 2015, j'ai relevé 25 erreurs de cumuls quotidiens sur un total de 241 jours. Mais ces erreurs sont parfois positives, parfois négatives.

En moyenne et en valeur absolue on a une erreur de 0.5 mm sur ces 25 jours et au total l'ensemble de ces erreurs ne fait qu'un total de -1,6 mm sur un total de près de 500 mm . C'est donc tout à fait négligeable, bien inférieur à la précision de nos instruments.

Il reste donc à régler les gros problème des cumuls des premiers et derniers jours

du mois.

En passant j'ai constaté qu'il y avait également des erreurs sur les TN. Sur le mois de janvier, il y a 3 erreurs nettes. Apparemment le programme n'a pas été chercher la minimale la veille à partir de 19h (heure locale d'hiver)

Je vais regarder cela en détails.

Suite au prochain numéro.

[lobarbot]

Bonjour,

J'ai passé en revue toutes les TN et TX de janvier à aout 2015.

Je rappelle comme l'indiquent les infobulles des Tempé.min et les Tempé.max des climatologies mensuelles des stations :

- La TN est calculée sur la méthode officielle OMM, c'est-à-dire de 18h UTC (19h en hiver, 20h en été) la veille à 18h UTC le jour-même.

- La TX est calculée sur la méthode officielle OMM, c'est-à-dire de 6h UTC (7h en hiver et 8 h en été) le jour-même à 6h UTC le lendemain.

On obtient, a priori, des résultats différents de ceux calculés sur les journées aux heures légales.

Pour le climat océanique de ma station :

- pour les TN, il y a 8 différences, essentiellement sur les 3 premiers mois (7 sur 8),

- pour les TX, il n'y a eu qu'une seule différence.

Sur les résultats affichés sur le site d'IC dans les climatologies mensuelles, il y a erreur systématique sur ces 9 valeurs : les TN et les TX ont été calculées de fait sur les journées légales.

Ce ne sont donc pas des erreurs aléatoires.

J'ai noté d'autres types d'erreurs (7 autres) , s'il manque une ligne de relevés dans une journée, cela affecte la valeur de TX et pas celle de TN et la valeur de TX affichée est une aberrance (au sens statistique du terme), la valeur ne faisant même pas partie des valeurs enregistrées dans la journée (avec des écarts allant jusqu'à 9°).

Je précise à nouveau que toutes ces remarques ont été notées à partir des relevés se trouvant dans la base de données d'IC. Il s'agit donc d'erreur de programmation et donc corrigeables.

En passant il manque deux journées entières de relevés (8 et 9 février 2015), ce qui embêtant car il est impossible de les remplir à la main (voir 3 messages plus haut).

J'espère avoir fait un travail qui puisse servir à améliorer notre site.

J'attends des retours d'autres personnes avant de faire un résumé de tout cela, pour donner une étude pratique aux administrateurs du site.

Si vous avez besoin d'un coup de main ou d'explications, n'hésitez pas à le dire.

[Sebaas]

Merci lobarbot pour ce gros travail de documentation des bugs. Petite précision: tu travailles sur quel genre de StatIC? Parce qu'entre celles qui sont en weathelink USB et qui transfère un fichier via ftp, celles qui sont en weatherlinkIP, les vws et vws2, tout un tas de cas reste possible.

La plus grosse difficulté venant du fait que weatherlink ne connait que les tn et tx sur le créneau minuit à minuit - et dépend donc également si la station est paramétrée en UTC (ce que nous recommandons, toutes les stations financées et installées par l'asso le sont) ou en heure local ou... ne soit pas à l'heure du tout.

[lobarbot]

Mes données sont envoyées dans un fichier statIC.txt généré par le fichier statIC.htx fourni par IC et envoyé par ftp dans un répertoire de mon site.

Je sais bien que WL ne connaît pas les "vrais" TN et TX, c'est pour cela que j'ai écrit l'appli OMM_un_mois ( http://www.meteo-gujan.org/Visiteurs

). Pour les erreurs sur les TN, en particulier, elles se situent toutes avant 0h UTC, ce n'est donc pas la différence entre UTC et heures légales qui est la source d'erreur. L'algorithme de calcul doit comporter un petit bug ou il n'y a pas d'algorithme qui les calcule.

D'autre part, cela ne répond pas au problème des cumuls de pluie perdus dans la nuit du changement de mois.

Je réitère ma proposition : pour la climatologie, ne pourrait-on pas remplir la base de données d'IC à partir des fichiers aaaa-mm.wlk envoyés tous les 2 du mois par les membres du réseau ? A l'arrivée on passe à la "moulinette" (*) avant d'injecter dans la base SQL ou ce sont les membres du réseau qui passent la "moulinette" avant d'envoyer les données digérées. Les données récupérées actuellement à la volée sont sujettes en plus aux aléas de plantage de la station, de l'ordi, des connexions internet, du serveur ftp etc...Mêmes si les données du jour et du mois en cours peuvent être soumises à ces déboires que l'on ne pourra jamais totalement éliminés, les données climatologiques devraient être nickel. On peut prendre le temps de les affiner.

Je suis bien placé pour connaître les difficultés pour maintenir un tel système. Ne voyez donc pas mes remarques comme des critiques, au contraire si je peux apporter ma petite contribution comme le colibri (**) je le ferai.

Bon courage à tous.

(*) par "moulinette" j'entends une petit appli genre OMM_un_mois ou wlktocsvchoix

(**) Un jour, dit la légende, il y eut un immense incendie de forêt. Tous les animaux terrifiés, atterrés, observaient impuissants le désastre. Seul le petit colibri s’activait, allant chercher quelques gouttes avec son bec pour les jeter sur le feu. Après un moment, le tatou, agacé par cette agitation dérisoire, lui dit : « Colibri ! Tu n’es pas fou ? Ce n’est pas avec ces gouttes d’eau que tu vas éteindre le feu ! »

Et le colibri lui répondit :« Je le sais, mais je fais ma part. »

[lobarbot]

Pour corroborer mon propos, je vais prendre seulement 6 exemples sur les TN, toujours en 2015 et en heures légales, avec les seules données affichées dans les climatologies mensuelles de la station sur IC :

- le 03/01, il est affiché 7.5°, alors que le 02/01 à 19h30 il faisait 5.1°,

- le 06/01, il est affiché 5.0°, alors que le 05/01 à 21h00 il faisait 4.2°,​

- le 28/01, il est affiché 4.1°, alors que le 27/01 à 20h30 il faisait 3.9°,​

- le 04/02, il est affiché -0.9°, alors que le 03/02 à 23h30 il faisait -1.2°,​

- le 01/03, il est affiché 12.1°, alors que le 28/02 à 20h00 il faisait 10.7°,​

- le 28/03, il est affiché 11.4°, alors que le 27/03 à 19h30 il faisait 10.3°.

Les valeurs sont bien dans la base de données. Que l'on prenne ces horaires en heures UTC ou en heures légales, on est bien dans la tranche 18h UTC veille à 18 h UTC du jour (ici 19h légales à 19 h légales ).

Bon, la terre a continué de tourner depuis... :-)

Bon WE à tous.

[Cyrilleb]

Bonjour,

Oui je sais comment modifier les valeurs avec le crayon ;-)

, mais tu confirmes ma remarque quand il manque une ligne complète il n'est pas possible de la remplir, quand on clique sur le crayon on a une page d'erreur qui s'affiche. C'est effectivement dommage, car on peut avoir une coupure Internet supérieure à une heure.

As-tu essayé OMM_un_mois

? Est-ce conforme à ta feuille Excel ?

Quant aux autres erreurs, toujours sur la pluviométrie, j'en ai notées quelques unes en faisant le travail précédent. Ce ne sont pas apparemment des erreurs type OMM, mais des valeurs inférieures ou supérieures aux valeurs : cela semble aléatoire.Je vais essayer de faire une étude plus précise, mais cela risque d'être long.

Pour l'envoi mensuel, on pourrait même fournir une "moulinette" à chaque membre du réseau, qui serait déclenchée par une tâche programmée tous les 2 du mois et enverrait un fichier simplifié et en clair avec les seules données utilisées par IC.

J'ai essayé ton programme OMM_un_mois, ça ne fonctionne pas correctement chez moi, j'obtiens des différences entre ma feuille excel et ton programme. Je pense que ta station est réglée en heure légale, et que tu fais les calculs de 8h à 8h (pour la Tx ou les précipitations), ou de 20h à 20h (pour la Tn). Comme ma station est en heure TU, je fais mes calculs de 6h à 6h, ou de 18h à 18h...

Il faudrait que l'on puisse choisir le fuseau horaire de la station dans ton programme. Pour ma part, j'ai laissé tombé l'heure légale car le passage à l'heure d'hiver entraîne systématiquement la perte d'une heure de données, et ça complique les calculs pour les données OMM...

Pour les techniciens d'Infoclimat:

Autre erreur constatée sur les stations en weatherlink IP: à chaque heure, la quantité de pluie est prise à partir de "last hour rain" de la page weatherlink http://www.weatherlink.com/user/cyrilleb/index.php?view=summary&headers=1

S'il pleut fort au moment où cette donnée est prélevée, il n'est pas rare de voir des écarts de 0.2 ou 0.4mm avec la réalité, car la page weatherlink n'est pas mise à jour à la seconde près... Pour les techniciens d'IC, Il serait plus judicieux de soustraire le cumul de la journée actuel de celui enregistré à l'heure précedente.

Exemple:

A 8h: cumul total de 6.4mm (day rain)

A 9h: cumul total de 9.4mm dans ce cas, on peut avoir last hour rain = 2.8mm (au lieu de 3mm) sur la page weatherlink.

Alors que si on fait 9.4mm - 6.4mm = 3mm, c'est toujours correct.

La donnée "last hour rain" est peu précise.

Pour la dernière heure de la journée, il faut quand même utiliser "last hour rain" car le total est remis à zéro...

Lobarbot: Pour l'envoi du fichier wlk, il faudrait effectivement envoyer 3 fichiers à chaque fois, le mois en cours, le mois précédent et le mois suivant pour calculer correctement les données du 1er et du dernier jour du mois. Et il faut tenir compte de l'heure de la console qui peut être en TU ou en heure légale... Avoir un petit programme chez soi est une autre solution...

Je vois que tu n'as validé aucune de tes données dans les tableaux mensuels, certes c'est pratique pour voir toutes les erreurs et les analyser, mais il faudrait que tu valides (et corriges si nécessaire) tes données, afin que tout le monde puisse consulter des données fiables et sans erreur. Nous sommes tellement peu à le faire

[lobarbot]

Bonjour,

Tout d'abord merci pour cet avis détaillé, mais je ne suis pas d'accord sur les 3 points que tu soulèves :

1) Mon programme OMM_un_mois

tient compte systématiquement de l'heure d'hiver ou de l'heure d'été. Ce type d'heure est calculé pour chaque journée. Il n'y a pas d'erreur sur ce point

, je fais les calculs , par exemple pour les TN, de 19h à 19 heures en hiver et de 20h à 20h en été. Il est vrai que j'aurais dû préciser que ce programme s'appliquait aux heures légales, mais comme mes messages étaient écrits en référence aux statistiques d'IC, qui elles sont bien affichées en heures légales, cela m'a semblé évident. Je vais rajouter ce point dans la doc. Ce programme ne fonctionne donc pas si on est en heures UTC, je vais faire une modification dans mon programme pour offrir cette possibilité. J'ai vérifié tous les résultats

qui étaient en contradiction avec ceux d'IC, je les ai détaillés lors de mon message précédent, ils sont donc visibles par tous.

2) Pour les calculs de pluie, comme pour les autres calculs d'ailleurs, ils ont été effectués à partir des données des fichiers aaaa-mm.wlk et pas à partir des résultats "dernière heure" un peu hasardeux. De plus quand il y a un cumul de pluie h

un jour j

, h

non nul, dans l'archive notée 8:00

(en été), h

est comptabilisé dans la pluie du jour j-1

, car la pluie est tombée entre 7:55 et 8:00

si l'archive est de 5 mn. Idem ici, les résultats ont été vérifiés et sont visibles (voir le premier message de ce fil)

3) Pour mes données sur IC je ne les ai pas corrigées, car les données modifiables sont les données horaires dans la climatologie quotidienne et celles-ci sont exactes (hormis les manquantes). Ce sont les calculs qui sont fait à partir de ces données par les algorithmes utilisés, notamment dans la climatologie mensuelle, qui sont quelquefois erronés .

Merci encore pour ton message et dès que j'aurai un peu de temps je vais paramétrer mon programme pour qu'il puisse être utilisé par ceux qui archivent totalement en UTC. Si tu veux bien je te l'enverrai d'abord pour le tester.

[Cyrilleb]

1) Mon programme OMM_un_mois tient compte systématiquement de l'heure d'hiver ou de l'heure d'été. Ce type d'heure est calculé pour chaque journée. Il n'y a pas d'erreur sur ce point, je fais les calculs , par exemple pour les TN, de 19h à 19 heures en hiver et de 20h à 20h en été. Il est vrai que j'aurais dû préciser que ce programme s'appliquait aux heures légales, mais comme mes messages étaient écrits en référence aux statistiques d'IC, qui elles sont bien affichées en heures légales, cela m'a semblé évident. Je vais rajouter ce point dans la doc. Ce programme ne fonctionne donc pas si on est en heures UTC, je vais faire une modification dans mon programme pour offrir cette possibilité. J'ai vérifié tous les résultats qui étaient en contradiction avec ceux d'IC, je les ai détaillés lors de mon message précédent, ils sont donc visibles par tous.

Nous sommes bien d'accord, ton programme fonctionne pour des données en heure légale, et il tient compte du changement d'heure.

2) Pour les calculs de pluie, comme pour les autres calculs d'ailleurs, ils ont été effectués à partir des données des fichiers aaaa-mm.wlk et pas à partir des résultats "dernière heure" un peu hasardeux. De plus quand il y a un cumul de pluie h un jour j, h non nul, dans l'archive notée 8:00 (en été), h est comptabilisé dans la pluie du jour j-1, car la pluie est tombée entre 7:55 et 8:00 si l'archive est de 5 mn. Idem ici, les résultats ont été vérifiés et sont visibles (voir le premier message de ce fil)

Ma remarque concernant les données de pluie était destinée aux techniciens d'Infoclimat, elle ne concerne pas ton programme.

3) Pour mes données sur IC je ne les ai pas corrigées, car les données modifiables sont les données horaires dans la climatologie quotidienne et celles-ci sont exactes (hormis les manquantes). Ce sont les calculs qui sont fait à partir de ces données par les algorithmes utilisés, notamment dans la climatologie mensuelle, qui sont quelquefois erronés .

Je crois que nous nous sommes mal compris sur ce point. En effet, tu peux corriger les données de chaque jour (chaque 1/2 heure, ou même toutes les 10 min) avec le petit crayon au début de chaque ligne: http://www.infoclimat.fr/observations-meteo/temps-reel/gujan-mestras/000R8.html

Mais tu peux aussi corriger la climatologie mensuelle pour chaque mois sur cette page: http://www.infoclimat.fr/climatologie-mensuelle/000R8/septembre/2015/gujan-mestras.htmlen cliquant sur le crayon à droite, au bout de chaque ligne; j'ai l'impression que tu n'as pas vu cette fonction. Cela permet de corriger les erreurs de calcul des algorithmes d'Infoclimat.

Pour mes données mensuelles, il y a une coche verte, indiquant que les données ont été corrigées et validées: http://www.infoclimat.fr/climatologie-mensuelle/000V4/septembre/2015/la-bruffiere.htmlOr, je ne vois pas cette coche verte sur tes données de climato mensuelle.

Merci encore pour ton message et dès que j'aurai un peu de temps je vais paramétrer mon programme pour qu'il puisse être utilisé par ceux qui archivent totalement en UTC. Si tu veux bien je te l'enverrai d'abord pour le tester.

OK, pas de soucis!

Petite question: ton programme fonctionne avec n'importe quel pas d'archivage? Il faut que ça fonctionne avec un pas allant de 1min à 1heure.

[lobarbot]

Bonjour,

Les durées d'archives ainsi que les heures des archives sont écrites dans les fichiers aaaa-mm.wlk

pour chaque archive donc mon programme s'applique, a priori, à n'importe quel pas d'archive même si celui-ci change en cours de journée.

Les fichiers binaires aaaa-mm.wlk

sont des fichiers très riches en informations. Pour chaque jour il y a deux résumés de plus de 70 valeurs (tu peux en voir une partie sur mon site http://www.meteo-gujan.org/Historique/TouteslesdonneesSemaine.php ) et pour chaque ligne d'enregistrement (archive ) il y a entre 25 et 50 valeurs (suivant le nombre de capteurs). On ne les exploite pas complètement !

Mon champ visuel a occulté le bout des lignes des climatologies mensuelles ​! Bon, pour le moment, je laisse les résultats tels qu'ils sont pour démonstration, en espérant que ces bugs seront réparés rapidement. Je les résume à nouveau pour faire le point après tous ces messages :

1) Pour les pluies, les données journalières sont conformes aux normes OMM, mais les cumuls de pluie entre minuit du dernier jour du mois et 6h UTC du premier jour du mois suivant sont systématiquement perdus. Cela peut entrainer une erreur de l'ordre de 10% en cumul annuel, ce qui n'est pas négligeable.

2) Pour les TN et les TX, les valeurs sont calculées suivant les heures de la journée et non suivant les normes OMM. Les erreurs induites sont quasi nulles sur les TX, par contre sur les TN on peut avoir des différences significatives, surtout en hiver, sur ma station en 2015 j'ai eu jusqu'à 2,4°C d'écart.

A toutes fins utiles, n'hésitez pas à me contacter pour donner un coup de main !

PS : Pour Cyril, merci de ton accord. Je te tiens au courant.

[lobarbot]

Bonjour,

Les versions de ces programmes (OMM_un_mois_UTC

et​​ OMM_mois_courant_UTC

) ​pour les stations configurées en heure UTC sont disponibles à l'adresse habituelle :

http://www.meteo-gujan.org/Visiteurs

Les programmes ont été testés et validés.

PS : Merci à Cyrilleb qui m'a envoyé ses fichiers pour tester ces programmes.

​