Why we compute active runways instead of just reporting wind

Ask an aviation API for wind at an airport and you'll get three numbers: direction, speed, sometimes a gust value. That's the raw measurement, and it's correct, and it's also not the question most people building on top of it actually have.

The question is usually: which runway is in use right now? A flight tracker wants to draw the right approach path. A dispatcher's tool wants to flag a tailwind departure before it becomes a problem. A training app wants to quiz a student on runway selection against real, current conditions. None of those are served by a raw wind report — they're served by an answer.

So /v1/airports/{icao_code}/runways/active computes one.

The method

Every runway at an airport has a true heading — 28L points at roughly 284°, its reciprocal 10R at roughly 104°. Given current wind direction and speed, we compare the wind vector against every runway heading on file and pick the runway (or runway pair, for airports that use them independently for arrivals and departures) whose heading is closest to a headwind.

That comparison alone isn't enough to be useful, though, which is why the response isn't just "runway 28L." It's:

{
  "ident": "28L",
  "is_arrival": true,
  "is_departure": true,
  "confidence": 0.94
}

Three things matter here beyond the runway identifier itself:

is_arrival / is_departure are separate flags. Busy airports often run different runways for arrivals and departures at the same time — reporting a single "active runway" would be actively wrong for one of those two use cases half the time.

confidence is not decoration. Runway selection isn't always a clean call. Calm wind, a runway configuration change in progress, or a crosswind that's genuinely ambiguous between two usable runways all lower the confidence score. A dashboard showing a big obvious "28L" and a debugging tool deciding whether to trust that number for an automated action have different tolerances for ambiguity — the score lets you set your own threshold instead of us silently picking one for you.

Why this is worth building

The value is in not making every developer who needs "which runway" re-derive it from "what's the wind" themselves, badly, once per project.

That's the shape of most of what we build: take data that's technically public but operationally annoying to turn into an answer, and return the answer.