Temperature Forecast Aging Lab

This dashboard shows how a temperature forecast changes as it ages. You pick a city, a forecast model, an actuals source (URMA or RTMA), and an exact forecast age in hours. The charts then compare the freshest forecast, the aged forecast, and the verifying actuals on the same timeline.

What the panels show

• Actual vs freshest vs aged forecast: the fastest way to see drift. If the aged line diverges early, that forecast vintage was already off regime.
• Forecast error over time: signed error, so you can see warm and cold bias rather than just miss size.
• Mean absolute error and bias: compact summary metrics for the visible window.
• Joined temperature strip: a quick row-wise diagnostic view of actuals, forecasts, and errors.
• Run evolution lattice: a matrix built from the /runs endpoint that shows the next 24 forecast hours emitted by each run, making short-range forecast drift easy to spot.

How the aging logic works

The dashboard uses the same standard GribStream API calls you would use directly. The freshest line is just a normal /timeseries request with a wide lead-time window. The aged line is the same request with minLeadTime and maxLeadTime set to the exact same number of hours. That forces the API to return only forecast values coming from that forecast age.

Representative GribStream requests

Example actuals request for New York City using 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" }
    ]
  }'

Example aged forecast request for a 24-hour-old NBM forecast at the same 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" }
    ]
  }'

Example run-lattice request showing all model runs that forecast the visible valid-time window:

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" }
    ]
  }'

Why this is useful

• Forecast stability: if older forecasts agree closely with the latest run, the model is behaving consistently.
• Regime changes: if the aged line and fresh line diverge sharply, the model is reacting to a new frontal passage or a rapidly evolving setup.
• Operational trust: the run lattice makes it obvious whether the latest forecast is a continuation of the previous trend or a sudden correction.

Related references: Quickstart · OpenAPI docs · Model accuracy vs URMA.