3.1.1.  SWIM

The System-Wide Information Management (SWIM) initiative supports the sharing of aeronautical, air traffic and weather information by providing communications infrastructure and architectural solutions for identifying, developing, provisioning, and operating a network of highly-distributed, interoperable, and reusable services.

As part of the SWIM architecture, data providers create services for consumers to access their data. Each service is designed to be stand-alone. However, the value of data increases when it is combined with other data. Real-world situations are often not related to data from one but from several SWIM feeds. Having consumers retrieving data from several SWIM services raises the need of interoperability between those services.

3.1.2.  OGC API Standards

For several years, the OGC members have worked on developing a family of Web API standards for the various geospatial resource types. These APIs are defined using OpenAPI. As the OGC API standards keep evolving, are approved by the OGC and are implemented by the community, the aviation industry can subsequently experiment and implement them.

The following OGC API Standards and Draft Specifications were used for the development of APIs during this Testbed:

OGC API – Features: a multi-part standard that defines the capability to create, modify, and query vector feature data on the Web and specifies requirements and recommendations for APIs that want to follow a standard way of accessing and sharing feature data. It currently consists of four parts:

• OGC API — Features — Part 1: Core. Approved September 2019, this standard defines discovery and query operations. [5]

• OGC API — Features — Part 2: Coordinate Reference Systems by Reference. Approved October 2020, extends the core capabilities specified in Part 1: Core with the ability to use coordinate reference system identifiers other than the defaults defined in the core. [6]

• Draft OGC API — Features — Part 3: Filtering. Part 3 specifies an extension to the OGC API — Features — Part 1: Core standard that defines the behavior of a server that supports enhanced filtering capabilities. [7]

• Draft OGC API — Features — Part 4: Create, Replace, Update and Delete. Part 4 specifies an extension that defines the behavior of a server that supports operations to add, replace, modify or delete individual resources from a collection. [8]

A specification for version 2 of the Common Query Language (CQL2) is being developed together with Part 3 to standardize a language that is recommended for filter expressions. [9]

OGC API – Processes: An approved OGC API standard, published December 2021, that specifies a Web API that enables the execution of computing processes and the retrieval of metadata describing their purpose and functionality. Typically, these processes combine raster, vector, coverage and/or point cloud data with well-defined algorithms to produce new information. [10]

Draft OGC API – Tiles: This draft API defines how to discover which resources offered by the Web API can be retrieved as tiles, retrieve metadata about the tile set (including the supported tile matrix sets, the limits of the tiled set inside the tile matrix set) and how to request a tile. [11]

Draft OGC API – Styles: This draft API specifies building blocks for OGC Web APIs that enables map servers and clients as well as visual style editors to manage and fetch styles. [12]

3.1.3.  Exploration of OGC API Standards by SWIM

For several years, the FAA and the OGC have jointly explored making SWIM data more easily accessible and more valuable. As part of these past efforts, Testbed-16 brought together previous work on the development of OGC APIs, the use of semantics to enrich data, and SWIM data processing. The objectives were to deliver the first demonstration of an OpenAPI-based API serving SWIM data, a component generating aviation Linked Data, and two client applications querying and displaying that data [8].

Two of the TB-16 recommendations were to integrate OGC APIs within SWIM Data Services and to demonstrate interoperability between diverse Aviation APIs [8]. In order to advance these recommendations, TB-17 focused on the development of eleven APIs based on OGC API standards, and the completion of Technology Integration Experiments (TIEs) between these APIs.

During TB-16, the development of the API serving aviation data resulted in numerous lessons learned and recommendations [8]. TB-16 saw the development of one aviation-related API based on an OGC API Standard (OGC API — Features). The APIs developed during TB-17 addressed many of those lessons learned and implemented additional OGC API standards which have been maturing since; this process is reflected in Figure 2.

Figure 2 — Timeline of OGC API Standards and its Aviation Demonstrations

3.3.1.  Component Interactions

Two scenarios involving end users were identified — one for each of the two clients developed in this Testbed: The Aviation Domain Expert Client (D108) and the Aviation Developer Client (D109). Both scenarios consist of the end user interfacing a client application to visualize aviation data. These scenarios are meant to satisfy the Testbed requirement of exploring both an end-user and a developer perspective:

On the backend two types of scenarios were identified. On one hand, the Aviation Domain Expert Client retrieves information from the APIs built on top of the fusion components and the APIs built as facades for SWIM services. On the other hand, the Fusion Services retrieve information by connecting to the APIs built as facades for SWIM services. All these interactions are meant to satisfy the Testbed requirement of exploring the potential of OGC APIs within the aviation domain.

4.1.1.  Component Overview

This Façade Service features two data retrieval subcomponents: One for the Federal Notice to Airmen System (AIM-FNS) and another one for airspace and airport static data sources, a database to store the extracted data, and an Idproxy which delivers the APIs that serve the extracted data. Figure 4 describes the Façade Service subcomponents, the data sources (note that for AIM-FNS the retriever also accesses static sources on some occasions), and the TB-17 components consuming from the Façade APIs.

Figure 4 — D104 Component Overview

4.1.2.  ldproxy (API Component)

The main component that delivers the Aeronautical Data APIs is ldproxy. ldproxy is a software product, written in the Java programming language, that implements the OGC API family of standards. Idproxy enables sharing geospatial data using Web APIs based on OGC API standards. The key characteristics of ldproxy are:

• Easy to use: The APIs support both JSON and HTML. Users of an API can use their favorite programming environment to access the data or simply use their browser.

• Browsable: All content is linked from the landing page of each API. A user can navigate through the API in any web browser and quickly get an understanding of the available data and the API capabilities. Search engines can also index the data.

• Linkable: Each data item in the APIs has a stable URI and can be used in external links.

• Based on standards: ldproxy is a comprehensive implementation of the emerging OGC API Standards and an increasing number of clients or libraries can use the AAPIs directly. This also applies to the supported formats returned by the APIs, such as GeoJSON, Mapbox Vector Tiles, Mapbox Styles, or TileJSON. In addition, the APIs are documented in a developer-friendly way via OpenAPI 3.0.

• Certified: ldproxy is certified as an OGC Reference Implementation for OGC API — Features — Part 1: Core 1.0 and OGC API — Features — Part 2: Coordinate Reference Systems by Reference.

• Open Source: The source code is available under the Mozilla Public License 2.0 on GitHub.

• Multiple Data Sources: Currently three types of feature data sources are supported: PostgreSQL databases with the PostGIS extension, GeoPackage and OGC Web Feature Services. In addition, map or vector tiles stored in a MBTiles container are supported as a tile source.

• Extensible: ldproxy is modular, written in Java 11 and designed to be extended.

The landing page for all four Aeronautical Data APIs that comprise deliverable D104 is https://t17.ldproxy.net/.

All APIs provide access to data published by the US Federal Aviation Administration (FAA).

4.1.3.  PostgreSQL/PostGIS (Database)

The data for all APIs is stored in a PostgreSQL/PostGIS database. The aeronautical datasets are:

• All Controlled Airspaces of the Classes B, C, D, and E from the National Airspace System Resource (NASR) Subscription;

• Airport data for the major airports in the United States provided by Hexagon (AIXM 5.1); and

• Notices to Airmen (NOTAMs) received from a Federal Notice to Airmen System (AIM-FNS) subscription in FAA’s SWIM Cloud Distribution Service (SCDS), a cloud-based infrastructure dedicated to providing near real-time FAA SWIM data to the public via Solace JMS messaging.

4.1.3.1.  Communication Between ldproxy and PostgreSQL

ldproxy converts API requests to SQL queries and processes the results to convert them to API responses in the GeoJSON, Features and Geometries JSON (JSON-FG), HTML or Mapbox Vector Tile (MVT) formats.

Figure 5 — Information Flow for Data Requests

While the first two datasets are static and do not change, the NOTAMs are dynamic: that is new NOTAMs are added to the database as they are received from the SCDS subscription. Since a new NOTAM may change information that is cached in ldproxy for performance reasons (in particular, the spatial and temporal extent of the NOTAM dataset, but also vector tiles) a database trigger is used to notify ldproxy about a new NOTAM. For TB-17 a new capability was implemented in ldproxy to “listen” for notifications about feature changes. For each new NOTAM, the spatial and temporal extents are evaluated and if needed the extents of the NOTAM feature collection are updated. In addition, vector tiles that include the spatial extent are invalidated in the tile cache.

Figure 6 — Communicating Data Changes to ldproxy

The communication between ldproxy and PostgreSQL uses the standard PostgreSQL protocol, which is TCP/IP-based.

4.1.4.  Airport and Airspace Data Retrieval

The airport and airspace datasets have been loaded into the database using the GDAL ogr2ogr tool.

The airspace data was available as a Shapefile and the schema in the database is the same as the schema for the Shapefile.

The airport data was provided as an AIXM 5.1 XML document for each airport. The data was loaded into the database with one table per AIXM feature type. Since every feature has a single time slice, the time slices were flattened. An additional column airport was added for each table to identify the airport to which the feature belongs. For example, the table definitions for two AIXM feature types in the database:

CREATE TABLE public.airportheliport (
    ogc_fid integer NOT NULL,
    gml_id character varying NOT NULL,
    identifier character varying(11),
    validtimebegin timestamp(0) with time zone,
    interpretation character varying(24),
    sequencenumber integer,
    correctionnumber integer,
    featurelifetimebegin timestamp(0) with time zone,
    designator character varying(24),
    name character varying(64),
    aixmtype character varying(2),
    wkb_geometry public.geometry(Geometry,4326),
    airport character varying(4)
);

Figure 7 — Table Definition of AirportHeliport Features

CREATE TABLE public.apron (
    ogc_fid integer NOT NULL,
    gml_id character varying NOT NULL,
    identifier character varying(11),
    validtimebegin timestamp(0) with time zone,
    interpretation character varying(24),
    sequencenumber integer,
    correctionnumber integer,
    featurelifetimebegin timestamp(0) with time zone,
    name character varying(21),
    composition character varying(24),
    associatedairportheliport character varying(24),
    airport character varying(4)
);

Figure 8 — Table Definition of Apron Features

When loading the data, the airport column was set to the filename of the AIXM file and the gml_id values were prefixed with the airport code to ensure their uniqueness. In a post-processing step some data inconsistencies in the source data were removed, in particular invalid geometries.

4.1.5.  NOTAM Data Retrieval

The NOTAM API delivers a select set of the Digital NOTAM (DNOTAM) Event information, together with its geometry to indicate where the event is taking place. This section documents how the DNOTAM data is retrieved from SCDS, how it is filtered and enriched, and how a default geometry is computed for each NOTAM, before the resulting NOTAM data is finally stored in a PostgreSQL database. The [img_d104_retrieval] illustrates the NOTAM retrieval workflow.

4.1.5.3.  Determination of a Default Geometry for a NOTAM

Digital NOTAMs typically do not have a default geometry attached to them. However, provision of such a geometry is highly beneficial for NOTAM consumers (users and systems alike). This is because the default geometry would support a common means to search for and filter NOTAMs relevant to a given use case. In addition, a GeoJSON- which is highly popular amongst web application developers — based NOTAM encoding requires a default geometry in a GeoJSON encoded feature. Therefore in TB-17, interactive instruments developed an approach for determining a default geometry for a NOTAM event.

According to the Digital NOTAM (DNOTAM) Event Specification (version 1, chapter 5.3), the geographical data included in NOTAM messages is less mathematical and more descriptive. Even though 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 production rules for each NOTAM scenario supported by AIM FNS. Since such rules could not be found for use in TB-17, a pragmatic approach for computing default geometries for NOTAMs was taken.

NOTE 1  On https://notams.aim.faa.gov — section Documentation — a number of documents for FNS NOTAM scenarios can be downloaded. These documents, even though they were issued in December 2010, are still referenced in recent publications — such as the SWIM Federal Notice to Airmen (NOTAM) System (FNS) NOTAM Distribution Service (NDS) Publish/Subscribe Operational Context Document (from Feb 28, 2019). However, it is unclear how the scenario identifier from digital NOTAM events can be matched against the relevant scenarios. Furthermore, rules for computing a default geometry for the scenarios could not be found.

The approach to determine a default geometry depends on whether the NOTAM message is airspace-related or not. A NOTAM message is airspace-related if the message header ‘us_gov_dot_faa_aim_fns_nds_NOTAMKeyword’ has value ‘AIRSPACE’.

Non-airspace-related NOTAM message:

• NOTAM messages delivered by SCDS often (but not always) contain time slices — mostly snapshots, but also temp deltas — of aeronautical features affected by the event. Note that the snapshots received from SCDS typically are incomplete. In other words, 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 TB-17 gathers all (elevated) points, curves, and surfaces contained in the aeronautical features that accompany (i.e. they are in the same message as) the event feature. The geometries of highest dimension are selected and, if there are multiple geometries, 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 (in namespace http://www.aixm.aero/schema/5.1/extensions/FAA/FNSE). 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 either, the NOTAM message is dismissed by the harvester.

Airspace-related NOTAM message:

• For airspace-related NOTAMs, the NOTAM text was inspected first. If the text matched the regular expression ^AIRSPACE SEE (\\w{3}) (\\d+/\\d+) .*$ (with dot also matching newlines) then the second group within the expression identifies the NOTAM number. This number may match one of the Temporary Flight Restrictions (TFR) published by FAA not via the SCDS subscriptions, but only on the TFR website as HTML and not in a machine processable form. Such TFRs may be accompanied by a Shapefile whose feature(s) provide a geometry (collection) that is useful as the geometry of the NOTAM. If a match was found, and the TFR did have a Shapefile, the harvester used its geometry.

  • As an example, the following text matches the regular expression: ‘AIRSPACE SEE FDC 1/5005 ZLC 91.137 HAZARD’. ‘1/5005’ would be parsed as NOTAM number and the Shapefile describing the extent of the temporary flight restriction would be at https://tfr.faa.gov/save_pages/1_5005.shp.zip.

• If no geometry could be determined via the TFRs, then the airspace designator (‘ZLC’ in the example NOTAM) — which appears to be encoded in the event location — was matched against the IDENT field of airspace features contained in the Shapefiles that are part of the 28 day NASR subscription files and that was published via the Airspace API. If matches were found, the default geometry was set to the union of the shapes of the matching airspace features stored in the Shapefile.

• Otherwise, the NOTAM message was dismissed by the harvester.

The pragmatic approach described above was taken for TB-17 in order to have a common set of relatively simple rules for computing default geometries for NOTAM events. For a production environment, rules for computing a default event geometry would need to be defined for each NOTAM scenario — and implemented as such. Figure 9 summarizes this process.

NOTE 2  The 28 day NASR subscription files can be downloaded from the FAA website. As the name suggests, these files have a time period of 28 days in which they are effective.

Figure 9 — Process for Determining Default Geometry

4.2.1.  Overview

Four APIs have been set up using:

• Class B/C/D/E Airspaces from the National Airspace System Resource (NASR) Subscription,

• AIXM 5.1 airport data provided by Hexagon,

• NOTAMs received from the AIM-FNS feed from SCDS.

The APIs implement Parts 1, 2 and 3 of OGC API Features as well as drafts of OGC API Tiles, OGC API Styles and other draft extensions to OGC API Features.

The airport data is provided as two APIs:

• Organized by feature type. That is, each AIXM feature type is a feature collection that contains the features for all airports.

• Organized by airport. That is, each airport is a feature collection that contains the features of all feature Types for the airport.

The feature data is provided in two JSON encodings (GeoJSON and JSON-FG) and HTML, based on the AIXM application schema.

The data is provided in the following coordinate reference systems (CRS):

• WGS 84 longitude-latitude axis aligned (http://www.opengis.net/def/crs/OGC/1.3/CRS84)

• WGS 84 latitude-longitude axis aligned (http://www.opengis.net/def/crs/EPSG/0/4326)

• Web Mercator (http://www.opengis.net/def/crs/EPSG/0/3857)

• NAD83 (http://www.opengis.net/def/crs/EPSG/0/4269)

Only a few CRSs were configured since no client has requested support for additional systems. If needed, additional CRSs could be added.

4.2.2.  API Design Considerations and Decisions

The data shared via the APIs are features that are specified in the Aeronautical Information Exchange Model (AIXM).

The APIs target web developers, but also aim to be usable by end-users familiar with aviation concepts in a browser.

Based on this, the following design decisions were made for all D104 APIs:

• There will not be a single Aviation API, but APIs for specific patterns of use. The APIs will re-use existing, standardized API building blocks mainly from IETF and the OGC API standards, where possible.

• The four Aeronautical Data APIs of D104 share base data for airspaces and airports as well as information about events with a temporal effect.

• Since the data, which is shared via the APIs, are features in the sense of the General Feature Model of OGC and ISO/TC 211, the APIs build on the standard API building blocks for feature data. In particular, they conform to OGC API — Features — Part 1: Core. An immediate benefit of this approach is that the APIs can be used with generic OGC API clients like QGIS or ArcGIS as well as in web browsers.

• To simplify the use of the data that is fetched by clients, every feature represents the state of the real-world object during a single time slice. In other words, an AIXM feature that consists of multiple time slices would be published via the API as multiple features, each with the temporal validity of the time slice.

• The features are provided in two JSON encodings: GeoJSON and JSON-FG.

• The AIXM feature type is encoded in each feature in a top-level JSON member with the key “featureType” and the AIXM feature type name with a “aixm:” prefix, e.g. "featureType": "aixm:AirportHeliport".

• The feature properties use the unqualified name of the AIXM property. Values are simplified / flattened, where possible, based on the information contained in the source data.

• In addition to providing the features in JSON, the data are also provided as HTML. The APIs translate the AIXM based data to a HTML representation that is human-friendly. Instead of the property names, the titles (and descriptions) from the AIXM documentation are provided. Coded values are translated to their human-friendly labels.

• To support easy-to-use filtering of data, the AIXM features can be filtered using query parameters for key attributes — in addition to the spatial and temporal filtering using the standard bbox and datetime query parameters.

• To support retrieving the feature geometries in other coordinate reference systems beside WGS 84, all APIs conform to OGC API — Features — Part 2: Coordinate Reference Systems by Reference.

• To support more advanced filtering of features, all APIs conform to the current draft of OGC API — Features — Part 3: Filtering and the Common Query Language (CQL).

• To support large filter expressions, the APIs also support URL-encoded POST requests to the Features resources.

• To simplify filtering features that are currently valid, an additional token “now” is supported in the datetime parameter (“now” can also be the start or end value in an interval). In CQL filters a function now() can be used.

• To support clients that need a schema of the available data, the JSON schema of the features is available based on the current “Schema” proposal.

• To support clients that only need a subset of the feature properties, the content can be tailored based on the current “Property Selection” proposal.

• To support clients that want to render feature data on a map, the feature geometries can be simplified based on the current “Geometry Simplification” proposal.

• To simplify viewing the data in a web map — including in the HTML representation in the web browser, some of the APIs also conform to the drafts of OGC API Tiles and OGC API Styles. Where supported, the feature data is also provided as vector tiles in the Mapbox Vector Tiles format and styles are available in the Mapbox Style format. The data in the vector tiles is restricted to data this is valid at the time of the request.

• OpenAPI 3.0 is used to define / specify / document the API.

• Cross-Origin requests are supported.

• HTTP caching and conditional requests are supported to leverage web caches.

Just like the OGC API standards, the four APIs making up this Façade Service have been designed to support two different approaches for how clients will use the API:

In the first approach, clients are implemented with knowledge about the API specification and its resource types. The clients navigate the resources based on this knowledge and based on the responses provided by the API. The API definition may be used to determine details, such as filter parameters, but this may not be necessary depending on the needs of the client. These are clients that are in general able to use multiple APIs as long as they implement the same API building blocks.

The second approach targets developers that are not familiar with OGC API standards but want to interact with spatial data provided by an API that happens to implement an OGC API standard. In this case the developer will study and use the OpenAPI definition to understand the API and implement the code to interact with the API. This assumes familiarity with OpenAPI and the related tooling. As such studying the OGC API standards documents should not be necessary.

4.2.3.  General Rules for all APIs

The following sub-sections provide an overview of the available resources in the API. All paths are relative to the base URI https://t17.ldproxy.net/{apiId} where {apiId} is airspaces, airports, airports2 or fns.

4.2.4.  FAA’s NOTAM API

During the execution of the TB-17, the FAA announced their own NOTAM API development in a SWIFT meeting on May 27, 2021. The following section compares the similarities and differences between the API developed by FAA and the API developed in TB-17, based on the information in the presentation given at the meeting (slides 22 to 36).

4.3.1.  Contrast With Testbed-16 Aviation Task Challenges

• What is a feature in SWIM for the OGC API — Features service?: The issue still exists. The NOTAMs distributed via SCDS are not full Digital NOTAMs and much of the information would have to be parsed from the NOTAM text and referenced to a dataset with all referenced aeronautical features (which was not available to us, except for certain feature types like airspaces). The participant therefore decided to restrict the API to NOTAMs as features.

• Unique identification of a feature: The issue still exists. The AIXM datasets that were used do not have any persistent identifiers. A result is that the identifiers are basically assigned by the API. This was not an issue for the use cases in this testbed, but these would be an issue for a production API.

• Spatial extent in a feature collection: This issue was addressed. See Clause 4.1.3.1.

• Temporal extent in a feature collection: This issue was addressed. See Clause 4.1.3.1.

• Spatial information in a feature: This was an issue in this testbed. See Clause 4.1.5.3.

• Limited semantic descriptions of feature collections and features: See the comments on JSON-LD above.

• Large data volume: Not an issue for D104. The NOTAM volume has not been an issue for the duration of this testbed. Purging NOTAMs that have not been active for some time should not be a problem for most use cases.

• Automatic code generation is not perfect: No experiments with automatic code generation.