Laboratoire d'âge de la prévision de température

Ce tableau de bord montre comment une prévision de température change en vieillissant. Vous choisissez une ville, un modèle de prévision, une source de vérification (URMA ou RTMA) et un âge exact de la prévision en heures. Les graphiques comparent ensuite la prévision la plus récente, la prévision de cet âge et l'analyse de vérification sur la même chronologie.

Ce que montrent les panneaux

• Analyse, prévision récente et prévision ancienne : compare l'analyse de vérification, la prévision la plus récente et la prévision plus ancienne. C'est la façon la plus rapide de voir la dérive. Si la ligne ancienne diverge tôt, cette version ne représentait déjà plus correctement la situation.
• Erreur de prévision dans le temps : erreur signée, pour voir les biais chauds et froids plutôt que seulement la taille de l'erreur.
• MAE et biais : métriques compactes pour la fenêtre visible.
• Bande de température combinée : vue diagnostique rapide, ligne par ligne, de l'analyse, des prévisions et des erreurs.
• Matrice d'évolution par run : matrice construite depuis l'endpoint /runs qui montre les 24 prochaines heures de prévision émises par chaque run du modèle, ce qui rend la dérive court terme facile à repérer.

Comment fonctionne la logique de vieillissement

Le tableau de bord utilise les mêmes appels à l'API GribStream standard que vous utiliseriez directement. La ligne la plus récente est simplement une requête normale à /timeseries avec une large fenêtre d'horizon de prévision. La ligne ancienne est la même requête avec minLeadTime et maxLeadTime définis au même nombre exact d'heures. Cela force l'API à retourner seulement les valeurs issues de cet âge de prévision.

Requêtes GribStream représentatives

Exemple de requête d'analyse de vérification pour New York City avec URMA :

curl -X POST 'https://gribstream.com/api/v2/urma/timeseries' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer [API_TOKEN]' \
  -d '{
    "fromTime": "2026-04-07T00:00:00Z",
    "untilTime": "2026-04-11T18:00:00Z",
    "coordinates": [
      { "lat": 40.6943, "lon": -73.9249, "name": "New York - New York" }
    ],
    "variables": [
      { "name": "TMP", "level": "2 m above ground", "alias": "actual" }
    ]
  }'

Exemple de requête de prévision ancienne pour une prévision NBM âgée de 24 heures au même point :

curl -X POST 'https://gribstream.com/api/v2/nbm/timeseries' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer [API_TOKEN]' \
  -d '{
    "fromTime": "2026-04-07T00:00:00Z",
    "untilTime": "2026-04-11T18:00:00Z",
    "minLeadTime": "24h",
    "maxLeadTime": "24h",
    "coordinates": [
      { "lat": 40.6943, "lon": -73.9249, "name": "New York - New York" }
    ],
    "variables": [
      { "name": "TMP", "level": "2 m above ground", "alias": "temp" }
    ]
  }'

Exemple de requête de matrice par run montrant tous les runs du modèle qui ont prévu la fenêtre visible d'heures valides :

curl -X POST 'https://gribstream.com/api/v2/nbm/runs' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer [API_TOKEN]' \
  -d '{
    "forecastedFrom": "2026-04-07T00:00:00Z",
    "forecastedUntil": "2026-04-11T18:00:00Z",
    "minLeadTime": "1h",
    "maxLeadTime": "24h",
    "coordinates": [
      { "lat": 40.6943, "lon": -73.9249, "name": "New York - New York" }
    ],
    "variables": [
      { "name": "TMP", "level": "2 m above ground", "alias": "temp" }
    ]
  }'

Pourquoi c'est utile

• Stabilité de la prévision : si les prévisions plus anciennes restent proches du dernier cycle, le modèle se comporte de façon cohérente.
• Changements de régime : si la ligne ancienne et la ligne récente divergent fortement, le modèle réagit à un nouveau passage frontal ou à une situation qui évolue rapidement.
• Confiance opérationnelle : la matrice par run rend évident si la dernière prévision prolonge la tendance précédente ou s'il s'agit d'une correction soudaine.

Références liées : guide de démarrage · documentation OpenAPI · précision des modèles vs URMA.