All posts
Dev Log·5 min read

You can now see the forecast, not just fetch it

Convek has always been an API - JSON in, JSON out. The new interactive map and route examples at /explore render the same WRF fields as a proper soaring map: thermals, cloudbase, day rating, convergence, and animated surface wind over a real basemap.

Convek has always been an API first. You send a request, you get structured JSON back - `wstar_ms`, `cloudbase_agl_ft`, `day_rating`, `surface_wind_speed_ms`, the whole soaring field set. That is the right shape for the people building on it: app developers, instrument makers, club webmasters. It is a terrible shape for anyone who just wants to glance at whether tomorrow looks any good. Numbers in a terminal do not tell you where the convergence line sits or how the wind funnels down a valley. So I built the thing that does: an interactive map.

The new explore examples render the exact same fields the API returns, but as a map you can actually read. The forecast map shows a colour field - thermal strength, cloudbase, day rating, or convergence - across the whole GB domain, with a time slider running through the day and a live wind-flow animation on top. Click any point and you get the real modelled values from the nearest sample - the same soaring fields a `/v1/site` call returns. That is the point: every pixel on the map is backed by real model data, not a stock image.

The wind is the part I am happiest with. It is not decoration - it is the model's surface `u` and `v` components, drawn as thousands of particles advected through the real vector field, coloured by speed, with wind-direction arrows over the top. Fair warning on resolution: this preview samples the domain on a coarse grid, so it shows the broad flow rather than every valley. The fine terrain channelling that makes a soaring map sing lives in the full 4 km model, and it comes through once the live tiles ship at native resolution. Even coarse, the moving wind over a dark basemap reads the way a soaring map should.

The route example is the corridor endpoint made visible. It walks a glider along a realistic Shropshire task and, crucially, re-rates the thermal field to the forecast hour the pilot actually reaches each turnpoint - so the map you see at the third turn is the 13:00 forecast, not the launch-time one. That time-aware corridor sampling is the same thing `/v1/corridor` does with `time_aware: true`; the map just makes it obvious why it matters on a long flight.

Now the honest part, because this blog does not do launch gloss. The maps currently run on an archived snapshot, not a live feed. It is real WRF output - a genuine GB run sampled right across the domain through a full soaring day - but it is one fixed day, clearly labelled as archived on every view. The reason is deliberate: the grid endpoint that produces these fields is a paid developer tier, and shipping a public map that hammers it, or that leaks an API key into the browser, would be the wrong way round. The live version fetches pre-rendered field tiles and wind grids from cache storage, published once per model cycle, so the public map costs nothing per view and never touches a customer's quota. That pipeline is the next job; the snapshot proves the rendering while it gets built.

None of this changes the product. Convek is still an API - the map is a window onto it, not a replacement for it. If you are building something, the soaring weather API is where the same data lives as JSON, and a free API key gets you started. If you just want to see what the model thinks of the day, the map is finally there to look at.

Written by JadeMore in Dev Log