lobarbot

Bonjour, Afin d'apporter des améliorations à GraphSolWlk , je désirerais recueillir des fichiers 2015-06.wlk de stations se trouvant dans les départements suivants : Nord, Bas-Rhin et Pyrénées-Orientales. Merci d'avance et pour ne pas encombrer ce fil, je vous invite à m'écrire directement.

Bon à quoi sert ce fil de discussion à part faire du buzz ? Quant au site en question à part de la pub que trouve-on ? Pas grand chose. Ne parlons pas des prévisions ! Vouloir faire des prévisions nationales, soyons sérieux. MétéoFrance a le plus gros ordinateur de France, dispose de toutes les données météo de France et du monde et de centaines d'ingénieurs au top niveau dans leur domaine. Regardons leurs prévisions cela suffira. Contentez-vous comme la plupart d'entre nous de collecter des relevés de votre lieu et ceci avec la meilleure qualité possible, puis de les mettre en ligne. Ce sera déjà pas mal.

Bonjour, Je viens de mettre en ligne la version console, elle s'appelle GraphSolDujour . Son but est de générer le graphique d'ensoleillement du jour sans aucune intervention, pour être exécuter automatiquement par le Planificateur de tâches. Ensuite on peut envoyer par FTP le fichier du gaphique sur son site. Notez que GraphSolDujour utilise pour son fonctionnement le fichier confgraphsol.txt , le fichier de configuration de GraphSolWlk . J'ai du procéder à quelques modifications sur GraphSolWlk afin que le fichier de configuration soit complet pour GraphSolDujour . Je vous invite à télécharger la nouvelle version 1.1 qui est maintenant en ligne. N'oubliez pas de lire la doc qui se trouve avec l'application à l'adresse habituelle : http://www.meteo-gujan.org/Visiteurs

Peux-tu m'envoyer, par voie directe, tes fichiers de novembre et de décembre ? A priori, je ne vois pas pourquoi, le programme ne fonctionnerait pas.

Bonjour, Ce ne sont pas des problèmes de code. Ce ne sont que des problèmes de physique et de maths à 100%. Quand je parle de lignes ce sont des lignes de calcul. Le codage est un problème secondaire, non négligeable tout de même quand il faut manipuler des fichiers binaires et faire du calcul scientifique. Le choix du langage n'est pas anodin. Pour calculer la radiation maximale ou l'ensoleillement minimal, il faut : la latitude, la longitude et l'altitude de la station, l'heure et la date. A partir de cela, on peut faire des calculs assez corrects. En thérorie, il faudrait avoir aussi le facteur de transmission, dont j'ai pris une valeur moyenne, et l'albédo dont il faudrait aussi tenir compte, sur la neige par exemple. Même si derrière ces graphiques mes calculs sont scientifiquement rigoureux, il faut rester modeste. La précison de nos capteurs (5% annoncé par le constructeur) ne peut pas nous permettre d'obtenir une très grande justesse. Si tu t'es promené sur mon site, dans la partie Historique-> Toutes les données tu pourras voir les courbes. Si tu veux calculer les durées d'ensoleillement, je t'invite à essayer les programmes qui se trouvent dans Durée d'Ensoleillement sur :http://www.meteo-gujan.org/Visiteurs et bien sûr la fonctionnalité du calcul d'ensoleillement qui se trouve dans EditWlk La valeur de l'ensoleillement minimal n'est pas une valeur fixe, c'est un fonction, évidemment très complexe, puisqu'elle tient compte de tous ces paramètres

Dans le programme il y a plus de 300 lignes de code, qui sont dédiés aux seuls calculs du Rayonnement maximum et à l'Ensoleillement minimum : astronomie, énergie, transfert thermique, maths, etc... C'est pour cela que j'ai mis cette application en ligne, pour que tout le monde puisse en bénéficier. Je vais mettre en ligne demain une version console pour la création automatique de graphiques.

Bonjour, Je ne connais pas ce fichier Xaria, donc je ne peux répondre à ta question (en cherchant avec Google la seule référence que je trouve est dans un message que tu m'avais fait il ya 2 ans et demi lors du lancement de la première version d'EditWlk, tu en parlais au détour d'une phrase, c'est d'ailleurs suite à ton message qu'il existe depuis une version longue d' EditWlk ) La courbe d'ensoleillement dans GraphsolWlk est la courbe représentative de la fonction que j'utilise également dans les diverses applications qui se trouvent dans la rubrique "Durée d'ensoleillement" sur http://www.meteo-gujan.org/Visiteurs . J'utilise seulement les mesures de radiations de la station qui figurent dans les fichiers aaaa.-mm.wlk. Après il y a "quelques" lignes de cacul ...

Bonjour, Je viens de mettre en ligne une nouvelle application GraphsolWlk pour les utilisateurs des stations Vantage de Davis. C'est un grapheur qui génère une image comportant, pour un jour choisi : - la courbe de radiation solaire, - la courbe de l'index UV, - la courbe de radiation maximum théorique, - la courbe d'ensoleillement minimum, pour lequel il y a ensoleillement ou non. L'application est paramétrable : police, couleurs, taille, format d'image. Elle est disponible, avec sa doc, à l'adresse habituelle : http://www.meteo-gujan.org/Visiteurs Et toujours sans pub ! Dans quelques temps (?), je mettrai à disposition une application soeur en mode console, qui construira automatiquement le fichier image du jour courant, pour pouvoir alimenter vos sites "en temps réel'. (Elle est maintenant en ligne, voir 9 messages plus loin : modification du 3 décembre 2015 à 17h) N'hésitez pas à me faire part de vos remarques.

Une petite erreur de frappe m'a fait écrire Lattitude au lieu de Latitude ... Désolé, pour ceux qui auraient déjà téléchargé EditWlk et qui seraient gênés par la faute. La version actuellement en ligne a été corrigée.

Bonjour, Sur le même sujet, je viens de mettre en ligne OMM_un_mois_meteohub un utilitaire pour calculer les données aux normes OMM (températures minimales et maximales et cumul pluie) pour les utilisateurs de Meteohub sous Windows. Il se trouve, ainsi que la documentation, à l'adresse habituelle : http://www.meteo-gujan.org/Visiteurs

Bonjour, Comme promis, je viens de mettre en ligne OMM_un_mois_meteohub un utilitaire pour calculer les données aux normes OMM (températures minimales et maximales et cumul pluie) pour les utilisateurs de Meteohub sous Windows. Il se trouve, ainsi que la documentation, à l'adresse habituelle : http://www.meteo-gujan.org/Visiteurs

Bonjour, Suite à la demande de Pascaloux de Fleurie (voir le fil :Nouvelle version d'EditWlk), je viens d'écrire un utilitaire pour calculer les durées d'ensoleillement pour les utilisateurs de Meteohub. Il s'appelle ensolmois_meteohub et se trouve à l'adresse habituelle : http://www.meteo-gujan.org/Visiteurs , on y trouvera aussi une doc détaillée pour son utilisation. Ce programme a été testé par Pascaloux pour une Vantage P2. Ceux qui utilisent une autre station pourront vérifier si cela fonctionne également . Merci d'avance de vos réponses. Il est juste nécessaire que vous ayez sur votre PC avec Windows les fichiers EXPmm-aa.csv que génère Meteohub. Dans quelques temps, j'écrirai un utilitairepour calculer les données OMM.

Bonjour, La version (2.0) d'EditWlk mise en ligne ne comportait pas la boite de dialogue sur le type d'horaire lors du déroulement de la fonctionnalité Ensoleillement. Excusez-moi pour cette inattention. Si votre station est en heure légale et/ou si vous n'avez pas de capteur de radiation, vous pouvez conserver cette version. J'ai corrigé ce petit oubli. Je viens de mettre la nouvelle version (2.01) en ligne. D'autre part, j'ai quasiment terminé l'utilitaire d'ensoleillement pour METEOHUB (il me reste la doc à rédiger). Pour que ce fil de discussion reste centrer sur EditWlk, j'ouvrirai à ce moment-là un nouveau fil de discussion.

Bonjour, Je viens de recevoir ton fichier METEOHUB. Je vais essayer d'écrire un programme comme ensolmois qui se trouve sur http://www.meteo-gujan.org/Visiteurs/ , mais pour les fichiers envoyés par METEOHUB. Il n'y a plus qu'à réécrire un nouveau programme. YAPUKA ..... ;-) Petite question les noms des fichiers sont-ils toujours EXPmm_aa.csv ?

Bonjour, Peux-tu m'envoyer un (des) fichiers que tu récupères depuis METEOHUB dans un courriel perso ? Je vais voir ce que je peux faire. A+

Bonjour, Je viens de mettre en ligne la nouvelle version d'EditWlk (2.0 après la 1.3). Les nouveautés : - intégration des exports des données conformes aux règles de l'OMM, - intégration des exports des calculs d'ensoleillement, - fusion des exports des résumés du jour, - affichage systématique de messages-dialogues après chaque opération, - amélioration de la résolution, grâce au nouveau compilateur. On le trouvera à l'adresse habituelle : http://www.meteo-gujan.org/Visiteurs/ Il conviendra de bien lire la documentation (Doc__EditWlk.html ) se trouvant à la même adresse. Cette version, la plus courante, est destinée à ceux dont l'intervalle d'enregistrement est égal ou supérieur à 5 minutes. Il existe une autre version EditWlk_Long qui permet de traiter des fichiers pour lesquels la période est égale à 1 minute : cette version est beaucoup plus longue à ouvrir (5 fois plus de temps) car le nombre d'enregistrement passe de 9000 à 45000 environ ! Rappel : EditWlk est un editeur pleine page des fichiers aaaa-mm.wlk générés par Weatherlink. Il comporte en plus des fonctions d'exports et d'imports de fichiers .csv .

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. ​

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.

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.

Bonjour, Je précise que ces utilitaires ne fonctionnent que si votre station est configurée heures légales. Je vais écrire dans quelques jours une nouvelle version paramétrable qui permettra également à ceux qui sont en UTC de l'utiliser. Excusez-moi de ne pas avoir donné cette précision plus tôt.

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.

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.

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. »

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.

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.