problème avec données corrompues

[stephrac74]

Bonjour,

C'est un peu hors sujet Graphweather, mais je souhaiterai savoir si d'autres ont le même souci que moi.

J'utilise WeatherDisplay pour récolter mes data de ma WMR200 et j'enregistre un log toutes les minutes. J'ai environ une trentaine de données donc le fichier devient conséquent (depuis le début 2011 j'en suis à 64Mo)

A l'intérieur de ce fichier il y a parfois des bourdes. Genre deux lignes avec la même date (lignes écrites deux fois), parfois des trous dans les log de quelques minutes.
Graphweather ne supporte pas du tout ce genre de boutade (en particulier les dates qui sont répétées ou pire qui n'arrivent pas dans le bon sens (genre une date inférieure à la ligne précédente) ce qui arrive (problème d'écriture ?). J'en profiter pour préciser que ce serait bien que ces cas soient gérés sous GW afin de ne pas planter (au pire il n'a qu'à ignorer la ligne plutôt que de crasher ! )

Bref, est-ce que d'autres ont ce problème récurent et si oui comment le solutionnent t'il ? Pour ma part j'essaie de faire des calculs via excel pour trier et effacer les lignes corrompues, mais j'y passe un temps dingue et actuellement j'ai une erreur quelque part que je ne trouve pas. (pas un probleme de date). Mon fichier faisant presque 500 000 lignes, c'est pas simple !

Comme ce genre de corruption de donnée est récurent, serait il possible de prévoir dans GW un test qui vérifie que la donnée lui plait avant de la traiter et de crasher lorsque cela ne lui plait pas ?

J'utilise GW 3.09

Merci
Stéphane

[ardigier]

je n'utilise pas ton logiciel avec la WMR200 , j'utilise xnet, ce dernier lorsqu'il enregistre les données , verifie la cohérence de celles-ci et en particulier les dates "anormales" et dans ce cas il les stocke dans un ficher séparé
cela permet eventuellement de reprendre manuellement certain enregistrements
d'autre part le pas d'enregistrement de 1 mn me parait excessif, avec un pas de 5 mn cela me suffit

[domidom81]

Bonsoir,
+1 avec Ardigier, passe à 5mm, sinon tu vas te retrouver avec un fichier super poid-lourd (si je me souviens j'avais à peu prés tes 64Mo sur plus de 2 ans)

a+

[jturlier]

Bonjour Stéphane,
+1 avec René et Dominique, un pas d'enregistrement inférieur à 5 minutes est parfaitement inutile en météo, le seul phénomène qui pourrait être manqué, c'est pour les rafales. La plupart des logiciels de pilotage des stations donnent la rafale la plus élevée de la période.

Pour information, j'ai un pas de 10 minutes et depuis le 1er janvier 2005 cela représente une base de données de 300 Mo. (Si GW devait traiter ce volume en tant que fichiers, le PC n'aurait pas beaucoup de temps pour faire autre chose.)

Faire du temps réel n'est nécessaire que pour la présentation de données instantanées, pas pour leur enregistrement.
Cependant, chacun est naturellement libre, et c'est heureux, de faire ce que bon lui semble !

Jean

[stephrac74]

Stéphane, en mode HELP HELP HELP HELP


Bonjour,

Bon j'ai toujours un gros problème avec mon fichier de données et GW.

D'abord je dois préciser qu'avec Weather Display, je ne peux pas faire de log entre 1 et 10 mn... Donc 5mn impossible, c'eut été mon choix si cela avait été possible. 10 mn ça commence à bien se voir sur la qualité des graphs nettement moins précis, en particulier pour le vent mais au jugé de mes soucis, je crois que je ne vais pas avoir le choix.

Cependant, mon problème immédiat est ailleurs : J'ai toujours mon problème de données corrompues.

Mon fichier fais près de 500 000 lignes, donc obligation de faire des contrôle automatiques pour s'en sortir.
Sous excel, j'ai pu corriger quelques 13000 lignes erronées du genre doublons de dates, dates inversées, etc... Bref j'ai fais un calcul simple
=date(c1;b1;a1)+temps(d1;e1;0) pour convertir la date en une valeur unique
ensuite je regarde si ligne - ligne-1 <= 0. Si oui, c'est que j'ai un problème de date, je filtre les lignes erronées et les corrige ou efface

Maintenant je n'ai plus d'erreur de date.

Cependant sous GW, j'ai toujours des problèmes. Parfois il crashe en voulant lire mes données, ou parfois il affiche un peu n'importe quoi, même si les données du jour sont normale. Je remarque que les dates où il s’emmêle les pinceaux correspondent à certaines anomalies genre trou dans les données ou autre, mais pour autant le fil des dates est croissant donc sans erreur. Cela ne semble donc pas être un problème de date.

alors là je ne m'en sors plus donc AU SECOURS !!!!!!

1. Serait il possible de savoir quels sont les cas qui peuvent provoquer des erreurs sous GW dans la lecture des données et qui ne sont pas testés ?(c'est sûr sur les dates, mais y a t il d'autres conditions )

2. Exisite t'il un outil de vérification du fichier de données ?

3. Mieux, serait il possible de prévoir dans GW un controle sur les champs et/ou valeurs, et lorsque quelque chose n'est pas conforme, d'indiquer le numéro des lignes défectueuses dans un fichier log et mieux encore, ne pas tenter de traiter les lignes qui ont des erreurs qui le font planter...


Merci de votre aide
Stéphane

[ardigier]

si tu as autant d'erreur lors de l'enregistrement des données, je crois qu'il faudrait aussi voir avec le concepteur de ce programme
et c'est pas forcémment à GW de corriger les erreurs de l'autre logiciel

[stephrac74]

Bonjour,
oui, il est clair que je dois solutionner les deux côtés.

Ce n'est pas tant que GW doive corriger les erreurs d'autres logiciels, mais plutôt qu'il devrait se prémunir de données qui le font planter. C'est je pense une faiblesse à corriger car des données corrompues, ce n'est pas quelque chose d'inenvisageable pour tout le monde, et GW devrait pouvoir les détecteret les ignorer pour ne pas planter. quelques tests à ajouter à la lecture, ce serait une solution fiable et simple

Weahter Display n'est surement pas la meilleure application pour juste récolter les données et calculer les radiations solaires de mon capteur de température solaire, mais pour le moment je n'ai pas trouvé d'autre application pour le faire
Je pense possible que le problème provienne de l'échantillonnage toutes les minutes. J’essaierai de passer à 10mn durant quelques temps pour voir. Mais cependant avant ça je dois urgemment solutionner le problème avec GW car pour le moment la station est plantée et je ne peux plus générer mes graphs...

Stéphane

[jturlier]

Bonsoir Stéphane,
+1 avec René,
Ce n'est pas à GW, qui pédale déjà beaucoup, de faire la vérification et les corrections des fichiers mal enregistrés.
C'est la responsabilité des utilisateurs de fournir des données cohérentes et conformes aux spécifications du programme.
Mettre ces vérifications dans GW pénaliserait tous les autres utilisateurs au plan des temps de traitement.
Antoine a principalement axé la version 3 sur une amélioration des performances, alors je ne souhaiterai pas revenir aux temps de réponse des versions 2.xxx.
Que les anomalies soient pointées et arrêtent le traitement, pourquoi pas !

Jean

[stephrac74]

Bonsoir,

Je suis partiellement d'accord avec vous. Un logiciel quelconque doit s'assurer que les données qu'il traite n'induisent pas une erreur d'exécution irrécupérable du logiciel. Imaginez votre PC qui crashe parce que vous n'avez pas entré la date correctement (vous allez me dire que c'est pas à lui de vérifier que l'utilisateur n'a pas deux mains gauche ? ), ou un ascenseur qui resterait bloqué parce que vous n'avez pas appuyé sur le numéro d'étage et la fermeture des portes dans le bon ordre ou encore une pompe à insuline qui s'arrêterait parce que les valeurs de glycémie du patient sont en dehors de la plage normale de mesure ou enfin un avion qui couperait ses moteurs car le capteur de vitesse ou d'altitude a renvoyé une valeur erronée ??? Ce serait désagréable hein ? Je suis d'accord que dans l'absolu tous ces cas de figure ne devraient pas arriver, mais il arrivent, aussi il faut les prévoir.

Ensuite que les données soient fausses c'est une autre histoire dont GW n'a pas à se soucier je suis d'accord, mais crasher à cause d'une donnée en dehors des valeurs attendues par un calcul, c'est un point qui doit être corrigé... Il y en a qui ont perdu une fusée il ya quelques années comme ça à cause d'une variable qui a dépassé les valeurs attendues dans un calcul et qui n'était pas bornée ...

Ayant travaillé dans des secteurs d'activité où la sureté était de mise, que ce soit dans l'électronique, le logiciel ou la mécanique, c'est un cas de figure classique qui doit être pris en compte. Heureusement il existe désormais des outils pour évaluer ces risques (AMDEC) ainsi que pour automatiser ces contrôles car l'erreur est malheureusement vite faite (Polyspace, ...)

Bref pour en revenir à des choses plus légères et à GW, il devrait dans tous les cas vérifier que le résultat d'un calcul, quelque soit la donnée d'entrée qu'il lui est présentée, n'induise pas un crash de l'application. C'est juste ce point qui doit être je pense amélioré. Par ailleurs sur un PC récent, ce n'est pas 10 tests supplémentaires qui vont notablement augmenter le temps de traitement. Avec un déjà vieux core duo pouvant traiter 24 milliard d'instructions par seconde ce serait un comble.

J'ai vraiment besoin de savoir comment GW traite ses données autrement je ne pourrais pas trouver quelles sont les données qui peuvent le faire crasher. Au moins si je pouvais avoir cette info, je pourrais déjà créer un outil permettant de détecter quelles sont les données qui le font crasher car en plus les erreurs d'affichage observées en cas de données qui ne lui plaisent pas ne se font pas à l'endroit des données qui le perturbent rendant le diagnostique quasi impossible. Bien sûr je pense que le soft devrait être amélioré sur ce point, mais si tu ne souhaites pas le faire Antoine, alors pourrais tu alors m'indiquer comment sont traitées les données pour que je puisse résoudre mon problème et déterminer ce qui fait crasher GW ?

Et malheureusement en attendant, mon site web est planté depuis quelques jours et déjà des visiteurs s'en inquiètent. Ce ne serait pas si critique si j'étais sûr d'arriver tôt ou tard à tout remettre en route, mais là je suis sec de chez sec aussi je n'ai pas de solution autre que d'écraser mes données depuis le 20 septembre....

merci merci....
Bonne nuit à tous
Stéphane

[MAGNUS]

Bonjour stefphrac74,
Pourquoi, en attendant de régler ce problème, ne pas essayer le programme Xnet qui permettrait au moins d'envoyer des données sur votre site afin de satisfaire vos lecteurs.
Vous pourriez pas la suite, revenir à vos premiers amours.
Cordialement.

[jturlier]

Bonjour Stéphane,
Je suppose que tu es en version 3.0.011b, n'oublie pas que c'est encore une version de test et que nombre de contrôles ne sont pas implémentés.
Qu'en est-il avec la version 2.0.321 ? L'as-tu essayée ?
Peux-tu dire avec quel plugin tu tournes. En fonction de ça, si j'ai les routines de décodage dans mes archives, j'essaierai de créer un fichier CSV (type Xnet ou table dans une base de données, pas possible de re-créer un fichier WD ) avec un pas de 10 min.
Si c'est faisable je te passerai un MP.

Jean

[stephrac74]

Bonjour à tous et merci pour votre support.

@Magnus : La dernière fois que j'ai essayé Xnet, cela ne fonctionnait pas bien. Bon, c'était en 2009 certes. Est-ce que maintenant la version est stable ?
De plus, Je ne pense pas que Xnet soit capable de traiter mon capteur de température solaire pour convertir la valeur en radiations solaires comme le fais Weather Display. Cependant il me semble que cette fonction est dans GW maintenant, il faut que je creuse, mais il faut aussi rendre mes anciennes données compatibles avec les nouvelles, bref ça ne parait pas simple.

@Jean : Merci pour ton aide.
J'utilise GW 3.0.9 et j'ai testé la 2.0.321 pour voir la différence. Ca crash pareil dans les deux cas.

Weahter Display me génère un fichier log au format CSV toutes les minutes avec l'entête de données suivant:

Code : Tout sélectionner

%date-day%;%date-month%;%date-year%;%time-hour%;%time-minute%;%temp%;%hum%;%baro%;%dew%;%avgspd%;%gstspd%;%cloudheightmeters%;%dirdeg%;%dayrn%;%hourrn%;%windch%;%humidexcelsius%;%indoortemp%;%maxsolarfortime%;%currentrainratehr%;%totalrainlast24hours%;%VPuv%;%VPsolar%;%generalextratemp1C%

[/size]
Dans GW j'utilise le plugin CSV pour lire ce fichier.

Dans les problèmes que je rencontre, j'ai :
- des doublons avec deux lignes répétées (même date), mais où une ou deux valeurs sont différentes. Deux dates identiques, GW il aime pas du tout et crashe immédiatement
- des données corrompues : si ça tombe sur une date, alors les lignes ne sont plus chronologiques, et crash immédiat.
Avec ma routine excel, je pense piéger ces cas de figure et pouvoir les corriger.
- parfois je trouve une donnée corrompue dans les données (genre rafale de vent à 92.3 km/h). Si je corrige cette valeur à la main par 0.0 km/h, alors cela peut le planter. Je suis certain que ce n'est pas le changement de cette valeur particulière qui le fait planter mais surement que dans le traitement des données , changer cette valeur induit un problème qui conduit au crash.

Actuellement, je parviens à lancer GW sans qu'il ne crashe. Cependant j'ai maintenant le problème des données incorrectement traitées.

Par exemple entre le 19 et 20/9, j'ai une interruption de donnée. Voir le log ci dessous :

Code : Tout sélectionner

20;9;2011;9;36;12.4°C;79;1022.0 mb;8.9°C;0.0 km/h;0.0 km/h;582;292 °;  0.0 mm;0.0;12.4°C;13.2°C;22.6;460;0.0;0.0 mm;4.0;0
20;9;2011;9;37;12.6°C;77;1022.0 mb;8.7°C;0.0 km/h;0.0 km/h;631;292 °;  0.0 mm;0.0;12.6°C;13.3°C;22.6;464;0.0;0.0 mm;5.0;0
20;9;2011;9;38;12.6°C;74;1022.0 mb;8.1°C;0.0 km/h;0.0 km/h;704;292 °;  0.0 mm;0.0;12.6°C;13.0°C;22.6;467;0.0;0.0 mm;5.0;0
20;9;2011;9;39;12.7°C;72;1022.0 mb;7.8°C;0.0 km/h;0.0 km/h;755;292 °;  0.0 mm;0.0;12.7°C;13.0°C;22.6;471;0.0;0.0 mm;1.0;0
20;9;2011;9;40;12.7°C;72;1022.0 mb;7.8°C;0.0 km/h;0.0 km/h;755;292 °;  0.0 mm;0.0;12.7°C;13.0°C;22.6;474;0.0;0.0 mm;1.0;0
20;9;2011;18;36;12.7°C;72;1022.0 mb;7.8°C;0.0 km/h;0.0 km/h;755;292 °;  0.0 mm;0.0;12.7°C;13.0°C;22.6;478;0.0;0.0 mm;0.0;0
20;9;2011;18;37;12.7°C;72;1022.0 mb;7.8°C;0.0 km/h;0.0 km/h;755;292 °;  0.0 mm;0.0;12.7°C;13.0°C;22.4;287;0.0;0.0 mm;0.0;0
20;9;2011;18;38;12.7°C;72;1022.0 mb;7.8°C;0.0 km/h;0.0 km/h;755;292 °;  0.0 mm;0.0;12.7°C;13.0°C;22.4;283;0.0;0.0 mm;0.0;0
20;9;2011;18;39;12.7°C;72;1019.0 mb;7.8°C;0.0 km/h;0.0 km/h;755;292 °;  0.0 mm;0.0;12.7°C;13.0°C;22.5;279;0.0;0.0 mm;5.0;0
20;9;2011;18;40;12.7°C;72;1019.0 mb;7.8°C;0.0 km/h;0.0 km/h;755;292 °;  0.0 mm;0.0;12.7°C;13.0°C;22.5;276;0.0;0.0 mm;4.0;0
20;9;2011;18;41;16.1°C;41;1019.0 mb;2.8°C;0.0 km/h;0.0 km/h;1804;292 °;  0.0 mm;0.0;16.1°C;14.7°C;22.5;272;0.0;0.0 mm;2.0;231
20;9;2011;18;42;16.1°C;41;1019.0 mb;2.8°C;0.0 km/h;0.0 km/h;1804;292 °;  0.0 mm;0.0;16.1°C;14.7°C;22.5;268;0.0;0.0 mm;0.0;76

[/size]
Si je trace le graph mensuel, on voit bien le trou de data entre 9h40 et 18h36, mais on voit pour tout le 21/9 des données complètement fausses ne correspondant pas au fichier log.
Si maintenant je zoome quelques jours sur cette date (voir graph ci dessous) alors on voit que GW se mélange les pinceaux et toute la zone zoomée de plusieurs jours affiche n'importe quoi. C'est donc bien dans le processing par GW qu'en fonction de la date qu'on lui demande de traiter, il se perd. Surement à cause d'une donnée corrompue, mais c'est là que je n'arrive pas à retrouver.

J'ai le même souci cette semaine où j'ai un trou dans mes données du 19 au 22/11 (voir 2e graph). Si je trace un graph mensuel, alors on voit bien le trou, mais il repart le 22/11 avec des données erratiques alors qu'elles semblent correcte à première vue (je les ai vérifiées à la main : 1 seule journée). Si maintenant je trace le graph à la journée, GW refuse tout simplement de m'afficher quoique ce soit après le 19. Ci dessous l'extrait du log autour du trou de données :

Code : Tout sélectionner

19;11;2011;23;20;2.5°C;85;1019.0 mb;0.2°C;8.7 km/h;5.4 km/h;422;22 °;  0.0 mm;0.0;0.0°C;0.4°C;24.7;0;0.0;0.0 mm;0.0;0
19;11;2011;23;21;2.5°C;85;1019.0 mb;0.2°C;8.7 km/h;5.4 km/h;422;22 °;  0.0 mm;0.0;0.0°C;0.4°C;24.7;0;0.0;0.0 mm;0.0;0
19;11;2011;23;22;2.5°C;85;1019.0 mb;0.2°C;8.7 km/h;5.4 km/h;422;22 °;  0.0 mm;0.0;0.0°C;0.4°C;24.7;0;0.0;0.0 mm;0.0;0
19;11;2011;23;23;2.4°C;85;1019.0 mb;0.1°C;8.7 km/h;5.4 km/h;422;22 °;  0.0 mm;0.0;-0.1°C;0.3°C;24.7;0;0.0;0.0 mm;0.0;0
19;11;2011;23;24;2.3°C;85;1019.0 mb;0.0°C;8.7 km/h;5.4 km/h;422;22 °;  0.0 mm;0.0;-0.2°C;0.1°C;24.8;0;0.0;0.0 mm;0.0;0
22;11;2011;1;6;5.0°C;94;1015.0 mb;4.1°C;7.9 km/h;6.8 km/h;422;22 °;  0.0 mm;0.0;3.2°C;4.0°C;24.4;0;0.0;0.0 mm;0.0;0
22;11;2011;1;10;6.1°C;84;1015.0 mb;3.6°C;8.0 km/h;12.2 km/h;451;338 °;  0.0 mm;0.0;4.5°C;4.9°C;23.9;0;0.0;0.0 mm;0.0;0
22;11;2011;1;11;6.1°C;83;1015.0 mb;3.4°C;7.2 km/h;6.1 km/h;473;22 °;  0.0 mm;0.0;4.6°C;4.9°C;23.9;0;0.0;0.0 mm;0.0;0
22;11;2011;1;12;6.1°C;83;1015.0 mb;3.4°C;7.2 km/h;9.1 km/h;473;22 °;  0.0 mm;0.0;4.6°C;4.9°C;23.9;0;0.0;0.0 mm;0.0;0
22;11;2011;1;13;6.0°C;83;1015.0 mb;3.3°C;7.2 km/h;9.1 km/h;473;22 °;  0.0 mm;0.0;4.5°C;4.8°C;23.9;0;0.0;0.0 mm;0.0;0

[/size]

Ce genre de problème est typique de ce que j'ai souvent rencontré lorsqu'il y a des dates dans le log qui ne sont pas chronologiques, mais je pense avoir bien vérifié cela aussi je pense possible que le problème soit ailleurs et c'est la raison pour laquelle j'ai besoin de savoir quels sont les calculs qui peuvent planter si une valeur attendue n'est pas conforme ailleurs que dans les dates

Merci
Stéphane

[stephrac74]

Bonsoir,

Voici quelques nouvelles de mes problèmes qui semblent pour le moment partiellement résolus.

D'abord merci à Jean, qui m'a offert du temps pour décortiquer le tout. Il s'est avéré lors de nos tests, que tout à fait par hasard j'ai noté que mes problèmes d'affichage corrompu étaient résolus lorsque je changeais le nom de mon fichier log et replantait lorsque je lui redonnais son nom original "customtextout.txt"

Après avoir cherché un moment, j'ai découvert qu'il y a un genre de cache. Lorsque que l'on importe un fichier de donnée, GW crée un fichier *.MAP correspondant dans le répertoire Plugins\Plugin_1. Je pense que si ce fichier MAP ne correspond plus au fichier données, alors ça plante majestueusement. C'est par exemple le cas lorsque l'on corrige manuellement des données dans le log !

Donc lors d’une modif du fichier source, la solution consiste à supprimer le fichier MAP du répertoire ET fermer GW puis le relancer. Il recrée alors un fichier MAP qui à l’air de lui plaire d’avantage.

Je pense qu’Antoine devrait modifier la fonction "supprimer un fichier source" pour que le fichier MAP soit effacé et vidé de la mémoire. Ce serait bien.

Au passage j'en ai profité pour mettre à jour le logiciel Weather display qui avait 65 révisions de retard (j'étais au build 21 alors que le 86 vient de sortir) ! Dans l'historique des versions j'ai noté beaucoup de corrections et améliorations de la communication avec les WMR200.
Tout est donc réinstallé depuis quelques minutes, et reste à voir si mes problèmes de données corrompues dans le log sont toujours présentes, en conservant un step de 1mn. J'ai fais l'essai depuis hier avec un step de 10mn, mais clairement cela ne me convient pas. La résolution n'est pas assez fine à mon goût !

En résumé :
1. problème de corruption du log : mise à jour de Weather Display en espérant une amélioration.
2. problèmes de GW :
a) Pas de contrôle des champs date sous GW qui peuvent le faire crasher : si données corrompues nécessite de corriger le log manuellement (ou avec un outil auto)
b) Attention au fichier MAP qui à l'air d'être un cache en cas de modification manuelle du log, s'il y a une différence entre les deux, ça affiche n'importe quoi dans GW, jusqu'à le faire crasher tout simplement.

Je pense sincèrement que ces deux points devraient être améliorés lors d'une prochaine version.

A suivre donc, je reviendrais vous tenir au courant du résultats de toutes ces manip dans quelques jours.

Cordialement
et encore merci à ceux qui m'ont aidé.
Stéphane

[MAGNUS]

Bonjour à tous et merci pour votre support.

@Magnus : La dernière fois que j'ai essayé Xnet, cela ne fonctionnait pas bien. Bon, c'était en 2009 certes. Est-ce que maintenant la version est stable ?
[/code][/size]
Merci
Stéphane

Bonjour Stéphane,
Aucun problème de mon coté avec Xnet que j'utilise depuis que j'ai ma nouvelle station WMR 200 (juin 2011)
Cordialement.

[stephrac74]

merci pour l'info.

Resterait à solutionner le point concernant le capteur solaire. Je ne pourrais plus le traiter sous Weather Display, je ne pense pas que Xnet puisse le gérer, mais j'ai vu une fonction que je n'ai jamais testé encore sous GW qui permettrait de le faire. A évaluer.

En tout cas la station tourne depuis hier impeccablement avec la nouvelle version de Weather Display et un log toutes les minutes.

A suivre donc.

Cordialement
Stéphane