OpenMeteoData - données météo libres et gratuites pour tous

[Pan]

.

Modifié 26 août 2023 par Pansa

[Sebaas]

Et concrètement, en considérant que les données du réseau StatIC soient le plus fiabilisées possibles (on a encore du travail à mener en terme de détection de pannes et d'incohérence flagrante, même si ça a bien progressé), quels seraient la démarche et les outils nécessaires pour assimiler les observations desdites stations dans un WRF "maison"?

[nico parapente]

quels seraient la démarche et les outils nécessaires pour assimiler les observations desdites stations dans un WRF "maison"?

Nous on peut mettre du calcul à disposition pour des tests.

[Pan]

.

Modifié 26 août 2023 par Pansa

[Synok]

Et concrètement, en considérant que les données du réseau StatIC soient le plus fiabilisées possibles (on a encore du travail à mener en terme de détection de pannes et d'incohérence flagrante, même si ça a bien progressé), quels seraient la démarche et les outils nécessaires pour assimiler les observations desdites stations dans un WRF "maison"?

Il faut traduire les données dans un format compatible avec les entrées de WRF et puis c'est a peu près tout (si j'ose dire).

Les "vraies données" d'observations sont un + génial !

Il faut écrire tous les scriptes d'importation et de traitements; mais c'est loin d’être infaisable.

Pour que les données d'un réseau d'observation soient fiables, il faut que l'horodatage soit juste aussi et qu'elles sortent au même rythme.. il n'y a pas que les données elles-mêmes a vérifier. Les PC de mesures doivent donc avoir l'heure unifiée et correcte.

[Pan]

.

Modifié 26 août 2023 par Pansa

[Synok]

Ben, tu choisi de faire du traitement sans moyennes a 15min, soit a 1/2 heure soit a 1h ou plus.

Comme il est plus sage de faire des moyennes entre station pour niveler les erreurs plutôt que de faire des moyennes par station; si tu as du 15 min sur un groupe ou du 1h sur un autre, c'est pas la même chose. C'est plus simple quand elles sortent toutes du 15 min ou du 1h...

Après, c'est sur que dans ton modèle tu peux lui rentrer aussi bien des 15 min que de 1h.. voir même de temps en temps des sondages ou des relevés radars (MesoNH). Mais les aberrations de mesures seront plus difficiles a détecter, et tes runs peuvent s'en trouver biaisés.

Mélanger les données c'est bien, quand tu ne met pas en doute la fiabilité des dites données, ce qui n'est pas le cas avec un réseau amateur.

[Pan]

.

Modifié 26 août 2023 par Pansa

[nico parapente]

Après on doit pouvoir voir si une station présente constamment un décalage avec les prévis du modèle.

Le tout est de savoir s'il s'agit d'un microclimat ou d'un problème de mesure.

[Synok]

Moyenner des observations qui sont distantes de plusieurs centaines de km pour réduire les erreurs ça n'a pas beaucoup de sens.

Ah, oui, c'est vrais que vous travaillez avec des maille très larges... Je suis plus habitué aux campagnes de mesures plus réduites géographiquement. Et vous ne faites pas de la turbulence ou autres donc les capteurs a 5 min, 15 minutes.. effectivement ça ne le fait pas.

[Sebaas]

En l’occurrence, sur les quelques 200 StatIC, on récupère et traite les données toutes les 10 min pour un grand nombre d'entre elles (celles en WeatherLinkIP et celles qui uploadent directement sur notre serveur via un ftp dédié). Pour les autres, toutes les demi-heure - à voir ce que l'on peut faire... mais c'est tentant /emoticons/smile@2x.png 2x" width="20" height="20">

[Synok]

Je veux bien participer dans la mesure de mes compétences (scriptes en Perl, administration Linux), un peu plus de mon CV en MP.

[nico parapente]

Qui veut recevoir des cartes de visites pour parler du projet ?

envoyez moi vos adresses via MP.

[moissinac]

Une partie des discussions de ce fil doit être prolongé. Ils sont une des bases de la pérennité d'OpenMeteoData: s'assurer qu'on ne reste pas complètement tributaire des données américaines pour l'initialisation du modèle. Cela implique d'avoir d'autres sources de données et les procédures qui permettent de les exploiter dans WRF: Météo-France, divers réseaux de balise...

Cela serait donc super qu'en parallèle de la version opérationnelle qui se met en place, il y ait des volontaires pour tout préparer pour l'injection progressive de nouvelles données dans le modèle.

[nico parapente]

Nous proposons de former un "conseil scientifique" au sein de l'association.

Celui-ci aura pour mission :

• d'assurer la cohérence scientifique du projet
• de discuter d'une manière ouverte sur les points techniques du projet (réglages du modèle, assimilation, transformation des données...)
• d'émettre des critiques ou des recommandations
• de publier sur la mise à disposition ou les nouveaux usages des données

Il ne s'agit pas la de créer une grosse organisation ingérable, mais simplement de fédérer les personnes qualifiés voulant s'impliquer dans le projet.Aussi, avec un "conseil scientifique", nous serons beaucoup plus crédible auprès du public et de nos interlocuteurs. Cela permettra de nouer plus facilement des relations avec des entreprises ou des universités.

Je pense que ça sera un levier non négligeable dans le développement du projet, et que ça pourra émuler d'autres scientifiques à se joindre au projet.

Et pour finir, après les thématiques de l'open-source et de l'open-data, cela fera une formidable expérience d'open-science : la science collaborative et ouverte, non contrainte par une institution.

Cela ne veut pas forcément dire y passer beaucoup de temps.

Si pour des raisons diverses vous ne pouvez pas associer publiquement votre nom à un tel projet, ça n'est pas un problème. Vous pourrez figurer dans le conseil sous un pseudonyme, accompagné de vos qualifications.

Encore une fois, je suis totalement à votre disposition pour en discuter.

[nico parapente]

Si jamais il y a des geeks parisien dans le coins, vour pourrez venir découvrir le projet à la conf Data Tuesday du 26 février

http://data-tuesday.com/