Glossary
Each term has a short definition and a link to the page that covers it in full. A few words have two or three meanings in different parts of the project, and their entries list each one.
Document
Section titled “Document”A versioned JSON file the engine publishes at a stable path. Readers accept one only through a contract guard. The kinds are profiles, manifests, catalogues, smoke, observation, and site context.
Profile
Section titled “Profile”The forecast document for one site (<model>/sites/<site>.json). The
engine writes it and renderers read it. Some pages call it a site profile
or site-forecast document; all three names mean the
same document.
Manifest
Section titled “Manifest”A small document for each model, stored beside its profiles. It records which publication this is, what it covers, and what the build fetched. Model manifest.
Model catalogue
Section titled “Model catalogue”models.json lists the available models and what each one declares: its
cadence, levels, semantics, and declared capabilities.
Model catalogue.
Site catalogue
Section titled “Site catalogue”sites.json is the list of launches you write by hand. Each entry has a
slug, name, coordinates, and timezone, and nothing about the terrain.
Configure launches.
Site context
Section titled “Site context”site-context.json holds measured facts about each site: the chosen
elevation, the surrounding terrain, and land cover. The engine measures it,
so you don’t edit it.
Site context document.
Launch and site
Section titled “Launch and site”A launch is the place you fly from. A site is that launch’s record
in the data. The docs say launch when they mean the place and site when
they mean the files (sites.json, the site block, siteSlug). Both refer
to the same thing.
One execution of a model. A published run is identified by the pair
(run.referenceTime, run.generatedAt). See
publication identity.
Reference time
Section titled “Reference time”run.referenceTime is the moment the model run starts from. Every forecast
hour counts forward from it. The docs usually write the field name.
schemaVersion and family
Section titled “schemaVersion and family”A document names its family with schemaVersion. Whether you can read
it depends on the package version you installed.
Compatibility explains the rule.
Capability
Section titled “Capability”On its own, capability means a product area: the
briefing, forecast, station, grib, and j2k capabilities, as in
meteo <capability> <command>. A declared capability is a flag in a
document’s capabilities block that says what a
model or a
station can publish.
Operator
Section titled “Operator”The person or club that runs the engine and publishes the forecasts their audience sees. The responsibility boundary lists what the operator is responsible for.
Engine and instance
Section titled “Engine and instance”The engine is the @azohra/meteo.forecast package. An instance is
one operator’s deployment of it. The project ships only the engine.
Engine and CLI.
The read side and the write side
Section titled “The read side and the write side”The write side is the engine, which derives and publishes documents.
The read side is @azohra/meteo.briefing, which works only from what
was published. The read side.
Meteogram
Section titled “Meteogram”The project’s main chart. It lines up surface forcing with the atmosphere above one model grid cell. Reading a Meteogram explains every mark.
One of the narrow rows under the Meteogram’s main panel, such as pressure, precipitation, cloud, or w*. Every strip shares the time axis and has its own scale. Reading a Meteogram.
Wind barb
Section titled “Wind barb”The wind symbol. The shaft points to where the wind comes from. A half tick counts 5, a full tick 10, and a pennant 50, in the unit printed on the chart. Reading a Meteogram.
Boundary layer
Section titled “Boundary layer”The layer of air that surface heating mixes. Its top is the dashed line
on the chart, written BL top in the docs. PBL is the depth the model
itself reports (pblHeightM, metres AGL). It answers the same question with
different physics and is drawn beside it.
Reading a Meteogram.
w* (thermal velocity)
Section titled “w* (thermal velocity)”The convective velocity scale, derived from surface heat flux and
boundary-layer depth. It is the number in the w* strip, stored as
thermalVelocityMps. It measures the energy available and does not predict
a climb rate.
Reading a Meteogram.
Usable lift
Section titled “Usable lift”The modelled height where climbing stops. It is where the strongest-core
lift profile falls to the sink threshold, or cloud base if that comes
first. It is the solid line on the chart, stored as usableLiftTopM.
Reading a Meteogram.
Sink rate
Section titled “Sink rate”The glider sink rate used to compute usable lift. The engine stores the result for 1.0 m/s, and the package can recompute the line for any other value. Pure derivations.
Serializable geometry built from one validated profile, independent of any renderer. The SVG serializer draws it, and the hit-testing queries read it. Scene graph.
Finding
Section titled “Finding”A typed statement about one forecast. It has a kind, its numbers, the
hours it refers to, and the thresholds used to compute it.
Analyze a profile.
Stored and pure derivations
Section titled “Stored and pure derivations”Stored derivations need raw model inputs, so the engine computes them and writes them into the document. Pure derivations depend only on the published document. Who owns each value explains the split.
History archive
Section titled “History archive”An append-only gzip JSONL file for each month, holding everything a dataset published that month. A small index file beside it records byte offsets. History archives.
Ingest
Section titled “Ingest”A loop a reader runs to keep its own copy of published documents. It polls
runs.json, stores each complete publication, and keeps serving the last
good copy through gaps.
Run an ingest.
Transport
Section titled “Transport”Two senses. The briefing package’s
/transport subpath loads published documents
consistently on the read side. The engine’s
provider transports are the ways it
fetches data from ECCC and NOAA on the write side.
Both senses come from the code. The station package’s
wire contract is the shape of a live
station document and its HTTP protocol. The engine’s [wire] report is
the transport summary every build prints.
Tune the wire explains how to read it.
Adapter
Section titled “Adapter”A pair of functions (meta and load) that turn one station vendor’s data
into a wire document. How adapters work.
Member
Section titled “Member”Three senses, each used on its own page:
- An ensemble member is one of a run’s perturbations (Ensemble values).
- A comparison member is one
(model, referenceTime)pair (Compare profiles). - A gzip member is one block of an archive that can be decoded on its own (History).
A station feed is the document the /feed
endpoint returns, with every configured station in one response
(Getting started). A model feed is a
provider’s published data stream
(Forecast model feeds).
Absence is never zero
Section titled “Absence is never zero”This rule applies everywhere in the project. When an optional field is absent, it means not published or not measured, and a reader must never show it as zero. Compatibility states the rule formally.