This experimental API provides information about temporary changes to components of, or hazards in the National Airspace System (NAS), which are published by FAA via the SWIM Cloud Distribution Service (SCDS) in the form of Digital NOTAMs, as part of the AIM FNS product.
The API delivers a select set of the Digital NOTAM Event information, together with a geometry to indicate where the event is taking place. The NOTAMs can be encoded as GeoJSON, JSON-FG, or FlatGeobuf. For this API, a geometry is considered an essential component of any event and events with no geometry are not shared via the API.
The current API includes NOTAMs collected since 2021-07-12.
This API is developed as part of OGC Testbed-18. The API is a work-in-progress and subject to change. This API provides the data according to the OGC API - Features - Part 1: Core standard and provides limited filtering capabilities (see below). Another API on the same data provides additional filtering capabilities: Federal Notice to Airmen System (FNS) - Filter API.
Simple filtering of the data can be achieved using query parameters.
According to the Digital NOTAM Event Specification (version 1, chapter 5.3), the geographical data included in NOTAM messages is less mathematical and more descriptive. Although the DNOTAM Event Specification contains rules for converting GML encoded geometries into NOTAM text, the NOTAMs received from SCDS rarely seem to contain such information. The correct way to compute a default geometry for each NOTAM would be to define according production rules for each NOTAM scenario supported by AIM FNS. Since such rules could not be found, this API takes a pragmatic approach for computing default geometries for NOTAMs.
NOTE: On https://notams.aim.faa.gov - section Documentation - a number of documents for FNS NOTAM scenarios can be downloaded. However, it is unclear how the scenario identifier from digital NOTAM events can be matched against the scenarios. Furthermore, rules for computing a default geometry for the scenarios could not be found.
NOTAM messages delivered by SCDS often (but not always) contain time slices - mostly snapshots, but also tempdeltas - of aeronautical features affected by the event. Note that the snapshots typically are incomplete, i.e. values are only given for a select subset of the feature properties (even though according to the AIXM Temporality Model, a snapshot should contain values for all feature properties). In any case, some of these time slices contain geometry data. The data harvester implemented for this API collects all (elevated) points, curves, and surfaces contained in the aeronautical features that are in the same message as the event feature. The geometries of highest dimension are selected and, if there are multiple, merged (creating a union geometry). If, for example, the geometries gathered from the aeronautical features contained points as well as surfaces, then only the surfaces would be selected. If the NOTAM message does not contain such geometries, then the ICAO location of the event is inspected. The ICAO location is part of an Event extension. It is not provided for all events, but if it has a value, then an attempt is made to match it against the 'locationIndicatorICAO' property of AirportHeliport features contained in the 28 day NASR subscription airport baseline data. If a match exists, then the Airport Reference Point (ARP) is used as default geometry for the event. If no match can be found via the ICAO location, the NOTAM message is dismissed by the harvester. For airspace related NOTAMs - indicated by the message header 'us_gov_dot_faa_aim_fns_nds_NOTAMKeyword' having value 'AIRSPACE' - a different approach was taken. In this case, the airspace designator - which appears to be encoded in the event location - is matched against the IDENT field of airspaces contained in shapefiles which are also part of the 28 day NASR subscription files. If a match is found, the default geometry is set to the airspace shape stored in the shapefile. Otherwise, the NOTAM message is dismissed by the harvester.
Note that this pragmatic approach was taken for Testbed 17 in order to have a common set of relatively simple rules for computing default geometries for NOTAM events. For a production API, rules for computing a default event geometry would need to be defined for each NOTAM scenario - and implemented.