Elias.MM Posté(e) 16 janvier Partager Posté(e) 16 janvier Bonjour la communauté IC, Je découvre le site et le forum suite à l'ouverture des données MétéoFrance par API. J'ai vu le fil https://forums.infoclimat.fr/f/topic/59033-ouverture-des-données-par-météo-france-au-010124/, qui montre que vous êtes bien bien mobilisés sur ce nouvel accès ! Pour ma part, simple utilisateur/consommateur de données, je suis à la recherche d'aide pour utiliser leurs nouvelles API ( https://portail-api.meteofrance.fr/web/fr ). A mon avis,c'est le boulot de MF (en théorie) de fournir cette assistance et documentation, mais en attendant qu'elle arrive, je suis sûr que certain-es par ici ont commencé à explorer, voire manipulent déjà bien ces interfaces. => Du coup, je vous propose de rédiger une petite documentation publique et partageable, si quelqu'un ayant un peu plus d'expertise veut bien m'aider à aboutir sur ma recherche (que je considère "simple", mais c'est subjectif ^.^) NotoModo : j'espère avoir visé la bonne catégorie, mais bien entendu vous pouvez m'indiquer où le déplacer si nécessaire. Merci d'avance pour votre aide ou vos pointeurs vers le bon forum/la bonne documentation ! Mon besoin Pour un projet citoyen de "flexibilité électrique" (Projet ELFE), je dois prévoir une production électrique d'éolienne dans les prochaines 24h : j'ai donc besoin d'obtenir la prévision de vitesse de vent à un endroit précis en France métropolitaine. Idéalement, ma chaîne d'info doit me permettre de sortir un fichier .csv avec les timestamp et la valeur souhaitée, sur un horizon de 24h. Ma compréhension de la situation L'information est présente dans le modèle AROME 0,01°, par exemple. Je sais faire des requête API POST/GET sur d'autres API, j'ai un environnement de test avec Node-RED. J'ai créé un compte sur https://portail-api.meteofrance.fr/web/fr, ,je me suis abonné à l'API AROME, et j'ai déroulé les requêtes d'essai proposées par le site web. Là où je bloque Impossible d'avoir une documentation claire sur comment restreindre la donnée en amplitude géographique. Le endpoint GetCapabilities donne le composant à cibler, par exemple WIND_SPEED__SPECIFIC_HEIGHT_LEVEL_ABOVE_GROUND___2024-01-16T09.00.00Z Ensuite, l'endpoint DescribeCoverage permet de comprendre ce qu'il y aura dans la réponse, notamment l'enveloppe max en 4 dimensions (espace + temps). Mais l'endpoint GetCoverage n'est pas assez documenté : il me répond Parameter subset is mandatory : only a 2D coverage can be downloaded Et je ne sais pas comment écrire ce subset, je tombe toujours en erreur (il faut découper au moins en height et time). Le lien indiqué dans DescribeCoverage, http://meteofrance.fr/def/crs/4DLongLatHeightTime n'est pas actif (ca renvoie vers la page d'accueil MF) Ca demande 5 ans d'études en météorologie, ou bien j'ai ma chance ? Ensuite, je me pencherai sur l'interprétation du fichier Grib (si j'arrive bien à l'obtenir), pour retenir uniquement la valeur qui m'intéresse Voilà, j'ai au moins posé ma réflexion, j'espère trouver preneur ! Merci de m'avoir lu ! Lien à poster Partager sur d’autres sites More sharing options...
Elias.MM Posté(e) 16 janvier Auteur Partager Posté(e) 16 janvier Ok donc le souci de requête est que le "subset" doit être précisé plusieurs fois : "subset=height=100&subset=time=$timestamp" (d'après : https://docs.geoserver.geo-solutions.it/edu/en/wcs/get.html ) MAIS l'interface de test sur le site MF ne le permet pas, du coup on ne peut pas générer de requête correcte. En passant sur la requête curl, agrémentée d'un second "&subset=", je finis par avoir un fichier grib. => Déjà, documenter cette étape permettra à davantage de monde de s'en servir, non ? Et maintenant, partons en chasse d'un convertisseur grib > csv. https://en.wikipedia.org/wiki/GRIB#Software Lequel vous préférez, par ici ? Lien à poster Partager sur d’autres sites More sharing options...
Julien L Posté(e) 18 janvier Partager Posté(e) 18 janvier Bonjour Elias, Je rencontre également des problèmes pour utiliser cette API. La documentaiton semble tout simplement inexistante. Si des personnes plus aguéries sur le forum pouvaient nous expliquer clairement l'utilisation, ce serait super. J'ai cependant peut-être une solution à ta question pour ton convertisseur grib -> csv. Tu peux regarder ecCodes de ECMWF avec la fonction grib_ls qui fera a priori ce que tu demandes: https://confluence.ecmwf.int/display/ECC/grib_ls Lien à poster Partager sur d’autres sites More sharing options...
Elias.MM Posté(e) 18 janvier Auteur Partager Posté(e) 18 janvier Merci Julien. Comme je disais, à force de creuser, j'ai trouvé la "bonne formulation". Voilà donc ma requête pour GetCoverage : curl -X 'GET' 'https://public-api.meteofrance.fr/public/arome/1.0/wcs/MF-NWP-HIGHRES-AROME-001-FRANCE-WCS/GetCoverage?service=WCS&version=2.0.1&coverageid=WIND_SPEED__SPECIFIC_HEIGHT_LEVEL_ABOVE_GROUND___2024-01-16T09.00.00Z&subset=height=100&subset=time(2024-01-16T10%3A00%3A00Z)&subset=long(-2.22)&subset=lat(47.62)&format=application%2Fwmo-grib' -H 'accept: application/octet-stream' -H 'apikey: $KEY$ --output test.grib On voit les subset en temps et en hauteur, ainsi qu'en latitude/longitude. En espérant que ça t'aide ! J'ai effectivement fini par installer ecCodes, le process est complexe (make avec options, compilation...), mais ça fonctionne très bien. 3 remarques sur la réponse reçue de l'API : J'ai l'impression que le subset "height" ne fonctionne pas. Je demande 100m mais j'ai "heigth=10m" dans la réponse, et si je mets d'autres valeurs ça renvoie une erreur. à creuser... Je n'ai pas réussi à demander plusieurs pas de temps, l'API renvoie une erreur du style "il faut slice par le temps" Si, en demandant un subset lon/lat très fin, le résultat de la requête est un point unique, l'API ne retourne pas un fichier binaire GRIB mais un fichier XML avec un seul point (qui n'est donc pas lisible par ecCodes). Ca devrait être documenté, à moins que ça soit dans le standard GRIB ? Lien à poster Partager sur d’autres sites More sharing options...
theperk Posté(e) 18 janvier Partager Posté(e) 18 janvier (modifié) Je ne m'y connais pas encore avec les modèles de prévision ni avec les fichiers Grib (donc j'espère que quelqu'un pourra m'aider 😉 ) Par contre, l'appel de cet API fonctionne, et comme tu l'as expliqué, il faut réécrire à chaque fois le subset (sauf pour le premier paramètre si tu utilises directement l'API sur le site de Meteo France) : Donc dans la case subset de l'API du site, il faut par exemple écrire : height(10)&subset=time(2024-01-18T12:00:00Z)&subset=long(-2.22)&subset=lat(47.62) et ça fonctionne si on choisit bien le format 'application/wmo-grib' : mais avec l'exemple proposé ça renvoit un fichier XML (plutôt que grib ) avec la valeur pour la hauteur et le point spécifié en latitude et longitude. Et ça ne renvoit rien directement si on utilise le format image/tiff, puisque ça renvoit en réalité le même fichier, qui n'est qu'un fichier XML et pas une image (normal puisque ça ne renvoit la prévision que d'un seul point) Ma question : comment faire pour obtenir la prévision sur une grille entière, et non pas pour un seul point comme dans l'exemple cité ? EDIT : Ok, je crois que j'ai compris pour la différence entre le point seul et la grille, c'est l'utilisation du point décimal ou de la virgule : subset=long(-2.22)&subset=lat(47.62) -> un seul point de coord : 2°22 Ouest et 47°62 Nord subset=long(-2,22)&subset=lat(47,62) -> grille de : 2° Ouest à 22° Est et de 47° Nord à 62°Nord Par contre je pense que c'est normal que ça ne produise pas de véritable fichier image/tiff car ce format n'est pas dans le DescribeCoverage. Et sinon, dans ce coverageID précis, les seules hauteurs autorisées sont : 10, 20, 50 et 100 (on le voit dans la réponse si jamais on tente une autre valeur, et de toute façon c'est précisé dans son DescribeCoverage) Modifié 18 janvier par theperk 1 Lien à poster Partager sur d’autres sites More sharing options...
Elias.MM Posté(e) 10 avril Auteur Partager Posté(e) 10 avril Et on continue à creuser les usages possibles de ces API, et notamment la limite de slicer par le temps. Voilà mon message envoyé ce jour, si vous avez des idées... Citation Bonjour, Je cherche à utiliser vos API pour obtenir la prévision de vent AROME à 100m sur un parc éolien citoyen. J'aimerais obtenir l'ensemble des points temporels de prévision pour 1 run sur 1 point géographique donné. Voilà ma requête actuelle : https://public-api.meteofrance.fr/public/arome/1.0/wcs/MF-NWP-HIGHRES-AROME-001-FRANCE-WCS/GetCoverage?service=WCS&version=2.0.1&coverageid=WIND_SPEED__SPECIFIC_HEIGHT_LEVEL_ABOVE_GROUND___2024-04-10T09.00.00Z&subset=height(100)%26subset%3Dlong(-2.22)%26subset%3Dlat(47.62)&format=application%2Fwmo-grib La réponse est une erreur : "Slicing on time is mandatory : only a 2D coverage can be downloaded" Et la requête fonctionne en ajoutant "&subset=time(2024-04-10T22:00:00Z)", ce qui m'oblige à construire et lancer 52 requêtes pour obtenir toutes les données. => Je veux bien obtenir un coverage 2D, mais dont une des dimensions est le temps. Est-ce faisable ? Et si non quelle serait la meilleure façon d'obtenir ces données sans consommer trop de ressources ? Merci pour votre réponse, Lien à poster Partager sur d’autres sites More sharing options...
_sb Posté(e) 11 avril Aubagne (13400) Partager Posté(e) 11 avril Le 18/01/2024 à 10:08, Elias.MM a dit : &subset=height=100& Le 18/01/2024 à 10:08, Elias.MM a dit : J'ai l'impression que le subset "height" ne fonctionne pas. Je demande 100m mais j'ai "heigth=10m" dans la réponse, et si je mets d'autres valeurs ça renvoie une erreur. à creuser... 100m, pas 100, sinon le serveur te renvoie en effet le premier niveau disponible, ici 10m. curl -X 'GET' 'https://public-api.meteofrance.fr/public/arome/1.0/wcs/MF-NWP-HIGHRES-AROME-001-FRANCE-WCS/GetCoverage?service=WCS&version=2.0.1&coverageid=WIND_SPEED__SPECIFIC_HEIGHT_LEVEL_ABOVE_GROUND___2024-04-11T09.00.00Z&subset=height=100m&subset=time(2024-04-12T05:00:00Z)&subset=long(-2.22)&subset=lat(47.62)&format=application%2Fwmo-grib' -H 'accept: application/octet-stream' -H 'apikey:... Pour un point en particulier, résultat en XML-like. <?xml version="1.0" encoding="UTF-8"?> <gmlcov:ReferenceableGridCoverage xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xmlns:xlink='http://www.w3.org/1999/xlink' xmlns:gml='http://www.opengis.net/gml/3.2' xmlns='http://www.opengis.net/gml/3.2' xmlns:swe='http://www.opengis.net/swe/2.0' xmlns:gmlcov='http://www.opengis.net/gmlcov/1.0' xmlns:om='http://www.opengis.net/om/2.0' xsi:schemaLocation=' http://www.opengis.net/gml/3.2 http://schemas.opengis.net/gml/3.2.1/gml.xsd http://www.opengis.net/swe/2.0 http://schemas.opengis.net/sweCommon/2.0/swe.xsd http://www.opengis.net/gmlcov/1.0 http://schemas.opengis.net/gmlcov/1.0/gmlcovAll.xsd http://www.opengis.net/om/2.0 http://schemas.opengis.net/om/2.0/observation.xsd' gml:id="FF__HEIGHT___2024-04-11T09.00.00Z"> <domainSet> <Point gml:id="GridPoint1" srsName="CRS:84" > <pos>-2.22 47.62</pos> </Point> </domainSet> <gml:rangeSet> <gml:DataBlock> <gml:rangeParameters/> <gml:tupleList> 3.55486383091 </gml:tupleList> </gml:DataBlock> </gml:rangeSet> <gmlcov:rangeType> <swe:DataRecord> <swe:field name="FF__HEIGHT"/> </swe:DataRecord> </gmlcov:rangeType> <gmlcov:metadata> <gmlcov:Extension> <om:NamedValue> <om:name xlink:title="time" /> <om:value>2024-04-12T05:00:00Z</om:value> </om:NamedValue> <om:NamedValue> <om:name xlink:title="height" /> <om:value>100</om:value> </om:NamedValue> </gmlcov:Extension> </gmlcov:metadata> </gmlcov:ReferenceableGridCoverage> curl -X 'GET' 'https://public-api.meteofrance.fr/public/arome/1.0/wcs/MF-NWP-HIGHRES-AROME-001-FRANCE-WCS/GetCoverage?service=WCS&version=2.0.1&coverageid=WIND_SPEED__SPECIFIC_HEIGHT_LEVEL_ABOVE_GROUND___2024-04-11T09.00.00Z&subset=height=100m&subset=time(2024-04-12T05:00:00Z)&subset=long(-2,22)&subset=lat(47,62)&format=application%2Fwmo-grib' -H 'accept: application/octet-stream' -H 'apikey:... Pour un domaine donné (, au lieu de ., comme indiqué plus haut). Résultat en GRIB2 sans compression. Sauf erreur de ma part, MF a continué à suivre l'esprit INSPIRE, seule la 2D est gérée : une surface ou un point (lon / lat) sur une dimension unique de temps et de hauteur. Inscrire une variation temporelle revient à avoir un set 3D, donc non géré. N requêtes sont requises. -> Il est nécessaire d'avoir une hauteur (ou un niveau de pression) [1 dimension], une échéance [1 dimension], une longitude, une latitude [2 dimensions]. Lien à poster Partager sur d’autres sites More sharing options...
Elias.MM Posté(e) 17 avril Auteur Partager Posté(e) 17 avril (modifié) Le 11/04/2024 à 21:41, _sb a dit : 100m, pas 100, sinon le serveur te renvoie en effet le premier niveau disponible, ici 10m. Bien pensé, mais c'est bien une valeur en mètres qui est attendue. Si je mets "100m" ou '100m" dans la requête, j'ai une erreur 404, et si je mets 10 20 ou 50 j'ai des valeurs cohérentes (vitesse de vent croissante avec l'altitude). Et la meta-data de la réponse "FF__HEIGHT" est cohérente à la valeur dans la requête. La réponse de l'API "describeCoverage" pour le même coverageID indique bien Citation <gmlrgrid:generalGridAxis> <gmlrgrid:GeneralGridAxis> <gmlrgrid:offsetVector srsDimension="4" axisLabels="lat long height time" uomLabels="deg deg m s" srsName="http://meteofrance.fr/def/crs/4DLatLongHeightTime">0.0 0.0 1.0 0.0</gmlrgrid:offsetVector> <gmlrgrid:coefficients>10 20 50 100</gmlrgrid:coefficients> <gmlrgrid:gridAxesSpanned>height</gmlrgrid:gridAxesSpanned> <gmlrgrid:sequenceRule axisOrder="+1">Linear</gmlrgrid:sequenceRule> </gmlrgrid:GeneralGridAxis> </gmlrgrid:generalGridAxis> Merci cependant pour les réponses/éclairages ! Pour moi prendre un seul point permettait de ramener la question en 2D (conceptuellement) mais je comprends que c'est pas l'esprit de cet outil. Donc allons-y pour N requêtes, heureusement on a droit à 50/minute ! Et puis c'est pas comme si la prévision était actualisée toutes les minutes (je crois que c'est 3h l'intervalle de publication AROME ?), donc ça va le faire. Modifié 17 avril par Elias.MM conseil erroné après test Lien à poster Partager sur d’autres sites More sharing options...
_sb Posté(e) 17 avril Aubagne (13400) Partager Posté(e) 17 avril La syntaxe est pourtant bonne. Tu dois avoir une autre erreur quelque part. Quelle est ta requête ? Voici les miennes selon ce que tu avais donné plus haut : curl -X 'GET' 'https://public-api.meteofrance.fr/public/arome/1.0/wcs/MF-NWP-HIGHRES-AROME-001-FRANCE-WCS/GetCoverage?service=WCS&version=2.0.1&coverageid=WIND_SPEED__SPECIFIC_HEIGHT_LEVEL_ABOVE_GROUND___2024-04-17T09.00.00Z&subset=height=100m&subset=time(2024-04-18T05:00:00Z)&subset=long(-2.22)&subset=lat(47.62)&format=application%2Fwmo-grib' -H 'accept: application/octet-stream' -H 'apikey:*********' --output testLoc.grib fournit ce fichier XML : <?xml version="1.0" encoding="UTF-8"?> <gmlcov:ReferenceableGridCoverage xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xmlns:xlink='http://www.w3.org/1999/xlink' xmlns:gml='http://www.opengis.net/gml/3.2' xmlns='http://www.opengis.net/gml/3.2' xmlns:swe='http://www.opengis.net/swe/2.0' xmlns:gmlcov='http://www.opengis.net/gmlcov/1.0' xmlns:om='http://www.opengis.net/om/2.0' xsi:schemaLocation=' http://www.opengis.net/gml/3.2 http://schemas.opengis.net/gml/3.2.1/gml.xsd http://www.opengis.net/swe/2.0 http://schemas.opengis.net/sweCommon/2.0/swe.xsd http://www.opengis.net/gmlcov/1.0 http://schemas.opengis.net/gmlcov/1.0/gmlcovAll.xsd http://www.opengis.net/om/2.0 http://schemas.opengis.net/om/2.0/observation.xsd' gml:id="FF__HEIGHT___2024-04-17T09.00.00Z"> <domainSet> <Point gml:id="GridPoint1" srsName="CRS:84" > <pos>-2.22 47.62</pos> </Point> </domainSet> <gml:rangeSet> <gml:DataBlock> <gml:rangeParameters/> <gml:tupleList> 7.20903273418 </gml:tupleList> </gml:DataBlock> </gml:rangeSet> <gmlcov:rangeType> <swe:DataRecord> <swe:field name="FF__HEIGHT"/> </swe:DataRecord> </gmlcov:rangeType> <gmlcov:metadata> <gmlcov:Extension> <om:NamedValue> <om:name xlink:title="time" /> <om:value>2024-04-18T05:00:00Z</om:value> </om:NamedValue> <om:NamedValue> <om:name xlink:title="height" /> <om:value>100</om:value> </om:NamedValue> </gmlcov:Extension> </gmlcov:metadata> </gmlcov:ReferenceableGridCoverage> En 2D, l'obtention du binaire pour une altitude de 100m ne pose pas de problème non plus (même requête, avec des virgules pour séparer les longitudes / latitudes) curl -X 'GET' 'https://public-api.meteofrance.fr/public/arome/1.0/wcs/MF-NWP-HIGHRES-AROME-001-FRANCE-WCS/GetCoverage?service=WCS&version=2.0.1&coverageid=WIND_SPEED__SPECIFIC_HEIGHT_LEVEL_ABOVE_GROUND___2024-04-17T09.00.00Z&subset=height=100m&subset=time(2024-04-18T05:00:00Z)&subset=long(-2,22)&subset=lat(47,62)&format=application%2Fwmo-grib' -H 'accept: application/octet-stream' -H 'apikey:*********' --output testLoc.grib Résultat : $ cdo infon ./test.grib -1 : Date Time Level Gridsize Miss : Minimum Mean Maximum : Parameter name 1 : 2024-04-18 05:00:00 100 1514641 113356 : 0.0036853 5.4292 13.793 : 100si cdo infon: Processed 1514641 values from 1 variable over 1 timestep [0.13s 99MB] Binaire : test.grib Lien à poster Partager sur d’autres sites More sharing options...
Elias.MM Posté(e) 18 avril Auteur Partager Posté(e) 18 avril Merci Stéphane pour ton aide ! Tu réagissais à mon post de janvier mais j'ai pu faire marcher ma requête entre temps (désolé si ça n'était pas clair). J'arrive bien à la même réponse que celle que tu partages, on est raccord. Dans mon dernier message, je disais que j'étais en recherche d'un 2D temporel, sans succès. Mais j'ai des données, effectivement en grib sur des surfaces, on en xml simple sur un point. Nouveau souci : j'ai des erreurs intermittentes lors de mes requêtes "Server error 137.129.43.104:443 - ECONNREFUSED" => Est-ce que c'est une histoire de quotas ? Je m'attendrais plutôt à un code 429, d'après la documentation. Là, ça sent le serveur en rade. D'autres avis ? Lien à poster Partager sur d’autres sites More sharing options...
eric eric Posté(e) 27 avril Partager Posté(e) 27 avril (modifié) Le 18/04/2024 à 15:59, Elias.MM a dit : Merci Stéphane pour ton aide ! Tu réagissais à mon post de janvier mais j'ai pu faire marcher ma requête entre temps (désolé si ça n'était pas clair). J'arrive bien à la même réponse que celle que tu partages, on est raccord. Dans mon dernier message, je disais que j'étais en recherche d'un 2D temporel, sans succès. Mais j'ai des données, effectivement en grib sur des surfaces, on en xml simple sur un point. Nouveau souci : j'ai des erreurs intermittentes lors de mes requêtes "Server error 137.129.43.104:443 - ECONNREFUSED" => Est-ce que c'est une histoire de quotas ? Je m'attendrais plutôt à un code 429, d'après la documentation. Là, ça sent le serveur en rade. D'autres avis ? Pareil des tonnes de "connexion refused/connexion reset error" depuis janvier. Ce n'est pas les quotas on a bien des 429 pour le quota. Avant janvier pas de pb avec cette api...Quelqun a t'il une explication ? le support inspire ne repond pas ... Modifié 27 avril par eric eric Lien à poster Partager sur d’autres sites More sharing options...
Messages recommandés
Créer un compte ou se connecter pour commenter
Vous devez être membre afin de pouvoir déposer un commentaire
Créer un compte
Créez un compte sur notre communauté. C’est facile !
Créer un nouveau compteSe connecter
Vous avez déjà un compte ? Connectez-vous ici.
Connectez-vous maintenant