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.
