Aide sur API MétéoFrance - Documentation

[MeteoMM]

Bonjour,

 

Je cherche des informations pour utiliser l'API meteo France.

En effet j'ai un peu de mal à comprendre certains éléments :

- coverageid ?

- Subset ?

 

J'utilise un script PHP pour appeler la commande CURL. J'ai repris un certains nombre d'exemples disponibles sur ce forum, mais à chaque appel j'ai ce résultat :

Invalid Credentials. Make sure you have provided the correct security credentials

 

Pourtant j'utilise la bonne clé API.

Même chose si je lance une demande depuis le site portail-api.meteofrance.fr , j'ai systématiquement ce resultat :

 

<?xml version="1.0" encoding="UTF-8"?>
  <mw:fault xmlns:mw="http://metwork-framework.org/">
    <mw:code>868404</mw:code>
    <mw:message>Synopsis backend error</mw:message>
    <mw:description>
      <ns0:ExceptionReport xmlns:ns0="http://www.opengis.net/ows/1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.1.0" xsi:schemaLocation="http://www.opengis.net/ows/1.1 http://schemas.opengis.net/ows/1.1.0/owsAll.xsd">
        <ns0:Exception exceptionCode="NoSuchCoverage" locator="coverageId">
          <ns0:ExceptionText />
        </ns0:Exception>
      </ns0:ExceptionReport>
    </mw:description>
  </mw:fault>

 

Bien Cordialement.

[jp59]

J'utilise l'API de Météo-France en Python sans difficulté.

 

 

Tu peux me contacter en message privé pour en discuter.

[MeteoMM]

Bonjour,

 

Merci pour la proposition, mais j'ai enfin réussi à faire mes premiers test.

Toutes la substilité réside dans le bon formatage de l'argument subset !

 

 

[jp59]

Tant mieux. Je reste à ta disposition.

[MeteoMM]

Mais visiblement impossible de récupérer plus que 1 jour , et plusieurs points ( long , lat ) !

Une idée ?

[_sb]

Si tu donnais ta requête ou un bout de code (en anomysant ta clé d'API) tout en indiquant de quelle API il s'agit (obs ? radar ? prévis ? etc), se serait probablement plus simple pour te répondre.

Peut-être ceci si c'est pour des obs ? https://portail-api.meteofrance.fr/web/fr/api/DonneesPubliquesPaquetObservation

Ce topic peut aussi être utile / adaptable :

 

[MeteoMM]

Bonjour à toutes et à tous,

 

J'ai aujourd'hui une autre question relative aux API et donc le requêtage.

 

En effet certaines données sur fournis dans les résultats en cumulées, le coverageid est dans ce cas codifié avec une autre valeur , "la période".

Par exemple :

SHORT_WAVE_RADIATION_FLUX__GROUND_OR_WATER_SURFACE___2024-06-02T00.00.00Z_P1D

SHORT_WAVE_RADIATION_FLUX__GROUND_OR_WATER_SURFACE___2024-06-02T00.00.00Z_P2D

SHORT_WAVE_RADIATION_FLUX__GROUND_OR_WATER_SURFACE___2024-06-02T00.00.00Z_P3D

SHORT_WAVE_RADIATION_FLUX__GROUND_OR_WATER_SURFACE___2024-06-02T00.00.00Z_PT12H

SHORT_WAVE_RADIATION_FLUX__GROUND_OR_WATER_SURFACE___2024-06-02T00.00.00Z_PT1H

SHORT_WAVE_RADIATION_FLUX__GROUND_OR_WATER_SURFACE___2024-06-02T00.00.00Z_PT18H

....

 

Donc le P1D, P2D, P3D ( j'imagine 1 jour , 2 jour , 3 jour )

PT12H ( j'imagine 12 heures, .... )

Mais comment ajouter cet arguement dans l'appel de l'API via le SUBSET ?

 

Cordialement.

 

[_sb]

tu ne l'ajoutes pas dans le subset, il est déjà dans le coverageid.

exemple :

https://public-api.meteofrance.fr/public/arpege/1.0/wcs/MF-NWP-GLOBAL-ARPEGE-005-EURAT-WCS/GetCoverage?service=WCS&version=2.0.1&coverageid=TOTAL_PRECIPITATION__GROUND_OR_WATER_SURFACE___2024-06-15T00.00.00Z_P1D&subset=time(2024-06-16T00:00:00Z)&format=application%2Fwmo-grib

 

[MeteoMM]

Merci, mais j'ai déjà essayé. Cela ne fonctionne pas =>

NoSuchCoverage

[MeteoMM]

 <ns0:Exception exceptionCode="NoSuchCoverage" locator="PRECIP__GROUND___2024-06-19T00.00.00Z_P1D">

[_sb]

Il y a 8 heures, MeteoMM a dit :

Merci, mais j'ai déjà essayé. Cela ne fonctionne pas

 

C'est pourtant ce que j'utilise au quotidien.

 

Comme déjà dit, sans un extrait de code reproductible, c'est difficile de t'aider.

[MeteoMM]

bonjour,

 

Voici mon appel :

curl -X 'GET' \
  'https://public-api.meteofrance.fr/public/arpege/1.0/wcs/MF-NWP-GLOBAL-ARPEGE-005-EURAT-WCS/GetCoverage?service=WCS&version=2.0.1&coverageid=TOTAL_PRECIPITATION__GROUND_OR_WATER_SURFACE___2024-06-19T00.00.00Z_P1D&subset=time(2024-06-19T00:00:00Z)&subset=height(10)&subset=long(5.216000)&subset=lat(43.437667)&format=application%2Fwmo-grib' \
  -H 'accept: application/wmo-grib' \
  -H 'Authorization: Bearer keyxxxxxx'

 

Resultat :

 

<?xml version="1.0" encoding="UTF-8"?><mw:fault xmlns:mw="http://metwork-framework.org/"><mw:code>868404</mw:code><mw:message>Synopsis backend error</mw:message><mw:description><ns0:ExceptionReport xmlns:ns0="http://www.opengis.net/ows/1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.1.0" xsi:schemaLocation="http://www.opengis.net/ows/1.1 http://schemas.opengis.net/ows/1.1.0/owsAll.xsd">
    <ns0:Exception exceptionCode="NoSuchCoverage" locator="PRECIP__GROUND___2024-06-19T00.00.00Z_P1D"><ns0:ExceptionText /></ns0:Exception>

 

 

[_sb]

Le bug est corrigé ce matin côté MF, j'en ai eu confirmation aujourd'hui. Il était présent depuis le 18 juin mi-journée. Tous les coverageid de la version EURAT1S20 était désadressés.

L'url que je t'avais donné en exemple fonctionne à nouveau.

 

Dans ton exemple, mets au moins 1 jour entre la date du cycle et la date de l'échéance.

Il est également totalement inutile de mettre une hauteur, ce n'est qu'un unique champ de surface.

 

Un autre exemple fonctionnel avec un subset spatial bien que cela te retourne malgré tout la totalité du domaine :

dans ce cas, ce sera à toi de faire le redimensionnement le cas échéant (via wgrib2 ou cdo par exemple)

 

# requete :
https://public-api.meteofrance.fr/public/arpege/1.0/wcs/MF-NWP-GLOBAL-ARPEGE-005-EURAT-WCS/GetCoverage?service=WCS&version=2.0.1&coverageid=TOTAL_PRECIPITATION__GROUND_OR_WATER_SURFACE___2024-06-24T00.00.00Z_P1D&subset=time(2024-06-25T00:00:00Z)&long(5.21600)&lat(43.437667)&format=application%2Fwmo-grib


# shell :
curl -X 'GET' \
  'https://public-api.meteofrance.fr/public/arpege/1.0/wcs/MF-NWP-GLOBAL-ARPEGE-005-EURAT-WCS/GetCoverage?service=WCS&version=2.0.1&coverageid=TOTAL_PRECIPITATION__GROUND_OR_WATER_SURFACE___2024-06-24T00.00.00Z_P1D&subset=time(2024-06-25T00:00:00Z)&long(-5,5.216000)&lat(43.437667,52)&format=application%2Fwmo-grib' \
  -H 'accept: application/wmo-grib' \
  -H 'apikey: xxxxxx

 

Modifié 24 juin par _sb
ajout

[MeteoMM]

Merci en effet maintenant ça marche !

La subtilité entre la date du cycle et la date de l'échéance, m'avait échappée...

dans le coverageid il s'agit de la date du cycle. Dans le subset la date d'échéance, que l'on modifie afin d'obtenir toutes les prévisions à cette échéance.

 

 

 

[_sb]

C'est ça !

[MeteoMM]

Reste plus qu'a trouver comment récupérer les archives AROME / ARPEGE , mais visiblement aujourd'hui pas possible...

[jp59]

Il n'y a pas d'archive d'Arome ou d'Arpège en ligne en open data sur le sites de MF plus anciennes que de quelques jours.

 

Si tu cherches des archives de modèles plus longues, il faut te tourner vers, par exemple, les ré-analyses ERA5 produites par le projet européen Copernicus :

 

https://cds.climate.copernicus.eu/cdsapp#!/dataset/reanalysis-era5-single-levels?tab=overview 

 

Elle sont également accessibles par une API

 

 

[_sb]

Tu peux trouver des archives « récentes » d'AROME et ARPEGE, un mois max, ici : https://mf-models-on-aws.org/

Je garde trois semaines (pas la totalité des cycles), le stockage devient trop important sinon.

[oliver88]

Ce script curl généré par l'API Portail, ne peut pas être utilisé à partir du bash script pour télécharger?

 

curl -X 'GET' \
  'https://public-api.meteofrance.fr/public/arpege/1.0/wcs/MF-NWP-GLOBAL-ARPEGE-005-EURAT-WCS/GetCoverage?service=WCS&version=2.0.1&coverageid=CONVECTIVE_AVAILABLE_POTENTIAL_ENERGY_MAX__GROUND_OR_WATER_SURFACE___2024-07-16T06%3A00%3A00Z&subset=time%282024-07-17T18%3A00%3A00Z%29%26subset%3Dlat%2836.94524836739841%2C52.80950617989841%29%26subset%3Dlong%284.4441068397667145%2C36.17262246476672%29&format=application%2Fwmo-grib' \
  -H 'accept: application/wmo-grib' \
  -H 'apikey: XXXX'

 

Je reçois cette notification

 

Attention : Les sorties binaires peuvent perturber votre terminal. Utilisez « --output - » pour dire à 
Avertissement : curl de l'afficher quand même dans votre terminal, ou utilisez « --output 
Avertissement : <FILE> » pour l'enregistrer dans un fichier.

Modifié 16 juillet par oliver88

[_sb]

Il y a 3 heures, oliver88 a dit :

Je reçois cette notification

 

Si tu n'indiques pas à curl un fichier de sortie, la réponse sera automatiquement transmise à la sortie standard (= STDOUT), par défaut généralement le terminal dans lequel tu as lancé la commande.

Dans le cas d'un téléchargement de données binaires (et aussi le plus souvent pour des données textuelles un tant soit peu longues), il est chaudement recommandé d'indiquer une sortie autre que la sortie standard (sauf cas particulier ou pipe).

Ainsi, ajoute après wmo-grib  «  --output mon_dossier/mon_fichier_binaire.grib2 », dont le chemin peut être relatif au répertoire courant (celui dans lequel a été exécuté le script).

 

curl -X 'GET' \
  'https://public-api.meteofrance.fr/public/arpege/1.0/wcs/MF-NWP-GLOBAL-ARPEGE-005-EURAT-WCS/GetCoverage?service=WCS&version=2.0.1&coverageid=CONVECTIVE_AVAILABLE_POTENTIAL_ENERGY_MAX__GROUND_OR_WATER_SURFACE___2024-07-16T06%3A00%3A00Z&subset=time%282024-07-17T18%3A00%3A00Z%29%26subset%3Dlat%2836.94524836739841%2C52.80950617989841%29%26subset%3Dlong%284.4441068397667145%2C36.17262246476672%29&format=application%2Fwmo-grib' --output dossier/fichier.grib2 \
  -H 'accept: application/wmo-grib' \
  -H 'apikey: XXXX' 

 

[oliver88]

4 hours ago, _sb said:

 

Si tu n'indiques pas à curl un fichier de sortie, la réponse sera automatiquement transmise à la sortie standard (= STDOUT), par défaut généralement le terminal dans lequel tu as lancé la commande.

Dans le cas d'un téléchargement de données binaires (et aussi le plus souvent pour des données textuelles un tant soit peu longues), il est chaudement recommandé d'indiquer une sortie autre que la sortie standard (sauf cas particulier ou pipe).

Ainsi, ajoute après wmo-grib  «  --output mon_dossier/mon_fichier_binaire.grib2 », dont le chemin peut être relatif au répertoire courant (celui dans lequel a été exécuté le script).

 

curl -X 'GET' \
  'https://public-api.meteofrance.fr/public/arpege/1.0/wcs/MF-NWP-GLOBAL-ARPEGE-005-EURAT-WCS/GetCoverage?service=WCS&version=2.0.1&coverageid=CONVECTIVE_AVAILABLE_POTENTIAL_ENERGY_MAX__GROUND_OR_WATER_SURFACE___2024-07-16T06%3A00%3A00Z&subset=time%282024-07-17T18%3A00%3A00Z%29%26subset%3Dlat%2836.94524836739841%2C52.80950617989841%29%26subset%3Dlong%284.4441068397667145%2C36.17262246476672%29&format=application%2Fwmo-grib' --output dossier/fichier.grib2 \
  -H 'accept: application/wmo-grib' \
  -H 'apikey: XXXX' 

 

Merci. 😊Je pensais que la sortie pouvait être un problème, mais je ne savais pas comment et où l'utiliser. Le téléchargement est déjà bien meilleur

[oliver88]

Je suis le seul à obtenir souvent cette erreur? 56 Recv faulure. Lorsque j'utilise ce script.

J'ai téléchargé le run 06z il y a une heure, sans cette erreur. J'ai inséré plus de liens dans ce script. Ensuite, environ 30 minutes plus tard, j'ai essayé de télécharger des fichiers cape12z, et j'ai souvent reçu l'erreur 56 recv failure.

curl -X 'GET' \
  'https://public-api.meteofrance.fr/public/arpege/1.0/wcs/MF-NWP-GLOBAL-ARPEGE-005-EURAT-WCS/GetCoverage?service=WCS&version=2.0.1&coverageid=CONVECTIVE_AVAILABLE_POTENTIAL_ENERGY_MAX__GROUND_OR_WATER_SURFACE___2024-07-16T06%3A00%3A00Z&subset=time%282024-07-17T18%3A00%3A00Z%29%26subset%3Dlat%2836.94524836739841%2C52.80950617989841%29%26subset%3Dlong%284.4441068397667145%2C36.17262246476672%29&format=application%2Fwmo-grib' --output dossier/fichier.grib2 \
  -H 'accept: application/wmo-grib' \
  -H 'apikey: XXXX' 

[_sb]

Plusieurs causes possibles à cette interruption de la connexion par le serveur distant, avant la fin de la transaction.

Cela peut être dû à une surcharge du serveur de MF (serveur sous-dimensionné), ce qui semble arriver régulièrement. Ce peut être aussi par une malformation de la requête, par une configuration inappropriée d'un firewall, etc.

Par ailleurs, comme je l'ai déjà indiqué, supprime ce qui est inutile dans ta requête tels que les subset lat et lon. Cela diminuera les sources potentielles de dysfonctionnements.

[oliver88]

15 hours ago, _sb said:

Plusieurs causes possibles à cette interruption de la connexion par le serveur distant, avant la fin de la transaction.

Cela peut être dû à une surcharge du serveur de MF (serveur sous-dimensionné), ce qui semble arriver régulièrement. Ce peut être aussi par une malformation de la requête, par une configuration inappropriée d'un firewall, etc.

Par ailleurs, comme je l'ai déjà indiqué, supprime ce qui est inutile dans ta requête tels que les subset lat et lon. Cela diminuera les sources potentielles de dysfonctionnements.

Oui, j'ai  alors supprimé le subset lat et lon de la requête. Just i l'ancienne version du lien copié ici.