Jump to content
Les Forums d'Infoclimat

Ce tchat, hébergé sur une plateforme indépendante d'Infoclimat, est géré et modéré par une équipe autonome, sans lien avec l'Association.
Un compte séparé du site et du forum d'Infoclimat est nécessaire pour s'y connecter.

Weather-Data


hermouparis
 Share

Recommended Posts

Oui Grib my bad :D

 

Ahh yes https://openskiron.org/en/icon-gribs c'est ce que j'avais trouvé sur le net, mais comme il proposé que la moitié de la France quand je regardais la zone traitée, je trouvais ça dommage car ce qui m'intéresse c'est la France entière. 

 

Super en tout cas. Je vais continué à implémenter les fonctionnalités avec Arome et Arpège, et j'intégrerais ICON, GFS..etc

 

Link to post
Share on other sites

  • Replies 65
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Bonjour ! Je viens ici vous présenter un nouveau petit projet web🙃. Après avoir badigeonné dans la farine pendant longtemps pour créer mon propre site de prévisions automatisées, je me suis

Du coup j'ai ajouté les unités ! J'ai aussi mis en route GEFS 1°, je me suis rendu compte dans le même temps que l'échéance était bloquée par défaut à 78h quel que soit votre choix... Du coup c'e

Tout devrait rentrer dans l'ordre en début d'après-midi ! Je vais mettre très prochainement un système de relance auto au run suivant en cas de plantage, je comprends pas pourquoi j'avais pas fai

Posted Images

Posted
Aubagne (13400)

OpenSkiron est orienté marine / voile donc oui forcément, ce ne sont que les façades maritimes. :) Pour GFS, je ne peux que te conseiller NOMADS (que tu connais probablement puisque tu t'intéresses à ce sujet), éventuellement en utilisant OpenDAP si c'est compatible avec ton utilisation.

Link to post
Share on other sites

Posted
Chambéry Sud (280m) -- Annecy centre (450m) pour les études

Bonjour,

 

le site risque d'être un peu lent ou parfois indisponible aujourd'hui. Je vais essayer de faire un gros travail sur AROME :

--> Ne seront plus disponibles avec arome 0.01° que la température à 2m et les précipitations (les 3 types) soit une conservation d'uniquement 4 paramètres avec cette maille.

--> Implémentation d'arome 0.025° avec mise à disposition de :

a) tous les paramètres qui étaient dispo sous arome 0.01° sauf température à 2m+précipitations

b) quelques nouveaux paramètres courants : Pmer, Tsurface, Eau nuageuse à 20m, ...

c) Paramètres en niveaux hauteur/pression : j'espère pouvoir profiter de l'espace libéré par arome 0.01° pour proposer vraiment beaucoup de paramètres en niveaux altitude, peut-être de quoi proposer des radiosondages prévus ? Je vais voir ce qui est faisable.

 

Au passage, j'ai rajouté hier l'altitude de chaque modèle : disponible dans l'API au niveau de  "geography" --> "model_altitude", en mètres bien sur !

 

Désolé pour le dérangement.

  • J'aime 1
  • Merci 1
Link to post
Share on other sites

Posted
Chambéry Sud (280m) -- Annecy centre (450m) pour les études

Bonsoir !

C'est ok pour la migration des paramètres d'AROME.

Dans la semaine qui arrive, je m'occupe de ré-intégrer ça correctement à la visualisation graphique et d'ajouter les paramètres altitude !

https://weather-data.org/api/get?model=arome-0.025&lat=45.866&lon=6.9222&token=W_000_test_000_D

 

Bye !

  • J'aime 1
Link to post
Share on other sites

Posted
Chambéry Sud (280m) -- Annecy centre (450m) pour les études

Bonjour bonjour,

 

quelques nouveaux points :

>>> possibilité d'afficher plusieurs modèles à la fois, dans ce cas là le schéma du json renvoyé est : "forecasts" --> "date" --> "param" --> "level" --> "model" --> value . Les modèles doivent être séparés dans l'url par une virgule, sans espaces supplémentaires comme dans l'exemple qui suit : https://weather-data.org/api/get?model=cosmo-d2,icon-eu,arome-0.01&lat=43.566&lon=5.9222&token=W_000_test_000_D

>>> il y a possibilité de NE PAS afficher le modèle entre le niveau d'altitude et la valeur. Ça peut être intéressant pour certains modèles dont les paramètres disponibles ne se chevauchent pas : c'est le cas pour arome 0.01° et arome 0.025° où j'ai fait en sorte de prendre une partie des données avec l'un et l'autre partie avec l'autre. Le paramètre à ajouter dans l'url est : model_disp_names=0 (la valeur est par défaut à 1 si vous ne précisez rien). Exemple ici : https://weather-data.org/api/get?model=arome-0.025,arome-0.01&lat=43.566&lon=5.9222&token=W_000_test_000_D&model_disp_names=0

 

J'ai eu quelques soucis en essayant d'intégrer les paramètres d'altitude, et j'ai toujours quelques interrogations par ailleurs :

j'ai ajouté température/humidité relative/pression sur les niveaux d'altitude entre +20m et +3000m par rapport au sol (25 niveaux en tout). Soyons honnête, ça fonctionne, et je pense même que je pourrai ajouter les paramètres en niveaux isobares histoire d'avoir quasiment de quoi fabriquer un RS, mais les performances sont moyennes... Environ 0.5s pour afficher arome avec tout ce bazar, sans doute pas loin de 1s si je mets vraiment tout ce que j'aimerai ajouter.

J'hésite donc à séparer clairement la partie "données pour RS" de la partie "données courantes", ça permettrait de conserver des performances très correctes pour l'affichage de données type prévision générale.

Bon, dans tous les cas, on reste dans des temps d'affichage encore acceptables.

 

Pour la suite, j'envisage, dans l'ordre chronologique :

>>> de faire un test avec tous les paramètres nécessaires aux radiosondages en conservant le système actuel, histoire de voir quelles performances on a lorsqu'on demande à l'API une quantité énorme de paramètres

>>> d'ajouter la possibilité de ne choisir que quelques paramètres au niveau des requêtes dans l'API (un truc du genre http://...&params=temperature,wind&levels=...)

>>> mise à jour de la doc

>>> ajouter sur la page d'accueil l'état d'avancement du stockage des modèles dans le serveur, histoire de savoir si AROME est bientôt dispo par exemple :D.

 

Bonne journée !

  • J'aime 2
Link to post
Share on other sites

Posted
Aubagne (13400)

Salut,

Les niveaux AGL sont sûrement plus pertinents que les niveaux de pression pour un usage « grand public ». Je me demande toutefois si ce grand public est intéressé par toutes les données AGL ou quelques unes seulement. De par mon expérience, je pencherais pour la seconde mais tu as la maîtrise d'œuvre ! :)

Peut-être peux-tu proposer un paramètre « défaut » qui renvoie quelques données AGL et surface qui sont caractéristiques et laisser une paramétrisation complète (surface, AGL et pressions) de ton API pour les utilisateurs qui connaissent précisément leurs besoins. Ça pourrait soulager ton serveur.

 

Petite question : est-ce que tous les process, du téléchargement des données brutes (sous quel format, question subsidiaire ?) jusqu'au site web et à la génération des réponses aux requêtes est sont sur le même serveur (hardware) ? Ou est-ce sur des machines différentes ? Ou encore des VM ?

 

Quand tu évoques les RS, tu penses fournir en JSON les données complètes pour réaliser un RS, à charger pour le requêteur de le construire ensuite ou fournir une image (ou sous un autre format) un RS que ton serveur aurait calculé en fonction de la demande (façon IC avec AROME 0.025 lors d'un clic droit, sur le principe car cela ne fonctionne plus correctement), à charge pour le requêteur de l'afficher ?

Edited by _sb
Link to post
Share on other sites

Posted
Chambéry Sud (280m) -- Annecy centre (450m) pour les études

Salut @_sb !

Effectivement les niveaux AGL (Above Ground Level, je précise car j'ai eu un doute aussi) toucheront plus de monde que certains niveaux en pression bien loin de la situation au sol.

En revanche, ces niveaux isobares restent indispensable à la fabrication d'un RS dans les règles de l'art.

 

J'ai fait le test avec vraiment tous les paramètres sauf le vent (ce qui est quand même dommage, rip les hodographes) et l'affichage de toutes ces données brutes dans l'API prend environ entre 0.6 et 0.9s ... Pas si pire !

Je pense que comme tu le dis je vais quand même séparer dans ma base de données la partie "données courantes" et la partie "données RS".

 

Oui tout se passe sur le même serveur ! Les données brutes sont téléchargées au format GRIB2. Après, si tu veux financer un second serveur y a pas de soucis:D

 

Pour ta question sur les RS je pensais faire les 2 ! Proposer les paramètres bruts (c'est déjà fonctionnel ça d'ailleurs, une petite requête avec le modèle "arome-0.025" et tu as tout ce qu'il faut) mais aussi des RS tous prêts qui se "fabriquent" au moment de la requête. Pour l'instant j'en suis à là (juste bossé dessus hier soir pour le moment) :

 

image.thumb.png.9c38579e6da022b21c33fe33a6ac00ee.png

 

Bon il manque quelques d'infos et il faudra revoir surtout les aspects graphiques mais ça commence à ressembler à quelque chose :D

Link to post
Share on other sites

Posted
Aubagne (13400)

Est-ce que les RS sont attendus par le « grand public » ?

Un RS sans les vents, c'est un peu dommage, tu perds toutes les infos de cisaillements par exemple.

J'ignore l'usage qui est fait de ton API : on imagine sans mal ce que tu proposes toi-même sur ton site mais on peut aussi avoir d'autres usages tels que des applets pour smartphone ou pour le bureau d'ordinateur mais aussi toutes sortes d'applications spécifiques dont la souplesse du format JSON est un avantage. C'est pourquoi je pense que ce serait une bonne chose pour ton projet de proposer différents environnements afin de mieux gérer les ressources de ton serveur.

 

Pour ma part, je ne suis pas du tout dans la même optique et je n'utiliserai pas ton API car ce n'est pas mon usage et que je génère déjà les données dont j'ai besoin. Cela ne m'empêche pas de trouver ton projet très intéressant et de répondre à un besoin réel. Je le suis avec intérêt. :)

Je te posais la question du hardware car sur une machine dédiée, c'est déjà très gourmand en ressources : je fais beaucoup de post-traitements multi-modèles pour obtenir des paramètres qui ne se trouvent pas ailleurs (ou sinon cher) ou avec des associations différentes ou encore pour les intégrer à des données d'observations et cela sur différents domaines plus ou moins étendus. De ce que j'ai vu (je peux me tromper), tu convertis toutes les données contenues dans le GRIB au format JSON sans ajout de données. Le gros du travail de ton serveur serait alors la génération des réponses aux requêtes (api, rs donc, ...). La conversion elle-même ne doit pas être si gourmande.. Non ?

Autant tu peux prévoir et planifier les ressources nécessaires pour être confortables avec les process de conversions, autant les requêtes sont aléatoires et vont dépendre du succès de ton projet (ce que je te souhaite !). Quand tu évoques 0.6 à 0.9s, c'est pour générer un RS en un point donné. Si tu as 100 requêtes / jour, aucun souci, si c'est par seconde ou même par minute, ...

Peut-être prévoir, si cette charge devient trop importante, de proposer des RS « préfabriqués » pour un certain nombre de nœuds de grille : ton API proposerait le choix entre un RS au point exact ou un RS au point le plus proche (par défaut) que tu aurais déjà générés et planifié en amont.

Link to post
Share on other sites

Posted
01 AMBERIEU-EN-BUGEY (255m)

Pour ma part, si je peux me permettre, ce n'est que mon avis, je préférai la première version de l'API Arome 0.01 ou il y avait la pression et vent au niveau du sol, en cherchant bien sur internet les conversions pour la pression le vent et sa direction étaient faisable.

Mais beau boulot quand même.merci

Link to post
Share on other sites

Posted
Chambéry Sud (280m) -- Annecy centre (450m) pour les études

Salut @fiflot !

Tu as toujours accès aux même données qu'avant en faisant une requête sous cette forme https://weather-data.org/api/get?model=arome-0.01,arome-0.025&lat=45.566&lon=5.9222&token=W_000_test_000_D&model_disp_names=0

 

Et il n'y a même plus la conversion à faire ! Les paramètres s'appellent directement "gust"(rafales), "wind_speed" et "wind_direction", t'as plus qu'à multiplier la vitesse par 3.6 et le tour est joué 😛

 

@_sb j'ai bien lu ton message, je réfléchis de mon côté à tout cela !

Concernant ce qui consomme le plus de ressources au niveau du serveur, il s'agit surtout de l'insertion des données en BDD. Le pire moment étant celui de l'indexation de la base en fonction de la latitude et la longitude, ça chauffe pendant un moment...

Edited by hermouparis
Link to post
Share on other sites

Posted
01 AMBERIEU-EN-BUGEY (255m)

Salut hermouparis

oui c'est bon merci, j'ai changé de lunette et j'ai retrouvé mes petits :D, merci pour les conversions, c'est du tout mâché :D 

  • Haha 1
Link to post
Share on other sites

Posted
Aubagne (13400)

Haha ! J'ai toujours évité de me coller aux BDD dans ma carrière, j'ai toujours refilé la patate chaude à d'autres équipes ! :D  Excepté sqlite que j'utilisais et qui n'est pas adapté ici, ça m'a toujours paru une usine à gaz pour optimiser les accès. Bref, je m'en éloignais le plus possible !

Gères-tu l'ensemble du domaine d'AROME ? Si oui, est-ce nécessaire (au moins dans un premier temps avec le serveur dont tu disposes actuellement) ? Réduire à un carré aux strictes dimensions de la France divise le nombre de données par 5 environ. Utiliser le landmask d'AROME pour n'avoir que les zones terrestres à l'intérieur de ce carré réduirait encore de 2, soit une division d'un ordre 10 en tout. Surtout à 0.01°  de résolution, ce n'est pas négligeable.

Autre piste : intègres-tu tous les paramètres fournis par AROME 0.01° (accessibles gratuitement j'entends) ? Un paramètre en moins, ce sont des milliers de données en moins pour ta base.

Vides-tu ta BDD à chaque run (aucun historique) ou l'incrémentes-tu à chaque sortie ?

Comment gères-tu une requête ? Tu réponds par le point de grille d'AROME le plus proche ? Tu interpoles en fonction des points de grille qui entourent la position demandée ? Une autre façon ?

Je ne t'embête pas plus ! 😛

Link to post
Share on other sites

Hello guys, 

 

Je suis aussi ce projet avec attention car je suis entrain de faire à peu près le même de mon coté. 

 

@_sb Pour ma part j'utilise du MongoDB sur un serveur dédié (je viens d'en prendre un nouveau ce matin, Xeon® D-1531, 32Go de ram, SSD). Donc je suis entrain de tout migrer aujourd'hui. 

 

Alors pour l'insertion des données comme le dit @hermouparis l'insertion dans en BDD reste le plus lourd job dans le traitement. A l'heure actuelle j'ai un serveur beaucoup moins puissant que celui que je viens de prendre et surtout en SATA ce qui réduit énormément les performances MongoDB. 

 

Le process est

 

- Récupération des fichiers GRIB2

- Extraction dans des fichiers csv par paramètre et échéance. 

- Concaténation de tous les paramètres pour par échéance dans un seul fichier CSV.

- Insertion en bulk opération échéance par échéance dans une nouvelle collection et indexation à la fin (1h10 duration mais avec un disque SATA)

 

Et il faut que je créer un process pour vérifier la disponibilité de tous les fichiers GRIB2 car là j'ai pleins d'erreurs (souvent), si les fichiers ne sont pas dispo (c'est en cours de réflexion)

 

Avant je mettais tout dans la même collection avec un TTL de 24h sur les createdAt, donc les documents de > 24h sont supprimer automatiquement, ça représenter environ 35 millions de documents. Mais j'ai changé ça, désormais  une nouvelle collection est crée pour chaque runs et chaque modèles. Ensuite j'ai un cronjob qui est nettoie les collections de plus de 24h, j'ai gardé le TTL sur les documents ce qui permet de vider la collection. 

 

Pour te donner un ordre d'idée Arome France 2.5km, c'est entre 8.5 millions et 9.5 millions de documents (10Go par run) (40 paramètres).

 

La méthode que j'utilise pour récupéré une data sur un point est

 

- Une première requête pour récupéré le point le plus proche du modèle de la coordonnées demandé

- Ensuite une deuxième requête pour récupéré l'ensemble des données du run (l'ensemble des échéances)

 

Donc c'est pas ouff et j'ai des performances médiocres, après j'ai du mal évaluer si le problème vient coté hardware ou fonctionnel car quand je fais les requêtes en brute ça prend 200/300ms .

 

A voir avec le nouveau serveur ce que ça va donner :)

Edited by Orage 33
  • J'aime 1
Link to post
Share on other sites

Posted
Aubagne (13400)

Salut !

 

Avez-vous réellement besoin des runs entiers ?

La TKE (L'énergie cinétique de turbulence) est un paramètre utile mais rentre-t-il dans le cadre de vos objectifs ?

Même question avec la pression en surface non réduite ? Les flux entrants et sortants de l'atmosphère, la brightness temperature, etc ?

Ils sont utiles mais, a priori, dans un autre contexte d'utilisation. À vous de voir bien sûr.

 

Dans la même optique, le run d'arome contient l'humidité relative, le point de rosée et l'humidité spécifique. Avez-vous besoin des trois ?

Les performances se retrouvent-elles améliorées en n'intégrant qu'un seul des trois et en calculant les deux autres au besoin ?

Ce type de calcul en un point est insignifiant alors qu'intégrer2 champs complets dans le DB bloque le CPU durant un bon moment. À voir même si, une fois calculé en un point, stocker la valeur dans la DB, ce sera toujours moins gourmand.

 

Idem avec le vent : avoir la vitesse et la direction par rapport aux composantes u et v est simple et non gourmand. Est-il nécessaire d'intégrer aussi la direction et la vitesse depuis les données AROME ?

 

Pour un RS, la tetha'e, les contenus en eau liquide et en glace à tous les niveaux, les tourbillons (absolu, relatif et potentiel fournis par AROME), etc vous sont-ils utiles ?

 

Toujours, quelle est le besoin en valeurs stratosphériques ?

 

Bref, vous voyez où je veux en venir ! :)

 

Vous pouvez réduire considérablement le nombre de données à insérer dans votre DB. Le jour où aurez un cluster de serveurs, intégrez tout ! :D

 

Il y a aussi la question que je posais précédemment : est-il opportun d'avoir le domaine entier d'AROME (pour l'instant en tout cas) ? Le réduire à un sous-domaine diminuera le nombre de données d'un facteur 2 à 3 au minimum ...

 

Encore, il y a l'assimilation qui prend du temps mais il y a aussi le vidage une fois le run qualifié d'"obsolète" qui prend du temps et du CPU, peut-être inutilement.

 

Vaut-il mieux bloquer les CPU à 90% pendant plus d'une heure ou prendre 0.01s supplémentaire à chaque requête pour une utilisation CPU de 1% ?

Une fois ces choix tranchés, il sera temps, à mon avis, de rechercher s'il y a moyen d'optimiser les transactions (et la structure de la DB le cas échéant).

 

À voir aussi s'il ne vaut mieux pas disjoindre et adjoindre les GRIB en amont, suivant votre process, plutôt que les CVS en sortie (je cite : « concaténation par paramètres ») ? À tester s'il n'est pas plus simple / moins onéreux en ressources, d'extraire les données depuis les GRIB, à la volée, sans passer par une DB, quitte à mettre un système de cache pour éviter de réextraire ce qui a déjà été extrait ? Là, ça peut influencer d'autres choses mais c'est une question à se poser.

 

Teste si la dernière échéance du paramètre à télécharger est présent ou non. Normalement, ils sont uploadés dans l'ordre chronologique. Ça évite de multiplier les connexions pour rien. Ensuite, bien sûr, tester chaque réponse si celle attendue.

 

Je trouve très bien ce que vous produisez mais si vous roulez avec une Ferrari sur laquelle vous accrochez un tank... :D

C'est cool de proposer le max de données, faut-il que le serveur assure derrière (déjà qu'il a Apache2 et différents modPhp ou python à gérer, peut-être d'autres services). Pensez à pérenniser le projet ! Les utilisateurs que vous avez n'ont pas envie que vous laissiez tomber ou que ça rame trop parce qu'investir dans un serveur suffisant reviendrait trop cher. Alors qu'en ciblant davantage les données et le domaine, vous chutez la charge du serveur sans besoin d'investir. :)

 

Quelques pistes de réflexions ...

  • J'aime 1
Link to post
Share on other sites

Posted
Chambéry Sud (280m) -- Annecy centre (450m) pour les études

Salut à tous les deux !

J'avoue que je ne pensais pas rentrer dans des considérations aussi techniques sur ce sujet qui était plus voué à simplement présenter le projet et connaitre les attentes d'éventuels utilisateurs. M'enfin ça ne me dérange pas du tout, bien au contraire 😁

 

Concernant le process, il est effectivement plus ou moins similaire à ce qu'a évoqué @Orage 33, avec pas mal de petites subtilités ou différences tout de même.

 

Concernant l'optimisation, il est clair que le travail de réduction du domaine spatial est indispensable. Il était réduit jusque-là pour tous les modèles à, au maximum, le domaine d'arome25. Il est désormais depuis quelques jours réduit à un rectangle encore plus petit intégrant uniquement la France Métropolitaine. Je dis "au maximum" car certains modèles comme cosmo n'ont pas un domaine qui couvre l'ensemble du rectangle déjà évoqué.

 

Les paramètres proposés (et donc inscrits en BDD) étaient, jusqu'à ce que je m'intéresse aux données d'altitude, restreints à des variables très courantes (TMP à 2m, RH à 2m,...). Concernant le vent à 10m, j'ai effectivement fait le choix de proposer les variables de vitesse et de direction au détriment des composantes u et v, comme la plupart du temps l'utilisateur se contente tout à fait de la vitesse et de la direction, on shunte l'étape de conversion et ça arrange beaucoup de monde ; libre à chacun d'utiliser la méthode pour retrouver u et v si vraiment cela est nécessaire !

 

Concernant les paramètres d'altitude, je récupère uniquement température, humidité relative, u, v, pression (pour les données AGL), géopotentiel(pour les données en niveau pression). Cela suffit a priori pour produire quelque chose de correct en effectuant des petits calculs au moment du traitement de la requête utilisateur.

 

La suppression des anciennes données est peu couteuse en ressources serveur, ce n'est pas vraiment un point à optimiser ou quoi.

 

Maintenant que les champs en niveaux d'altitude sont dispo, je vais (en + d'ajouter un moyen de connaitre l'état d'avancement des modèles sur le serveur qcomme je l'avais déjà évoqué) essayer de faire un petit "mode montagne" avec ajustement des températures en fonction de l'altitude réelle du point, détermination de la limite pluie-neige, qualité de la neige, possibilité de pluies verglaçantes...

A défaut d'intéresser beaucoup de monde, ça me servira au moins à moi 😂😂

Edited by hermouparis
  • J'aime 2
  • Merci 1
Link to post
Share on other sites

  • 2 months later...

Salut @hermouparis,

Cela fait des mois que je recherche une API de ce type et au moment où je m'étais décidé à la faire moi même, je tombe sur ton post ! Ca à l'air vraiment parfait pour mon projet et je vais me lancer dans quelques tests pour voir comment implémenter tes données.

J'aurais bien sur quelques questions par la suite, mais avant tout, est-ce que tu pourrais remettre la documentation en ligne ?
Je voulais aussi savoir où est-ce que je dois m'adresser pour avoir une clé/token ?

Dans tous les cas, un grand merci pour ton job, ça va m'être très utile.
 

Link to post
Share on other sites

Posted
Chambéry Sud (280m) -- Annecy centre (450m) pour les études

Salut !

Ravi de savoir que tu es intéressé ! Je viens de voir qu'effectivement la doc est hs, ainsi que les données d'arome...

Je suis en vacances sans doute jusqu'au 20/25 juillet, ensuite je m'occupe de réparer tout cela, c'est promis !

A+

  • Merci 1
Link to post
Share on other sites

Super cool merci.

Pour la doc, je m'en suis sorti, il y a un json qui traine qui contient toutes les informations importantes.
J'ai pas encore commencé l'intégration des données sur mon projet, mais de ce que j'ai vu, il y a presque tout ce que j'ai besoin.
Un grand merci pour ton projet et surtout pour le partage !

Link to post
Share on other sites

Posted
Chambéry Sud (280m) -- Annecy centre (450m) pour les études

Salut salut !

Effectivement il y a le json mais c'est des données qui sont ensuite lues par un petit programme pour afficher une "belle" documentation, tu as dû t'arracher les cheveux à lire cela directement haha. En fait j'avais juste pas passé en https le lien... Bref, la doc est à nouveau disponible en suivant ce lien : https://weather-data.org/api/doc

Je m'occupe aujourd'hui de tout remettre bien en route, concernant les modèles disponibles et la "plateforme" d'état des modèles,  ce soir ça devrait être bon !

Edited by hermouparis
Link to post
Share on other sites

Je n’ai pas de conseils particuliers à te donner ni de questions, mais si tu peux avoir sur ton radiosondage l’aire correspondant à la CAPE (depuis la surface, par exemple), celle correspondant à la CIN, et en plus de cela un hodographe, je serais très heureux! Continue à faire du bon boulot!

Link to post
Share on other sites

Posted
Chambéry Sud (280m) -- Annecy centre (450m) pour les études
Le 24/07/2020 à 22:18, Smercz a dit :

Je n’ai pas de conseils particuliers à te donner ni de questions, mais si tu peux avoir sur ton radiosondage l’aire correspondant à la CAPE (depuis la surface, par exemple), celle correspondant à la CIN, et en plus de cela un hodographe, je serais très heureux! Continue à faire du bon boulot!

 

Salut ! C'est super pratique avec le module Python que j'utilise je crois que je peux faire tout cela en quelques lignes de code. Mais pour l'instant, j'ai stoppé le développement de cette partie car ça nécessitait un peu trop de ressources au niveau du serveur... Je vais peut-être me pencher à nouveau là-dessus avant la fin des vacances !

 

Il y a 23 heures, libertykite a dit :

Salut @hermouparis,

Une petite question (J'en aurais d'autres), la valeur de tes Gust est en m/s-1. Mais si je dis pas de bétises les m/s-1 c'est pour des vecteurs et il faudrait les valeurs U et V, comme pour le vent moyen d'ailleurs. Du coup les gusts sont en m/s ?

 

Hello, je ne suis pas sûr de bien comprendre. De mon côté toutes les valeurs de vent et les normes des vecteurs U et V sont bien en m.s^(-1) = m/s (ce sont les mêmes unités, juste la "convention" utilisée est différente). Si tu as toujours un soucis à ce niveau, n'hésite pas à me reposer la question (peut-être en joignant une capture d'écran de ce qui te semble erroné?).

 

A+

Link to post
Share on other sites

  • 1 month later...

Salut @hermouparis,

Deux petites requêtes :

- Pourrais-tu réactiver le modèle GFS-0.25 ? Il me semble qu'il est planté...

- Est-ce qu'il serait possible d'agrandir un poil la zone de tes datas de façon à couvrir l'entier de la Suisse ? J'essaye de faire une requête dans l'est de la Suisse, mais la zone ne semble pas couverte.

Dans tous les cas, pour le moment c'est top !

 

EDIT 4/9/2020 :
Bon au final plus besoin du modèle GFS, je me suis débrouillé avec le icon-eu
Sinon, toujours intéressé pour l'agrandissement de la zone des prévisions à l'entier de la Suisse 🙂

 

 

Edited by libertykite
Link to post
Share on other sites

Posted
Chambéry Sud (280m) -- Annecy centre (450m) pour les études

Salut ! Désolé j'ai été un peu moins actif sur le projet ces derniers temps.

Je regarderai demain pour GFS. Pour l'agrandissement de la zone, pas de soucis pour tous les modèles excepté arome à 0.01°... Je ferai des tests pour voir si ça ne ralentit pas trop le fonctionnement du système sur ce dernier modèle. Dans tous les cas je reposterai ici pour te prévenir de ce que j'ai choisi de faire !

A+

Link to post
Share on other sites

  • 2 months later...

Salut @hermouparis,

Ton api semble plantée, une simple requête du genre https://weather-data.org/api/get?model=icon-eu&lat=46.40&lon=2.12&token=W_000_test_000_D

ne retourne plus rien 😞.

 

 

Est-ce que tu envisagerais de mettre ton code en open source ? Ça me permettrais de faire tourner une version sur mon serveur pour avoir plus la main dessus 🙂
Sinon, je crois que je vais devoir me plonger dedans, mais j'avais d'autres projets d'abord !!

A tout plus

Fred

 

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...