Soaring data in a vario: corridor sampling along a task
A note for instrument makers. Time-aware corridor sampling means the next leg's lift can be on the flight computer screen before you fly into it. Here is the shape of that integration.
This one is aimed squarely at instrument and flight-computer makers, because it is the use case the corridor endpoint was really built for and the one I most want to see someone build on.
Here is the scenario. A pilot is mid-task. The flight computer knows their position, their track, and their ground speed from GPS. What it does not know, unless you feed it, is what the air ahead is going to be doing by the time they get there. A point forecast at the current position and current time is already slightly stale for the next thermal and badly wrong for a turnpoint forty minutes downtrack. That gap is exactly what the corridor endpoint closes.
`/v1/corridor` in time-aware mode takes a launch point, a bearing, a maximum distance and a sample spacing, plus a launch time and a ground speed. For each sample point it computes when the aircraft would actually arrive - distance over ground speed - and returns the forecast valid at that hour, rolling into the next forecast hour, or even the next day, as the track runs on. So the value you get back for the point 40 km ahead is the forecast for when the pilot is predicted to be there, not for now. Feed it the live GPS position as the launch point, the current track as the bearing, and the instantaneous ground speed, and you have a forecast that walks ahead of the glider in both space and time.
What is worth surfacing on the instrument: `wstar_ms` and `cloudbase_agl_ft` along the next leg, so the pilot can see whether the lift holds or the base drops before committing to a glide; the convergence fields, so a line ahead shows up as something to aim for; and the point down-track where the day rating falls off, which is the quiet 'start heading home' signal. You do not need to render a map in a vario - a sparkline of thermal strength along the next 50 km is enough to change a decision.
On the engineering: this is a server-side integration, not a client one. Cache the corridor response and refresh it on a sensible cadence - the forecast updates four times a day, so re-pulling every few seconds buys nothing and just burns quota. Redistribution of forecast data into a shipped product needs the partner tier, which exists precisely for instrument makers and redistributors rather than the per-developer dev tier.
The honest limits, because a flight computer is exactly where overconfidence hurts: this is a 4 km forecast, not a nowcast, so it tells you the shape of the air, not the next gust. The corridor is a straight line on a bearing, so a task with turnpoints means stitching a corridor per leg. And the arrival times are only as good as the ground speed you feed it. None of that makes it less useful; it just means it belongs next to the pilot's judgement, not in front of it.
If you build instruments and any of this is interesting, get in touch - I would much rather work with you on what the firmware actually needs than guess at it. Partner tier details are on the developer page, and the corridor endpoint is documented in the API reference.