ATIS is messier than METAR — here's how we normalize it

If you've worked with aviation weather data before, METAR probably didn't scare you. It's terse, but it's a genuinely stable format — decades of prior art, consistent field ordering, and enough existing parsers that decoding one is a solved problem.

ATIS is a different animal. It's not a data format at all — it's a recording of a controller (or a text-to-speech system) reading a scripted broadcast, transcribed into text that's meant to be read, not parsed. Field order varies by facility. Phrasing varies by controller. The same piece of information — say, a closed runway — might show up in the NOTAM section, the remarks section, or folded into the runway line, depending on who wrote that particular broadcast.

What we actually extract

/v1/airports/{icao_code}/atis returns the raw broadcast text — because sometimes you genuinely want to read it the way a pilot would — alongside a structured breakdown:

{
  "wind_direction": 250,
  "wind_speed_kt": 12,
  "visibility_sm": 10.0,
  "clouds": [{ "cover": "SCT", "base_ft": 4000 }],
  "runways": [
    { "ident": "31L", "runway_type": "ARR", "is_approach": true, "is_departure": false },
    { "ident": "31R", "runway_type": "DEP", "is_approach": false, "is_departure": true }
  ],
  "notams": ["RWY 04L/22R CLSD"],
  "remarks": ["BIRD ACTV"]
}

The runway breakdown is the part that took the most iteration. Unlike a METAR, which never mentions runways at all, an ATIS broadcast frequently tells you exactly which runways are being used for arrivals and which for departures — often the two are different, and often more than one runway is active in each direction at busy fields. Reporting a single "active runway" field would throw away real information the broadcast actually contains, so we return the full set with each one tagged for arrival, departure, or both.

NOTAMs and remarks get pulled into their own lists rather than left buried in a wall of text, specifically so you can scan for "is anything currently closed or unusual" without re-parsing prose every time.

Why not just wind, like METAR?

Because ATIS often already answers the question our active runway computation exists to answer for airports that don't broadcast ATIS. Where a live broadcast is available, it usually reflects an actual controller decision — which can diverge from pure wind math during a runway change, noise abatement procedure, or traffic flow adjustment. That's exactly why our active-runway endpoint prefers ATIS as a source when it's available and only falls back to computing from wind when it isn't.

The honest limitation

ATIS coverage today is US-only, because that's where a live, continuously updated feed of broadcasts exists in a form we can parse. Outside the US, our /wind endpoint falls back to METAR automatically, so you still get an answer — just without the extra structure ATIS provides where it exists. Expanding that coverage is a matter of finding equivalent feeds elsewhere, not a limitation of the parsing approach itself.