nico123456

Au passage, le service premium, c'est 640k€ de pertes annuelles. Pour palier aux faiblesses du service gratuit pour les pauvres. Maintenant, imaginez qu'au lieu de privilégier une élite avec ce premium qui coûte cher, on réaffectait ces 640k€ pour renforcer les 103k€ de budget du service gratuit... Je m'arrête là dans mon lobbying. Pas certain qu'IC soit l'endroit approprié pour ça. Merci à tous les rebelles dans les équipes internes de MF qui m'envoient régulièrement ces documents. Si vous en avez d'autres, n'hésitez pas à me les transférer :

Mais pour moi, la position de MF, avec son opendata premium payant est complètement contraire à l'esprit de la directive : D'ailleurs, devinez qui est le plus gros consommateur du service premium ?...

Le but est de mettre en place un système pour mettre en commun nos demandes. Au lieu d'avoir 1000 personnes qui doivent faire 40 000 requêtes chacune, on va en distribuer 40 par personne puis mettre en commun les résultats. J'ai déjà un service sur un principe similaire pour les modèles : mf-models-on-aws.org , qui permet d'éviter leur service premium et qui distribue aujourd'hui le double de ce que distribue le serveur officiel MF. Quand vous allez sur IC, windy, windguru ou d'autres, les données AROME viennent de chez moi. Le système pourra marcher avec toutes les API de Météo-France. Dans un premier temps pour les modèles, mais on pourra ensuite étendre aux autres API si besoin. Après, il faudra que ça tienne du coté de chez MF pour servir ces 1000 personnes en simultané, mais ils n'ont pas trop le choix. La directive exige "une qualité de service compatible avec les modalités de réutilisation". Dans le cas de la météo, difficile d'argumenter que le temps réel n'est pas nécessaire. Si ça ne passe pas, on ira voir le tribunal administratif pour faire augmenter le tuyau. La directive : https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX:32023R0138

Quelles sont les plages de vitesse à prévoir pour la transmission ? Quelle est l'unité que vous privilégiez ? km/h ou m/s ? (savoir sur quoi arrondir) Est-ce que - pour votre usage - une résolution au km/h près suffit ou alors il faut des décimales ou du 0.1 m/s ? Ça donne quoi sur les autres stations que vous utilisez ? L'OMM dit 0.5 m/s Pour les rafales, l'OMM dit qu'on doit transmettre entre 0 et 150m/s à 0.1m/s près. Mais je pense que c'est du délire. À cette vitesse (540km/h), ça fait bien longtemps que l'anémomètre se sera envolé. MeteoWind se revendique conforme OMM, mais ne peut transmettre que jusqu'à 51,1 m/s (184km/h, encodage sur 9 bits, source) alors que l'OMM demande 75. Quid du Davis ou des autres stations que vous utilisez ? Il y a-t-il beaucoup d'applications qui ont réellement besoin d'être 100% OMM ? Je suis un peu perdu entre la théorie et la pratique. Exigences OMM ci-dessous :

Attention ! Une fréquence d’échantillonnage plus élevée ne veut pas dire une vitesse instantanée plus juste, contrairement aux rafales. Pour la majorité des anémomètres mécaniques, le calcul de la vitesse se fait en comptant des impulsions. Voici un schéma : Les impulsions sont représentées par les traits noirs et les périodes sont représentées par les rectangles. Avec une période d’échantillonnage courte, le problème est que les impulsions ne tombent pas toujours pile poil au bon moment. On peut en avoir juste avant le début de la période ou juste après. Les périodes en bleu font toutes la même durée. Idem pour les rouges. Pour la bleue, en échantillonnant sur 0,25s, on mesure une vitesse de 3 ou 5,9 km/h, selon comment ça tombe. Pour la rouge, on a entre 0 et 3 km/h. Ici, je l'illustre pour une vitesse faible, mais le problème est valable également pour des vitesses plus élevées. Le nombre d'impulsions correspondant à la vitesse réelle est donc +/- une impulsion. Ça crée un pourcentage d'erreur qui peut être non négligeable. Sur cet exemple du Windbird, à 0.25s, je peux encore avoir près de 10% d'erreur à 43km/h et je dois monter jusqu'à 81km/h pour n'avoir plus que 5% d'erreur. C'est quasi 5x pire sur le Davis, avec 3.621km / h / impulsion vs 0.735 km / h / impulsion pour le Windbird. Pour ces anémomètres mécaniques, ça n'a donc pas de sens de sortir une valeur absolue à 0.25s. La situation est différente sur les anémomètres qui utilisent d'autres principes de mesure, comme les ultrasons ou les pitots. C'est pourquoi on moyenne sur plusieurs périodes. Plus le nombre de périodes est grand, plus l'approximation numérique baisse. L'OMM estime qu'une moyenne sur 3 secondes représente bien les rafales pour la majorité des anémomètres mécaniques. Mais alors pourquoi échantillonner sur 0.25s ? Car les 3 secondes correspondent à une moyenne glissante. Si on avait des périodes de 3 secondes fixes, on pourrait n'avoir que le début ou la fin de la rafale. Avec la moyenne glissante, on est assuré d'avoir la mesure centrée sur le maximum de la rafale. -- Par rapport à la meteowind, on aura l'avantage non négligeable du prix (divisé par deux !), de la simplicité d'installation et du GPS antivol. Et dans notre expérience, l'hélice résiste mieux. On a eu beaucoup de casse en montagne avec les coupelles meteowind, alors qu'on a du vendre max 10 hélices de pioupiou en 7 ans - souvent cassées suite à une chute. Notre partenaire vend une MeteoWind version Sigfox, intégrée au réseau openwindmap : https://www.nextmodelrc.com/fr/anemometre-connecte-balise-meteo/9405-mwi-c05-sf-rc1-meteowind-iot-pro-sigfox-openwindmap-1-an-abonnement.html -- Pour ce qui est des traitements statistiques dérivés (mini, moyen, max), on peut les calculer à postériori pour aggréger les périodes. 10 minutes, 1 heure, 24h.... Mais effectivement, ça sera intéressant de pouvoir sortir ça directement sur l'API. Je vais l'implémenter. C'est la preuve que votre point de vue "météorologique" a un apport pour le projet 👍 Par contre, on ne peut pas le faire pour la déviation standard, car le calcul nécessite d'avoir tous les échantillons. Je la proposerai donc sur 10 minutes comme les recommandations OMM.

API. Qui sera probablement similaire à l'existante : https://developers.pioupiou.fr/

> Après, les données peuvent être générer comment ? C'est à dire ? Je n'ai pas compris la question

Oui, si on a les rafales sur 5 minutes, on les a aussi sur 10. Il suffit de prendre la valeur max des deux périodes. Idem pour la moyenne, on peut l'avoir sur 10 minutes.

Pas le même produit que dans l'autre sujet sur ce forum. Il me semble pertinent de poser la question ici, auprès de la communauté infoclimat. Ça permet de croiser les regards.

Nous visons un marché international. Le nom en anglais est donc justifié.

Bonjour Je suis dans la dernière ligne droite pour sortir l'anémomètre Windbird : Son prédécesseur, le Pioupiou, était destiné uniquement au sport. Donc je n'avais pas vraiment pris en compte les besoins des professionnels et passionnés de météorologie. Corrigeons-ça ! Pour l'instant, voici ce que j'imagine pour chaque transmission : - Vitesse vent moyen sur 5 minutes (2 périodes). Sampling 4Hz - Direction moyenne sur 5 minutes (2 périodes). 0-360°, résolution 1°. Sampling 1Hz - Rafale max sur 5 minutes (2 périodes). Sampling 4Hz moyenné sur 3 secondes. - Vent min sur 5 minutes (2 périodes). Sampling 4Hz moyenné sur 3 secondes. - Température moyenne sur 10 minutes (mesure non conforme car pas d'abri, mais qui reste intéressante). Sampling 1Hz. - Deviation standard de la vitesse, de la direction et de la température sur 10 minutes. Sampling 1Hz Quelles sont les spécifications que vous attendez d'un anémomètre "idéal" ? Quelles sont les spécifications requises pour le réseau StatIC et pour une utilisation "pro" ? Quelles sont les plages de mesure et la résolution qui vous semblent appropriés ?

Ou alors, je pourrais avoir une station principale chez moi et une station "backup" dans un lieu géographique plus éloigné (01 / 38 / 69 / 73 / 74). Ça compenserait les pertes dues à des paraboles plus petites, tout en renforçant la disponibilité. Ça serait alors + léger : - Parabole de 1m80 - Un ordinateur - Utilisation de la fibre optique de la maison - Pas de starlink, pas d'onduleur, pas de groupe elec

Je ne sais pas où vous en êtes sur le sujet mais, pour info... openwindmap.org projette de proposer des abonnements LoRa pour les stations météo. Comme on le fait déjà avec Sigfox, pour les arduinos, pioupious, meteowind et autres : https://forum.openwindmap.org/topic/325/renouvellement-des-abonnements une opportunité de mutualiser ?

Bonjour J'étudie la possibilité d'installer une station de réception Eumetsat, pour utilisation sur mon site, et possible partage de l'accès avec la communauté IC (selon licence des données). L'ensemble sera constitué de : - une parabole de 2.4m de diamètre, orientée +/- vers le sud. - un ou deux ordinateurs - un onduleur - un petit groupe électrogène - un accès fibre optique grand public - un starlink en backup Étant à l'étroit dans mon jardin, je cherche quelqu'un qui pourrait héberger ça. Évidemment, je prendrai en charge tous les frais, y compris l'électricité consommée. Il y aurait-il parmi vous un volontaire, dans la zone Grenoble / Chambéry / Albertville ?

Bonjour Je cherche quelqu'un capable de rédiger un bulletin d'analyse météo fin pour le parapente et les autres activités aériennes. Pays à couvrir en priorité : France, Allemagne, Suisse Freelance ou CDD de 6 mois en temps partiel (contrat étudiant possible). Je suis joignable au 09 72 61 41 16 Nicolas