Cumuls précipitations Xnet et GraphWeather différent

[oregon66]

Bonjour,
Mes données de cumul de précipitations sont différentes entre mes données Xnet (fichiers csv) et GraphWeather. Par exemple, pour Janvier 2014 cumul mensuel de 35.6 mm pour GraphWeather et 38.8 mm sur mon fichier csv Xnet (voir capture ci-jointes). Recherche de données erronées sur mon fichier csv mais rien d'anormal de trouvé.
De plus, cumul journalier et mensuel également différents lorsque qu'on passe de utc+1 à utc+2 (heure d'hiver/heure d'été) pas facile d'avoir une base climato à moins de calculer directement en utc les données fournies par Xnet...

Les données de température maximale et minimale pour une journée donnée sont calculées sur une journée de 0h00 locale à 0h00 locale ? Et non sur les normes OMM ?
Exemple norme OMM :
La température minimale: entre 18 heures U.T.C. la veille et 18 heures U.T.C le jour même
La température maximale : entre 6 heures U.T.C. et le lendemain 6 heures.
Pensez vous qu'il serait possible de créer un script en paramétrant les normes OMM pour les différents champs de relevés et ainsi avoir une base climato aux normes ?
[img][IMG]http://img11.hostingpics.net/thumbs/mini_515429Janvier2014.png[/img][/img]
[img][IMG]http://img11.hostingpics.net/thumbs/mini_511662Xnet2014.png[/img][/img]

[jturlier]

De plus, cumul journalier et mensuel également différents lorsque qu'on passe de utc+1 à utc+2 (heure d'hiver/heure d'été) pas facile d'avoir une base climato à moins de calculer directement en utc les données fournies par Xnet...

Bonjour,
Pour info les dates xnet sont en UTC

Il y a sans doute des problème d'arrondis entre les xnet et les données NOAA affichées par le script de comparaison, car les stations WMR200 ont un pas de 1mm, mais le pluviomètre a tendance à générer des valeurs à 3 décimales dans xnet.

Pour les tn et tx, tu as la réponse ici viewtopic.php?f=58&t=618&p=5997&hilit=t ... i+tn#p5997

Personnellement, je transfère mes données dans une base MySQL et les problèmes de pluie ne sont plus qu'un mauvais souvenir car à chaque restauration de la console, le total est mis à 0, tu ne peux donc plus te fier à rien.

[oregon66]

Bonjour,
Pour info les dates xnet sont en UTC

Justement, des cumuls journaliers différents selon les réglages utc+1/utc+2 dans GraphWeather (faire test)

Il y a sans doute des problème d'arrondis entre les xnet et les données NOAA affichées par le script de comparaison, car les stations WMR200 ont un pas de 1mm, mais le pluviomètre a tendance à générer des valeurs à 3 décimales dans xnet.

Donc on aurait tous des valeurs erronée en passant par le script NOAA ?
Mon cumuls total (année 2015) sur ma station et Xnet sont égaux (526.1 mm) mais par GraphWeather j'ai un total de 515 mm

Pour les tn et tx, tu as la réponse ici viewtopic.php?f=58&t=618&p=5997&hilit=temperature+maxi+tn#p5997

C'est les tn et tx basé sur une journée mais sur quelle période ? 0h00 loc. au lendemain 0h00 loc. ?

[jturlier]

C'est les tn et tx basé sur une journée mais sur quelle période ? 0h00 loc. au lendemain 0h00 loc. ?

Non standard OMM

Donc on aurait tous des valeurs erronée en passant par le script NOAA ?
Mon cumuls total (année 2015) sur ma station et Xnet sont égaux (526.1 mm) mais par GraphWeather j'ai un total de 515 mm

Ce ne sont pas réellement des valeurs erronées dans GW, c'est plutôt lié à la mauvaise qualité des pluviomètres des WMR200, car je ne vois pas bien comment avec un pas de 1mm tel qu'il est prévu avec ces stations on puisse obtenir des décimales (c'est malheureusement un phénomène connu. Chaque fois que tu cumules 1mm (vrai) dans, en réalité tu as 1.016 comptabilisé. D'ailleurs, si bêtement on multiplie 515 par 1.016, ça donne 523.24. Je pense donc qu'avec ce type de matériel, il ne faut pas être plus royaliste que le roi. Si tu souhaites des chiffres plus proches de la réalité, la VP2 serait certainement un meilleur choix.

Je ne sais pas comment tu as fait, mais personnellement j'ai déjà dû faire 4 restaurations de ma console suite à la perte de la sonde UV, si bien qu'à chaque fois le total de la pluie est remis à 0, tu as donc bien de la chance d'avoir encore le cumul de l'année de ta station dans xnet !

Justement, des cumuls journaliers différents selon les réglages utc+1/utc+2 dans GraphWeather (faire test)

dans GW si tu fais un recalcul des statistiques, GW utilise le décalage utc en cours donc, tu l'appliques sur toutes les données statistiques que tu recharges

[oregon66]

Ok merci pour ces précisions et plutôt en accord avec ton avis et tes arguments sur la précision du pluviomètre de la WMR 200
Par contre pour avoir une base climato aux normes OMM différente de la NOAA (notamment sur le cumul journalier de précipitation), le mieux c'est de recalculer ses stats avec son fichiers csv en utc
Penses-tu que GraphWeather calcule un cumul de pluie journalier de 6h00 utc le jour j à 6h00 utc du lendemain ? il me semble que c'est sur la base ricaine (noaa) de 0h00 loc à 0h00 loc
Merci pour tes réponses et pour la Davis Vantage Pro2 pour l'instant cela reste un doux et beau rêve mais je l'aurais un jour je l'aurais

[jturlier]

Boinjour,

Penses-tu que GraphWeather calcule un cumul de pluie journalier de 6h00 utc le jour j à 6h00 utc du lendemain ? il me semble que c'est sur la base ricaine (noaa) de 0h00 loc à 0h00 lo

voici la réponse d'Antoine :
Si tu parles du calcul dans GW, j'avais pris les normes. Tn entre 18h j-1 et 18 j Tx entre 6h j et 6h j+1.
Bonne journée

[oregon66]

Boinjour,

Penses-tu que GraphWeather calcule un cumul de pluie journalier de 6h00 utc le jour j à 6h00 utc du lendemain ? il me semble que c'est sur la base ricaine (noaa) de 0h00 loc à 0h00 lo

voici la réponse d'Antoine :
Si tu parles du calcul dans GW, j'avais pris les normes. Tn entre 18h j-1 et 18 j Tx entre 6h j et 6h j+1.
Bonne journée

Re,
Je ne comprend pas, ayant un peu de temps en ce moment, j'ai vérifié si les statistiques de Graphweather était bien programmées pour calculer les Tn avec les normes OMM comme précisé ci-dessus.
Prenons un exemple :
Rappel sur la norme OMM utilisée par Météo-France pour la température minimale : "relevé effectué sur une période de 24h soit de 18h00 UTC la veille du jour j et jusqu'à 18h00 UTC le jour j"
Prenons en exemple la Tn calculée pour le 13 janvier 2014
Cela nous donnera donc une période de 24 h compris entre 18h00 UTC le 12 janvier 2014 et 18h00 UTC le 13 janvier 2014 soit en hiver 19h00 locale la veille et 19h00 locale le jour j comme sur la capture du tracé sur cette période à l'aide de Graphweather (image 1).

On relève donc sur cette tranche de 24h en accord avec la norme OMM une Tn de 9.8 °C.

Comparons maintenant avec les relevés NOAA générés par Graphweather (statistiques) sur la deuxième capture

On relève une Tn ce jour-là de 9.3 °C enregistrée le 13 janvier 2014 à 23h31 locale....(soit 22h31 UTC) et donc au "dela" de 18h le jour j...
C'est un exemple parmi beaucoup d'autre rien que sur le premier mois (janvier 2014) du début de mes relevés
Donc êtes-vous sûr que les Tn sont calculées sur les normes OMM ? C'est simplement pour savoir si je dois créer une climatologie sur des relevés de 0h00 locale à 0h00 le lendemain ou une climatologie avec les normes OMM à l'aide de mes données csv, je ne remets pas en cause l'énorme travail et la qualité des programmes Xnet et Graphweather bien au contraire que les choses soient bien claires

[ardigier]

Je me demande si tu n'es pas entrain de confondre la Tn ( 18 h à 18 h ) et la T minimale (0 h à 24 h)

[oregon66]

Je me demande si tu n'es pas entrain de confondre la Tn ( 18 h à 18 h ) et la T minimale (0 h à 24 h)

Ben justement... ce sont deux paramètres bien différents donc dans les relevées NOAA ce sont les températures minimales sur une tranche 0 à 24 h
C'est bon niquel je viens de trouver les Tn et Tx dans les statistiques Graphweather (voir capture)

Nous avons la Tn et Tx dans le cadre du dessus et la température minimale sur une tranche 0 à 24h dans le tableau en dessous

Cela va me faire gagner du temps pas besoin d'éplucher mes données csv