Affected Elements V2: Structured NOTAMs Semantics

Affected Elements V2 is live. It is the interpretation layer that turns raw NOTAM text into structured NOTAMs: typed, filterable objects that stay faithful to the source.

The goal is simple. A NOTAM stops being a paragraph of prose and becomes a set of operational objects (aerodrome, runway, taxiway, airspace, services) with explicit effects, conditions, exceptions, and references. Severity stays accurate. Applicability stays machine-readable for profiles, alerts, and integrations.

Scoped closures stay closed. Carve-outs land in exceptions instead of buried prose. Fuel type, aircraft category, and permissions become structured fields you can filter on, not paragraphs you re-read.

Structured NOTAMs and graphical NOTAMs

Structured NOTAMs are the machine-readable shape of a notice: consistent types, effects, and semantics. Graphical NOTAMs are how that structure meets the map. Airport surface, closed taxiways and closed runways drawn in place, airspace restrictions, and context you can scan without re-parsing every line.

The same structured NOTAM payload feeds list views, filters, and API consumers. Graphical NOTAMs in products like Notam Globe build on those objects, so pilots and dispatchers see where a restriction applies on the map. Which taxiway is closed, which runway segment is out, not just what the text said.

That layer already powers filtering, alerting, API responses, and flight-level intelligence across Notamify.

Explore it live. The full walkthrough with side-by-side raw NOTAMs and JSON, covering fuel restrictions, helicopter closures, taxiway rules, and multi-element airspace cases, is on the dedicated page:

Affected Elements V2: interactive examples and semantics

From there, jump into Notamify or the NOTAM API to see how structured NOTAMs surface in the app, and how graphical NOTAMs and integrations stay aligned on the same underlying model.