meteoby AzohraOpen meteorology for mountain flying

Publish forecasts for your launches

Give @azohra/meteo.forecast your launches and it publishes their forecasts. It fetches each model's newest run, derives the soaring values for every site in your catalogue, and writes plain JSON files wherever you host them. You choose the schedule, and one CLI does the work.

Here is one of its runs, an HRDPS forecast for three sites. Browse any file in it.

data-sample/runs.json (170 B, the whole file)

{
  "schemaVersion": 1,
  "runs": {
    "hrdps-continental": {
      "referenceTime": "2026-08-12T12:00:00Z",
      "generatedAt": "2026-08-12T18:22:29.601Z"
    }
  }
}
The smallest published document, listing the newest run per model. meteo forecast runs-index writes it.

The published dataset

Give the engine a site catalogue and an output directory, and it writes this tree there. This sample is an HRDPS continental run over three test sites, served at meteo.azohra.com/data-sample/. You can curl any path in it.

meteo.azohra.com/data-sample/

  • data-sample/
  • models.json11.1 kBthe model catalogue: grid, cadence, horizon, capabilities, sunset dates
  • runs.json170 Bthe newest run per model
  • sites.json530 Bthe site catalogue this run was built from
  • site-context.json5.5 kBmeasured terrain per site: elevation, slope, aspect, relief, land cover; sources named
  • hrdps-continental/
  • manifest.json556 Bthis run: reference time, hours, sites, and what the build cost
  • sites/
  • test-hill.json10.7 kBone site document
  • test-ridge.json7.7 kB
  • test-valley.json12.6 kB
  • history/
  • test-hill/2026-08.jsonl.gz2.0 kBappend-only month archive: one gzip member per published run
  • test-hill/2026-08.index.json273 Bsidecar index: byte offset and length per member
  • test-ridge/2026-08.jsonl.gz1.6 kB
  • test-ridge/2026-08.index.json273 B
  • test-valley/2026-08.jsonl.gz2.3 kB
  • test-valley/2026-08.index.json273 B

hrdps-continental/sites/test-hill.json · excerpt, pretty-printed

{
  "schemaVersion": 2,
  "model": "hrdps-continental",
  "run": {
    "referenceTime": "2026-08-12T12:00:00Z",
    "generatedAt": "2026-08-12T18:22:29Z"
  },
  "site": {
    "id": "test-hill",
    "name": "Test Hill",
    "latitude": 49.4581,
    "longitude": -117.3956,
    "modelElevationM": 1180.8,
    "timeZone": "America/Vancouver"
  },
  "semantics": {
    "gust": "hourMax",
    "precipitation": "windowMeanRate"
  },
  "hours": [
    … 7 earlier hours …
    {
      "validAt": "2026-08-12T20:00:00Z",
      "surface": { … 12 surface quantities … },
      "levels": [ … 7 pressure levels, 875–600 hPa … ],
      "derived": {
        "boundaryLayerTopM": 2136.9,
        "thermalVelocityMps": 1.8,
        "cloudBaseM": 2362.8,
        "usableLiftTopM": 2362.8
      }
    }
  ]
}
Between the run's first and last published hour, thermalVelocityMps goes 0 → 1.8 and usableLiftTopM goes null → 2362.8. The engine derives both from the sampled fields, and the equations for every derived quantity are in Meteogram derivations. The full file is test-hill.json.

The documents total 55.6 kB. manifest.stats records how much work the build took: 717 provider downloads, 1.44 GB fetched, 106 s, 28 retries.

From model cycle to browser

Publication flow from model cycle to browser A five-stage sequence across three actors: an upstream provider publishes a forecast cycle; the forecast engine probes completeness, builds each model, and publishes once across the static-dataset boundary; the browser reads manifest and profile and exposes a torn pair as stale.
The upstream model publishes a cycle. The engine checks that the cycle is complete, builds, and publishes once. In the browser, a consistency check marks a mismatched manifest and profile as stale. Forecast architecture walks through each step.
Two transports, one job A comparison of NOAA indexed byte ranges and ECCC whole-domain streaming. Four HRRR records are located at byte offsets read from the repository fixture for 2026-08-06 12Z; ECCC builders stream one file at a time, sample configured sites, and discard the file.
NOAA models are read as .idx-indexed byte ranges. ECCC models stream one whole-domain file at a time, which the engine samples in memory and discards. Provider transports is the reference.

The CLI

Installing the package puts the meteo binary on your path, and meteo forecast build is the command that produces a dataset. The forecast documentation covers the rest of the CLI.

a first build

$ pnpm add @azohra/meteo.forecast

# plan it first: prints what it would build, fetches and writes nothing
$ pnpm exec meteo forecast build --model hrdps-continental \
    --sites ./sites.json --output ./public/data --dry-run

the build behind the sample dataset

$ mise run //forecast:build
$ node forecast/dist/cli.js forecast build --model hrdps-continental \
    --sites scenarios/catalog/sites.json \
    --output site/public/data-sample --max-steps 8

Drop --dry-run and the engine fetches the newest complete run and writes the dataset. --max-steps 8 is what holds the sample dataset to eight of the model's 48 hourly steps.

You run the engine yourself

The package is not a hosted service and ships no running pipeline. You supply the cron schedule that triggers builds, the site catalogue it builds from, and the storage bucket and credentials the documents land in. acrophobia.ca runs the reference pipeline. To set up your own, Run one model walks through the first build. The forecast documentation is the engine's full reference.