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.

5.2.1.  Available APIs

D105 provides actual flight position data from TFMS, STDDS, and SFDPS. STDDS provides flight positions in and around airports versus TFMS and SFDPS focus more on en route flight positions. The API calls are defined using OpenAPI 3.0.1 and are structured similarly for each feed providing a standardized way for a developer to access the data from these three disparate feeds. The API calls available for each data feed include:

• Get a unique route (user inputs acid, origin airport, destination airport, and time).

• Get routes of flights using an origin airport (user inputs origin airport, start time, and end time).

• Get route of flight using a destination airport (user inputs destination airport, start time, and end time).

• Get route for a specific GUFI (user inputs GUFI).

The returns are structured in JSON. In cases where a single flight is returned (e.g., Get route for the specific GUFI), a single feature is returned whereas for cases where multiple flights are returned, then a featureCollection is returned. However, it should be noted that for all the services, a flight maps to a single feature. Each feature includes the following:

• type

• geometry

• gufi

• acid

• aircraft_address

• aircraft_registration

• arrival_aerodrome_icao_name

• departure_aerodrome_icao_name

• departure_time

• arrival_time

Resulting feature collections are filtered only by the parameters defined for each function. In the case of functions that return FeatureCollection, these include a limit parameter. No other general use filtering strategy is provided at this time.

6.1.1.  API Overview

This API was built following the Standard OGC API — Features and adapted to publish JSON-FG.

In this case, flight plans fit well in the definition of feature (according to ISO-19101, a feature is defined as an: “abstraction of real world phenomena”), so OGC API Features seems the natural API to publish flight data. As flight plans always have a temporal interval (the planned or actual departure and arrival times), the best format to encode them is probably JSON-FG, although it is important to keep GeoJSON format due to its wide adoption and ecosystem of ready-to-use tools.

The API supports filtering using the following parameters:

• limit: Will return the next elements until the amount specified in the limit.

• bbox: Will return all flights that cross the bounding box.

• datetime: Only available if format requested is jsonfg.

  • specific datetime: Will return all flights that are operating at that moment.

  • datetime interval: Will return all flights that are operating at any moment during that interval.

• queryables: The list of available queryables is here: https://aviationapi.skymantics.com/faa/collections/faa_flight_plans/queryables.

The API also provides semantic information. To start with, the HTML and GeoJSON formats provide one property named “feattype” that indicates the type of feature. In JSON-FG format the top-level member featureType is the one indicating the type of feature.

The content of the featureType (or the feattype property) for flight plans is sfdps:FlightPlan, which follows the JSON-LD standard. This serves as an anchor to define contexts and provide links to dictionaries providing further information of the featureType. In this case, the context is sfdps and could provide the link to a dictionary containing all the information on FAA’s SFDPS.

Moreover, JSON-FG provides additional links to JSON schemas describing the structure of the collections and features data. Several links can be provided for the same item, for example a link to the schema of a GeoJSON feature, a link to the schema of a JSON-FG feature and a link to the schema of a FAA SFDPS flight plan, being all simultaneously valid (because these features follow those three schemas simultaneously).

Apart from that, nested properties in features keep their original FIXM types (such as ns5:NasRouteType, ns2:FixPointType or ns5:NasAircraftType). In addition, other nested properties that provide a link to external features stored in the aeronautical databases have their own type definition, referring to the linked type, such as arrival or departure airports and alternates (type defined as schema:Airport) or control center (type defined as nasr:ARTCC).

Finally, the API also provides links to external features, in order to complete information such as airports and control center.

6.2.1.  Contrast With Testbed-16 Aviation Task Challenges

• Spatial information in a feature: Flight plans do not explicitly include spatial information but must be inferred from the route string, which is hard to interpret and is sometimes ambiguous.

• Limited semantic descriptions of feature collections and features: In JSON-FG this issue is solved with the featureType member, the JSON-LD context, and the links to JSON schemas. However, these dictionaries and schemas need to be implemented and available for linking. https://semantics.aero/ would be a good place to start. This is a pretty similar conclusion as in TB-16

• Large data volume: This issue was resolved by cleaning the database of messages older than 7 days. But it is an issue as it limits the scalability of the service. For example, if updates were limited to only the data that has changed, the data transfer will likely drop to less than half of current level.

7.1.1.  API Overview

• Main endpoint (OGC API — Features): Data for this endpoint is periodically downloaded from NM B2B PREOPS service for all flights leaving or arriving to six airports (KJFK, KBOS, KPHL, KCLT, KIAD and KMEM), same as FAA façade.

  • Flight plans: https://aviationapi.skymantics.com/eurocontrol/collections/eu_flight_plans/

• Additional endpoints (OGC API — Features): Data for these endpoints is static and has been extracted from EUROCONTROL NM Airspace Datasets.

  • Airports: https://aviationapi.skymantics.com/eurocontrol/collections/airports

  • FIXes: https://aviationapi.skymantics.com/eurocontrol/collections/fixes

7.2.1.  Contrast With Testbed-16 Aviation Task Challenges

• Spatial information in a feature: This service offers a much more convenient way to assess the 4D flight trajectory in detail (in fact, the EUROCONTROL trajectory was encoded using the rules specified in the draft Route Exchange Model). The only remaining problem was the ambiguity of some waypoints that share the same ID but are located in very different coordinates.

• Large data volume: NM B2B supports requesting flight information when needed and to select the properties to be downloaded, so this issue is solved. However, a new issue appears if there are no sub/pub services providing timely info on updates and new flights. This issue forces periodic requests that require a high consumption of bandwidth. This can be solved by using both request/response and pub/sub services provided by NM B2B to complement each other.

8.1.1.  Fusion Process

The component has two separate processes based on whether the end user, as a filter parameter, has provided the GUFI number of the flight for which restrictions are being looked for. Both processes are described in the Figure 15.

• If no GUFI number is provided, the fusion service requests a list of ‘default’ flights are received from D107a. It was not possible to receive ‘default’ flights from D105 as it did not support the limit parameter and had some required parameters (origin, from, to). For each of the retrieved flights, the fusion service extracts the information about the geometry, departure and arrival time and uses it to request flight restrictions from D104. Results from D104 are returned to the client. Only the number of records defined by the limit parameter are returned.

• If a GUFI number is provided, the fusion service first tries to get the flight details based on the GUFI using the Clause 5. If no data is returned, the fusion service tries to get the flight details from the Clause 6. This means the component is supporting flown flights and flight plans at the same time. The geometry and information about the departure and arrival time are extracted from the retrieved flight details and used to request flight restrictions using the Clause 4. This service returns (if found) a collection of flight restrictions features encoded as a GeoJSON document.

Figure 15 — Fusion Process of the Flight Restrictions Data Fusion Component

The fusion condition is an expression that can be evaluated to yes/no and can contain logical operators, spatial functions, time functions, data conversion functions or any other functions. The fusion condition is evaluated for each combination of rows from both data sources and if it evaluates as “yes”, the relation between these two rows exists. Obviously, the fusion condition contains a reference to both rows that are currently evaluated. The simplest example for the fusion condition would be rowDataSource1.id == rowDataSource2.id.

The fusion condition used for this fusion service is following spatial_intersects(rowFlightData.geometry, rowRestriction.geometry) && temporal_intersects(rowFlightData.timeRange, rowRestriction.timeRange). This condition is simplified. The actual fusion condition contains additional functions to unify the data formats. Omitted additional functions are conversion of geometry to the same coordinate reference system, conversion to the unified time range data type from the fields departuretime, arrivaltime, valid_time_begin, and valid_time_to.

As the geometry CRS from all data sources is the same (CRS84), the CRS conversion is not required and therefore not active. The reason why the CRS conversion was considered is the intention to build a data fusion service that is capable of fusing any two data sources that provide data as a GeoJSON document. While this is possible from the CRS point of view, the showstopper is the lack of a standardized way for encoding the temporal information. The “Features and Geometries JSON” draft offers a way on how to overcome this problem with the use of the proposed “when” parameter. For the testbed, it was not possible for the Fusion Component to use JSON-FG because the main data source for flight data did not offer data in the JSON-FG format. This is a good opportunity for future experiments, where all data sources will be delivered using the proposed JSON-FG format. At that time, generic fusion based on geometry and time would be possible.

8.1.2.  Data Models Explored for Fused Data

The simplest way to fuse the data is to return all fields from both data sources in one row as displayed in the diagram (option A in Figure 16). However, there are many problems associated with this approach. First of all, there is not always a one-to-one relation. This is the TB-17 case. Second, encoding such a structure in GeoJSON format is not possible because there are two ids, two geometries and two sets of properties. A possible way to overcome this problem would be to select id and geometry from one entity and select only specific properties from entity a or b. In case of same name of the property in both entities, the property could be renamed.

The other extreme is to provide only ids of rows that are related (option B in Figure 16). However the user would be forced to gather the data manually based on ids received from the fusion service. On the other hand, the advantage would be that the data model is very simple and straightforward.

Another possibility would be to produce two datasets as result of the fusion (option C in Figure 16). The first dataset would contain all data from the first data source (id, geometry, properties) and list of IDs of related entities from the second data source. The second dataset would contain all data from the second data source and list of ids of related entities from the first data source. An alternative to this approach is to include the entire data object instead of a list of ids. However, this would produce a confusing nested data structure. The diagram displays the alternative with the list of ids.

The latter approach looked like a good alternative, but this option presented showstoppers as well. On one hand, the fusion service would have been able to get all flight restrictions for a specific flight. On the other hand, the fusion service would have not been able to get all flights for a specific flight restriction as the flight data sources (D105 and D107a) do not support filtering based on geometry. Furthermore, as one of the flight data sources (D105) does not support the limit parameter, which controls how many records are returned, it is really hard to offer a responsive fusion service when no filter criteria are defined from the client.

Figure 16 — Fused Data Model Options Explored

Another option considered was to force users to enter a GUFI filter to be able to use the fusion service. The API would return all restrictions that fulfill the fusion condition and are related to the flight according to the GUFI specified by the user. This idea was discarded because OGC API — Features shall support parameterless access as well.

The chosen model, as seen on Figure 17, consists of an “Enriched Entity” made up of the id, geometry and properties of an “Entity B” coupled with the ID of an “Entity A” with which it has been fused. In this example, Entity A would represent flights and Entity B would represent flight restrictions. As D105 nor D107a support filtering based on geometries (OGC API — Features: Part 3), the model was built with only one flight (Entity A) associated with a flight restriction (Entity B). Since in reality a restriction normally affects many flights, the data model uses the variable name retrievedForGUFI as a reference to the GUFI associated with the restriction in order to make clear that the restriction is associated to one flight in the model but can also be associated with another flight as well.

Figure 17 — Fused Data Model Option Selected

9.1.1.  Usage

As with any other OGC API — Processes implementation, the method used to launch the process is POST. Therefore, a browser is not a useful interface to test the service. Curl or Postman are good alternatives. Using the POST method and a JSON message with the aforementioned structure in the Body of the request makes the process execute.

Example 1 — Query the EUROCONTROL Flight Plan for FAA’s GUFI 9fc90409-15c9-49b3-a697-7bfc6b6dc29b

curl -X POST "https://aviationapi.skymantics.com/fusion/processes/aviation-fusion/execution/" -H "Content-Type: application/json" -d "{\"inputs\":{\"flight\":\"9fc90409-15c9-49b3-a697-7bfc6b6dc29b\"}}"

{
    "outputs": {
        "flight": "9fc90409-15c9-49b3-a697-7bfc6b6dc29b",
        "dataset": "FAA",
        "status": "FAA flight found in EUROCONTROL dataset",
        "results": [
            {
                "id": "AT02815598",
                "dataset": "EUROCONTROL",
                "href": "https://aviationapi.skymantics.com/eurocontrol/collections/eu_flight_plans/items/AT02815598",
                "lastupdated": "Unknown"
            }
        ]
    }
}

Example 2 — Query the FAA Flight Plan for EUROCONTROL’s flightid AT02815598

curl -X POST "https://aviationapi.skymantics.com/fusion/processes/aviation-fusion/execution/" -H "Content-Type: application/json" -d "{\"inputs\":{\"flight\":\"AT02815598\"}}"

{
    "outputs": {
        "flight": "AT02815598",
        "dataset": "EUROCONTROL",
        "status": "EUROCONTROL flight found in FAA dataset",
        "results": [
            {
                "id": "9fc90409-15c9-49b3-a697-7bfc6b6dc29b",
                "dataset": "FAA",
                "href": "https://aviationapi.skymantics.com/faa/collections/faa_flight_plans/items/9fc90409-15c9-49b3-a697-7bfc6b6dc29b",
                "lastupdated": "2021-09-08T05:18:31.394000"
            }
        ]
    }
}

10.2.1.  Visualization

The application displays aviation data through the LuciadRIA 3D map environment. When loaded, collections are listed in a window where users can look them up, focus the map on them, toggle their visibility or remove them from the application. Aviation data can be visualized combined with other non-aviation geospatial data. The capabilities developed in TB-17 were built to be compatible with LuciadRIA’s map and feature visualization through its integration with other OGC services. Users are able to connect to a Web Map Service (WMS) or Web Feature Service (WFS) to retrieve and visualize a preferred base map (such as satellite imagery or road maps), as well as additional non-aviation data such as administrative jurisdictions or natural geographic features.

LuciadRIA has codecs built to process each data encoding. During TB-16, three prototypes were used to process AIXM, FIXM and GeoJSON data respectively. For TB-17, a prototype codec for JSON-FG was designed. This new codec extends the existing GeoJSON format and adds those features that are considered important for aviation — such as multiple CRS support, time dimension, feature type, and additional geometries. The data returned by the server is displayed “as is” in the map. The data is decoded and converted to the LuciadRIA native data model, but all original attributes are preserved including the properties, geometry and native CRS.

The data is styled accordingly to the feature type. If a feature type is recognized, the styles, such as stroke color, fill-in color, text and so forth, are properly defined for each feature type. If a feature type is not recognized, then the feature is still painted on the map but uses a default generic style. For instance, if a feature of type Runway is received, it is styled as a polygon draped on the terrain and colored in a blackish tone. Likewise, if a runway marking is received, it is rendered as white lines, polygons or points that are draped on top of the Runway. For TB-17, new feature types were introduced for which Hexagon added suitable styling.

10.2.2.  Displaying Aviation Raw Data

Figure 20 — LuciadRIA Displaying Airspaces Retrieved From D104

LuciadRIA can connect to multiple endpoints and load information about airspaces, airport structures, and NOTAMS. Features are visualized in the LuciadRIA 3D map environment, as seen in Figure 20, and its properties can be explored by selecting them on the map, right-clicking on them and selecting the option to view properties.

Figure 21 — LuciadRIA Displaying NOTAMs Retrieved From D104

NOTAMS are displayed on the map in the form of markings. As seen in Figure 21, a time control tool allows users to navigate throughout a given timespan. Users can move forward or backward in time and select different timespans, and NOTAMs belonging to the selected timeframe appear accordingly on the map based on the data loaded. Users can also explore feature properties of each NOTAM by right clicking them and selecting “show properties” from the context menu.

Figure 22 — LuciadRIA Displaying STDDS Flight Data Retrieved From D105

Flight data can be retrieved from D105 and D107a. For D105, a new form was created in LuciadRIA to enable users to connect to the API, select whether to retrieve data from SFDPS, STDDs, or TFMS, search flight data from different airports and display it (as seen on Figure 22).

10.2.3.  Displaying Aviation Fused Data

Figure 23 — LuciadRIA Displaying Flight Restrictions Retrieved From D106

A new form was created in LuciadRIA to enable users to connect to the Clause 8. In this form, the user inputs the service URL, the GUFI of the flight where restrictions are being looked for. LuciadRIA then connects to the Fusion Service, retrieves the corresponding flight restrictions and displays them on the map, as seen on Figure 23.

Figure 24 — LuciadRIA Displaying International Flight Data Retrieved from D107a, Using D107

A new form was created to connect in LuciadRIA to enable users to the Clause 9. The process to work with this Fusion Component is:

1. The user inputs the service URL and the GUFI or Flight ID being looked for

2. LuciadRIA requests the first flight feature from D107a based on the original GUFI of Flight ID input by the user.

3. LuciadRIA sends the request to the Fusion Service.

4. LuciadRIA retrieves from the response of the Fusion Component the corresponding D107a flight URI.

5. LuciadRIA requests the second flight feature from D107a based on the retrieved URI.

6. LuciadRIA displays both flight features on the map, as seen on Figure 24.

10.3.1.  Contrast With Testbed-16 Aviation Task Challenges

• One of the lessons learned from TB-16 was that the GeoJSON format is very generic and therefore it becomes impossible to properly identify a feature type (this was one of the reasons TB-16 used AIXM). In TB-17, during the design of JSON-FG, a decision was made to add a feature type attribute in a similar way as specified in AIXM. This supported the ability to identify the type of the feature and interpret it accordingly, thus solving the problem identified in TB-16.

11.2.1.  Importance of API Consistency

The integration of the services with D109 was very straightforward because all the services used the OpenAPI specification. The same documentation format allowed the web crawler to process the information in a consistent way. The primary lesson learned is the importance of API consistency. If the APIs are built in a similar way, with similar path structures then the ability to search across the APIs is relatively simple and provides the end user with many benefits.

12.2.1.  D104 Aviation API for D106 Fusion Service

This TIE successfully tested the following scenarios. Details are provided in Table 3.

• Retrieve flight restrictions data in GeoJSON format / Ability to retrieve the ‘default’ data (no required filters, returning first X records).

• Retrieve flight restrictions data filtered by geometry.

• Retrieve flight restrictions data filtered by feature type (airport, airspace, etc.).

• Confirm that the data provided by (D104 and D105) and (D104 and D107a) are in the same date range.

Table 3 — TIE Functional Test — D104 > D106

12.2.2.  D105 Aviation API for D106 Fusion Service

This TIE successfully tested the following scenarios. Details are provided in Table 4.

• Retrieve historical flight data filtered by GUFI (Globally Unique Flight Identifier) including departure and arrival time.

• Confirm that the data provided by D104 and D105 are in the same date range.

Table 4 — TIE Functional Test — D105 > D106

12.2.3.  D107a Aviation API for D106 Fusion Service

This TIE successfully tested the following scenarios. Details are provided in Table 5.

• Retrieve flight plan data in GeoJSON format / Ability to retrieve the ‘default’ data (no required filters, returning first X records).

• Retrieve flight plan data filtered by GUFI (Globally Unique Flight Identifier) including departure and arrival time.

• Confirm that the data provided by D104 and D107a are in the same date range.

Table 5 — TIE Functional Test — D107a > D106

12.2.4.  D107a Aviation API for D107 Fusion Service

This TIE successfully tested the following scenarios. Details are provided in Table 6.

• Find flight in FAA façade based on FAA GUFI, if it exists.

• Find flight in EUROCONTROL façade based on EUROCONTROL flightID, if it exists.

• Find flight in EUROCONTROL façade based on FAA GUFI, if it exists.

• Find flight in FAA façade based on EUROCONTROL flightID, if it exists.

Table 6 — TIE Functional Test — D107a > D107

12.2.5.  D104 Aviation API for D108 Client Application

This TIE successfully tested the following scenarios. Details are provided in Table 7.

• Retrieve available collections and capabilities.

• Retrieve features per collection.

Table 7 — TIE Functional Test — D104 > D108

12.2.6.  D105 Aviation API for D108 Client Application

This TIE successfully tested the following scenarios. Details are provided in Table 8.

• Retrieve flight SFDPS.

• Retrieve flight STDDS.

• Retrieve flight TFMS.

Table 8 — TIE Functional Test — D105 > D108

12.2.7.  D107a Aviation API for D108 Client Application

This TIE successfully tested the following scenarios. Details are provided in Table 9.

• Retrieve available collections and capabilities.

• Retrieve features per collection.

Table 9 — TIE Functional Test — D107a > D108

12.2.8.  D106 Fusion Service for D108 Client Application

This TIE successfully tested the following scenarios. Details are provided in Table 10.

• Retrieve flight restrictions and display in map.

Table 10 — TIE Functional Test — D106 > D108

12.2.9.  D107 Fusion Service for D108 Client Application

This TIE successfully tested the following scenarios. Details are provided in Table 11.

• Retrieve a Flight ID based on a GUFI.

• Retrieve a GUFI based on a Flight ID.

Table 11 — TIE Functional Test — D107 > D108

12.2.10.  D104 Fusion Service for D109 Client Application

This TIE successfully tested the following scenarios. Details are provided in Table 16.

• Access API documentation from D104 through READ link.

• Access API endpoints from D104 through EXPERIMENT link.

• Search for D104 API endpoints.

Table 12 — TIE Functional Test — D104 > D109

12.2.11.  D105 Aviation API for D109 Client Application

This TIE successfully tested the following scenarios. Details are provided in Table 13.

• Access API documentation from D105 through READ link.

• Access API endpoints from D105 through EXPERIMENT link.

• Search for D105 API endpoints.

Table 13 — TIE Functional Test — D105 > D109

12.2.12.  D107a Aviation API for D109 Client Application

This TIE successfully tested the following scenarios. Details are provided in Table 14.

• Access API documentation from D107a through READ link.

• Access API endpoints from D107a through EXPERIMENT link.

• Search for D107a API endpoints.

Table 14 — TIE Functional Test — D107a > D109

12.2.13.  D106 Fusion Service for D109 Client Application

This TIE successfully tested the following scenarios. Details are provided in Table 15.

• Access API documentation from D106 through READ link.

• Access API endpoints from D106 through EXPERIMENT link.

• Search for D106 API endpoints.

Table 15 — TIE Functional Test — D106 > D109

12.2.14.  D107 Fusion Service for D109 Client Application

This TIE successfully tested the following scenarios. Details are provided in Table 16.

• Access API documentation from D107 through READ link.

• Access API endpoints from D107 through EXPERIMENT link.

• Search for D107 API endpoints.

Table 16 — TIE Functional Test — D107 > D109

13.1.1.  Developing Façades in Front of SWIM Services

Due to the effort required and the large number of actors involved, the transition of SWIM services into using standards-based APIs can be considered a long-term endeavor, the development of façades becomes a practical consideration. A façade is a component that fetches data from a service and offers that data through its own API. The SWIM Data Relay API built during Testbed-16 was a façade, as well as this Testbed’s D104 (only the API serving NOTAMs), D105, D107a and D107b.

The cases when deploying façades can be beneficial are the following:

• When transitioning the authoritative source into using OGC API Standards is not immediately possible.

• When the authoritative source provides data only through pub/sub services, and there is a value to support also request/response.

• When you need to transform the format of the data (for example, from GML to GeoJSON/JSON-FG).

• When reducing the amount of data published is needed in the service (and the original source does not offer a mechanism for that).

• When for performance reasons the data needs to be close to a service (for example deploying a fusion service).

The disadvantages or challenges for façades are the following:

• The volume of data to store is large, especially as there is a requirement to store a wide variety of messages during a long period of time.

• The extra processing consumes time, making the service slower.

• When a request/response façade is built in front of a request/response authoritative source, storing a local copy of the dataset in the façade can bring issues to keep the data updated. In contrast, when working with pub/sub, every data update on the authoritative source would be automatically notified to the façade as new incoming messages.

• Making a pub/sub façade in front of a request/response is not an option, as you just cannot provide the advantages of pub/sub service of informing of real-time changes.

13.1.2.  Building Standards-Based APIs Natively on top of SWIM Data

A standards-based API that directly accesses the SWIM data would provide two main benefits:

• Be more performant and more stable, compared to an API façade that sits on top of an existing SWIM service and translates API requests to SWIM service requests (like an API façade that talks to a WFS at the backend), because of the additional processing and transformations.

• Reduce the computational complexity and resource requirements compared to an API façade that subscribes to pub/sub SWIM services and build a local datastore that is used to respond to API requests (which is what the NOTAM API does).

13.2.1.  Creating a new API Standard for Aviation Data

The implementation of new standards is a long process that requires consensus and involvement of the community. Once approved, the standard needs to be promoted and developers need documentation and support to understand and adapt the standard.

The standard will not have credibility and will not reach mass adoption until uptake reaches a tipping point, with enough functional implementations available. If the standard serves a clear use case, with real-world demand, that cannot be served using existing standards, then it will naturally follow that path and eventually be adopted. If the use case is not clear or if it can be served using existing standards, that will lead to community fragmentation or to lack of adoption for the new standard.

Before any attempt to define a new OGC API standard, its scope should be clearly — and narrowly – defined with specific use cases with real-world demand that cannot be served using existing APIs. A market need for such a standard and why it is feasible to develop and promote such a standard should be clearly stated.

Further, it is unclear whether standards-based APIs can be developed for certain use cases. From experience with aeronautical data in TB-17 it seems as if different AIXM datasets follow different conventions. So, a NOTAM API from FAA will likely have to be different from an API from another NOTAM distributor.

13.2.2.  Implementing Existing OGC API Standards to Serve Aviation Data

As there is no reason to re-invent standards, for the geospatial aspects of aviation data, leveraging the relevant OGC API building blocks is a way forward. For other aspects, the best solution depends on the community and ecosystem as to whether to leverage the non-geospatial OGC API building blocks. The experiments carried out during the Testbed demonstrated that current OGC API standards (in particular, the Features and Processes APIs) can indeed support the exchange of aeronautical data, flight data, and fused data.

Using existing standards have a huge benefit in using readily available applications (clients and servers) which provides out-of-the-box functionality that has proven useful in many other use cases and that has been tuned by a long iterative process. An example is the rich filtering capabilities provided by OGC API — Features with respect to searching for flight plans according to a variety of criteria, or searching for flight restrictions based on a geometry that represents a flight path. A new API would take a long time before it could have these capabilities agreed and completed.

Using existing standards is the most time efficient strategy for the adoption and implementation of standards by the community. This approach benefits from having existing documentation, tutorials and examples, existing experienced developer basis and existing ecosystem of functional solutions. New synergies come to play, as the use cases of existing standard expands, increasing the usage, communities, documentation and ecosystem of the existing standard.

13.2.3.  Additional Considerations for APIs Serving Aviation Data