pour la courbe de prévision de
l'historique kzs on utilise arome HD sur l'api de
open-meteo.
on a constaté que nos mesures étaient généralement 10 à 20% au dessus du modèle, ce qui n'est pas logique surtout avec une station à 5m de haut au lien des 10m du modèle.
en fait dans la requête il faut faire attention aux coordonnées. exemple:
https://open-meteo.com/en/docs?hourly=w ... _france_hdhttps://open-meteo.com/en/docs?hourly=w ... _france_hdà l'heure où j'écris ces lignes, il y a une différence de 5% pour seulement 0.02° de longitude.
on peut noter aussi une différence d'altitude de 2m, ce qui n'a pas vraiment de sens, sauf à considérer le fond du lac et non sa surface.
concernant l'heure de disponibilité du modèle, on peut trouver les infos ici:
https://api.open-meteo.com/data/meteofr ... /meta.jsonil y a un run toutes les 3h, mais la durée de calcul est de +/- 4h. sur windguru c'est l'heure de début du run qui est affichée, en UTC. donc celui de 9h UTC est disponible à 9+2+4=15h légale, celui de 12h le sera à 18h, etc. à quelques minutes près bien sur.
en tout cas je ne constate pas de différé significatif sur windguru. cependant il peut y a voir aussi le cache, du navigateur, de l'hébergeur, etc.
exemple à l'heure où j'écris ces lignes:
il est 17h30, c'est le run de 9h00UTC (11h00L) qui est sur windguru, le fichier date de 15h23L, ce qui est cohérent avec la dispo annoncée par open-meteo (15h14mn45s).
les directives de cache (de windguru) indiquent d'un coté un expiration à 18h23L mais d'un autre coté 10800s de validité (3h) soit jusqu'à 17h30+3h00=20h30. dans le cas de firefox c'est cette dernière valeur qui est prioritaire, il va donc vous présenter le run de 9hUTC au moins deux heures de trop...
pour avoir un update hors cache il faut actualiser la page par CTRL+F5 (sur pc en tout cas). ça ne présume en rien cependant du comportement des caches intermédiaires (cloudflare en l’occurrence).