Why this project exists

I am Justin Watts, a paraglider and software builder in Nelson, British Columbia. I read forecasts before I fly, help open and maintain flying sites, and work on the remote weather stations pilots use there. meteo grew from that life, not from a plan to start a software platform.

It began while I was rebuilding acrophobia.ca for our local free-flight club. The best forecast view we had was a static PNG from Canada RASP: useful, but impossible to interact with. I wanted a modern, web-native meteogram for my own use and my club’s, with live weather-station data beside it. Looking for one exposed the gap: everything close was paid, Europe-only, or ancient. Nothing was built for Canada, nothing was designed around a single club’s sites, and none of it was in TypeScript.

What started as one club’s need became an open-source meteorology platform for pilots, primarily free-flight paragliders. meteo by Azohra brings forecast and live observational data into tools people can use to inform a flying decision. It does not make that decision for them.

A club’s site can present the result for its own community, and its readers need no code to use it. The science, contracts, and derivations stay open to inspection underneath.

The open-forecast bet

meteo publishes the inputs, the executable derivations, and the versioned result, so more than one frontend can draw the same forecast. A reader can check the number behind a mark, or compare a profile with its archived run.

An acknowledged lineage

This work descends from Canada RASP, an extraordinary resource that has served Canadian pilots for years and to which I contribute. It kept its operations open enough for this project to learn from; meteo’s first derivations were faithful ports of its constants.

The projects now do different jobs: Canada RASP draws national maps from a standing server; meteo derives site columns, publishes versioned documents, and renders them through a reusable library that other sites can build on. In publishing open soaring forecasts at all, it also follows soaringmeteo, which has done that job for the wider free-flight world for years.

How the pieces came together

The work predates this repository. Forecast tooling first lived in the archived azohra/meteo.forecast repository, which retains the windgram releases and the original publication pipeline. The live-station library grew out of acrophobia.ca and has its own archive at azohra/meteo.station. Their commit histories and changelogs carry the release details.

Bringing them together exposed a shared foundation: units, wind-vector math, transport failures, schema tooling, and presentation rules. The forecast pipeline then moved from Python to TypeScript. Real provider fixtures and side-by-side builds established parity before the Python implementation was removed. The GRIB correctness record and JPEG 2000 correctness record explain how the byte decoders are checked against independent implementations.

The repository now separates the reusable engine from any operating instance. Operators choose their sites, schedule, storage, credentials, and public pages in their own repositories. The azohra/acrophobia-forecasts repository is the public reference instance; the compatibility guide has the current version and migration rules.

Learning in public

The platform grows as I learn enough to take on another part of the weather stack. The documentation, logbook, and labs record what I learned, where the methods came from, and what remains uncertain. I want that trail to help another pilot or builder begin further ahead.

Each published quantity has exactly one source, and a club can run any layer on infrastructure it controls. The documentation maps those boundaries, starting with Who owns each value.