OGC Engineering Report

Testbed-17: Aviation API ER
Sergio Taleisnik Editor
OGC Engineering Report


Document number:21-039r1
Document type:OGC Engineering Report
Document subtype:
Document stage:Published
Document language:English

License Agreement

Permission is hereby granted by the Open Geospatial Consortium, (“Licensor”), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.


This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.

I.  Abstract

This Testbed-17 (TB-17) Aviation API Engineering Report (ER) summarizes the implementations, findings and recommendations that emerged from the efforts of building a definition for an Aviation API compliant with the requirements of the OGC Standards Program, and the exploration of the potential of aviation data fusion.

This ER describes the nine façades built to interface SWIM services and serve aviation data through OGC APIs, the two services built to consume SWIM data and fuse it to generate richer datasets while serving the fused data through OGC APIs, the client application built to display data retrieved from the façades and fusion services, and the development client built to focus on functionality and experimentation.

Finally, this ER discusses the potential of OGC APIs to help standardize the access to aviation data within the context of the System Wide Information Management (SWIM) program.

II.  Executive Summary

The System Wide Information Management (SWIM) Data Services of the Federal Aviation Administration (FAA) currently produce data from the National Airspace System (NAS) to consumers using various protocols and service offerings in both synchronous and asynchronous messaging formats. These services are documented and described in the FAA’s NAS Service Registry/Repository (NSRR). Consumers can access the NSRR to obtain this information for each SWIM service offering in order to develop their business applications. Often, business applications require multiple SWIM data; therefore, efforts have been made to standardize the SWIM data models for their domains (i.e. weather, aeronautical, and flight) based on XML standards such as Weather Information Exchange Model (WXXM), Flight Information Exchange Model (FIXM), and Aeronautical Information Exchange Model (AIXM).

Previous OGC work has addressed the challenges of increasing interoperability between aviation data services. Recently, the OGC community has developed a new family of standardized OpenAPI-based Web APIs for the various geospatial resource types with the potential to enhance the way in which consumers can access geospatial data from various sources. Testbed-16 brought together previous work on the development of OGC APIs, the use of semantics to enrich data, and SWIM data processing, and demonstrated an OpenAPI-based API serving SWIM data. Testbed-17 took many lessons learned and recommendations from Testbed-16 and focused on further testing the value of standards-based APIs within the SWIM program.

The research questions for the Aviation API Task were:

To answer these questions, the Aviation API Task was organized into the development and testing of a system of seven interconnected components, as seen on Figure 1:

Figure 1 — Component Diagram for the Aviation API Task

All components were successfully developed and tested. Eleven APIs were built implementing several OGC API Standards. The lessons learned throughout the Testbed are captured in this ER and help respond the research questions. The following is a set of recommendations for future work:

III.  Keywords

The following are keywords to be used by search engines and document catalogues.

ogcdoc, OGC document, Aviation, API, SWIM

IV.  Preface

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

V.  Security considerations

No security considerations have been made for this document.

VI.  Submitting Organizations

The following organizations submitted this Document to the Open Geospatial Consortium (OGC):

VII.  Submitters

All questions regarding this document should be directed to the editor or the contributors:

Name Organization Role
Sergio Taleisnik Skymantics, LLC Editor
Clemens Portele interactive instruments GmbH Contributor
Johannes Echterhoff interactive instruments GmbH Contributor
Jarrod Lichty Mosaic ATM Contributor
Frantisek Albert NG Aviation SE Contributor
Ignacio “Nacho” Correas Skymantics, LLC Contributor
Felipe Carrillo Romero Hexagon Contributor

Testbed-17: Aviation API ER

1.  Scope

This OGC Engineering Report (ER) presents deliverable D002 of the OGC Testbed-17 (TB-17) initiative performed under the OGC Innovation Program.

The ER reports on the activities performed throughout the testbed and provides discussions on the lessons learned. The ER discusses the business value of APIs based on OGC API standards in the purpose of serving aviation data through the SWIM system. This ER also explores the value of fusing raw aviation data into richer aviation datasets, and the consumption of raw and fused aviation data from the perspectives of both an aviation domain expert and a developer of aviation applications.

1.1.  What Does This ER Mean for the Working Group and the OGC

The Aviation Domain Working Group (DWG) was tasked with reviewing this ER. The Aviation DWG works on the subjects of aviation-related data interoperability and access.

The Aviation API Standard Working Group (SWG), proposed by the Aviation DWG, was constituted concurrently with TB-17. This approach provided a framework for leveraging the lessons learned and recommendations presented by this Testbed’s Aviation participants in order to work on the development and maintenance of an OGC Aviation API Standard.

Despite not being the focus for TB-17, the work on Aviation Linked Data could also be of interest to the Geosemantics DWG, which has been actively working on this subject for several years. This Geosemantics DWG reviewed the Testbed-16 (TB-16) Aviation Task ER due to the strong focus of TB-16 on semantics.

2.  Terms, definitions and abbreviated terms

This document uses the terms defined in OGC Policy Directive 49, which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this document and OGC documents do not use the equivalent phrases in the ISO/IEC Directives, Part 2.

This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the ‘ModSpec’. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.

For the purposes of this document, the following additional terms and definitions apply.

2.1.  Terms and definitions

2.1.1. Application Programming Interface (API)

an interface that is defined in terms of a set of functions and procedures, and enables a program to gain access to facilities within an application [1]

2.1.2. Web API

an API using an architectural style that is founded on the technologies of the Web [2]

Note 1 to entry: Best Practice 24: Use Web Standards as the foundation of APIs in the W3C Data on the Web Best Practices [2] provides more detail.

Note 2 to entry: A Web API is basically an API based on the HTTP standard(s).

2.1.3. Standards-based API

an API that conforms to one or more conformance classes specified in one or more standards

Note 1 to entry: Since almost all APIs will conform to some standard, the term is usually used in the context of a specific standard or a specific family of standards. This ER considers Web APIs with a specific focus on the OGC API standards. Therefore, whenever the term is used in this ER, it is meant as an alias for an API that conforms to one or more conformance classes as defined in the OGC API standards.

2.1.4. Standardized API

an API that is intended to be deployed by multiple API providers with the same API definition

Note 1 to entry: The only difference between the API definitions will be the URL(s) of the API deployment. All other aspects are identical (resources, content schemas, content constraints and business rules, content representations, parameters, etc.) so that any client that can use one deployment of the standardized API definition can also use all other deployments, too.

Note 2 to entry: If the API provides access to data, different deployments of the API will typically share different content.

2.1.5. Façade Service

A Façade Service is a component that fetches data from a specific data source and makes it available through its own interface [3]. The main reason for building this type of service is the difficulty or inability to modify the original data source with the intent of modifying:

  • The underlying API structure

  • The format in which the data is made available.

2.1.6. SWIM Data

Any data provided through the SWIM System.

2.1.7. SWIM Data Service

A service within the SWIM System that provides data. [4]

2.2.  Abbreviated terms


Aeronautical Information Exchange Model


Application Programming Interface


Air Route Traffic Control Center


Coordinate Reference System


Engineering Report


European Organisation for the Safety of Air Navigation


Federal Aviation Administration


Flight Information Exchange Model


Federal NOTAM System


Globally Unique Flight Identifier


Java Messaging Service


National Airspace System


Notice to Airmen


Open Geospatial Consortium


SWIM Cloud Distribution Service


SWIM Flight Data Publication Service


SWIM Terminal Data Distribution System


System Wide Information Management




Traffic Flow Management System


Temporary Flight Restriction


Technology Integration Experiment


Web Feature Service


Web Map Service


Web Map Tile Service


Weather Information Exchange Model

3.  Introduction

3.1.  Background

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.2.  Requirements Statement

Testbed-17 required investigating the potential of OGC API Standards in the context of the SWIM Program.

The original goals of the TB-17 Aviation API Task were the following:

  • Explore the potential of OGC Web APIs in the context of SWIM.

  • Develop an Aviation API, based on OGC Web API building blocks, that enables convenient access to existing SWIM services.

  • Demonstrate the capabilities of the new Aviation API in a data fusion scenario, and to serve aviation raw data.

  • Develop two clients: one with a focus on ease-of-use for end-users, and the other with a focus on functionality for developers.

  • Build on and stress-test previous Testbed results for semantic interoperability.

As noted, the original requirement for the Aviation task was the development of a draft OGC API specification specific for the exchange of Aviation information. Within the first few meetings after the Testbed began, participants agreed that this might not be a feasible option and therefore engaged into the alternative of using existing approved and draft OGC API standards to create the OGC APIs for the TB-17 components.

This change in the task focus provided a whole new set of questions to be answered. The original idea of developing a specific OGC API standard for Aviation was kept throughout the Testbed in order to contrast it with the usage of existing OGC API standards in aviation. The updated research questions are summarized as follows:

  • What are the benefits and downsides of:

    • Transitioning current APIs of SWIM services into APIs compliant with current and emerging OGC API Standards?

    • Creating a new OGC API standard for aviation data?

    • Implementing existing OGC API standards to create APIs serving aviation data?

  • Do these benefits and downsides change between:

    • Serving aviation raw data and serving aviation fused data?

    • Working with a client from a domain expert perspective and working with a client from a developer perspective?

    • Working with aeronautical data and working with flight data?

  • What lessons can be learned from the usage of different encodings, CRSs, and Linked Data?

The TB-17 Features and Geometries Task worked on the development of potential solutions to problems with JSON and GeoJSON when serving specific sets of data, including aviation data. Many participants from the Aviation Task also participated in the Features and Geometries Task.

3.3.  Functional Overview

As shown in Figure 3, the Aviation Task architecture was organized into a system of seven interconnected components. All seven components were developed simultaneously throughout the Testbed, with permanent communication and cooperation among participant organizations.

The components can be divided into three groups:

  • Façades for SWIM services, retrieving aviation data from multiple SWIM services (or static sources) and serving these data through OGC APIs. Three Façades comprising nine API components were built.

    • The Aeronautical Data APIs (identified collectively as D104): Four APIs built to serve NOTAMs, Airport Layouts and Airspaces

    • The Flight Positions Data APIs (identified collectively as D105): Three APIs built to serve flight positions from the STDDS, SFDPS, and TFMS Services

    • The International Flight Data APIs (identified collectively as D107a and D107b): Two APIs built to serve flight plans from the SFDPS (FAA) and NMB2B (EUROCONTROL) Services

  • Components that fuse raw aviation data, and serve the fused data through OGC APIs. Two fusion components were built, each one featuring an API.

    • The Flight Restrictions Data Fusion Service (identified as D106): Built to identify flight restrictions from past or future flights.

    • The International Flight Data Fusion Service (identified as D107): Built to fuse flight plans from a same flight spanning across the US and European airspaces which are commonly served separately.

  • Client components which present aviation data to end users. Two clients were built: One meant to serve an aviation domain expert, and the other to serve a developer of aviation software applications.

    • The Aviation Domain Expert Client (identified as D108): A client built to display aviation data to domain experts in a 3D map environment.

    • The Aviation Developer Client (identified as D109): A client built to explore the provision of data for the sake of helping developers access API information.

Figure 3 — Component Diagram for the Aviation API Task

The following table summarizes the SWIM data sources accessed by the façades:

Table 1 — SWIM Data Sources Accessed by TB-17 Façades

#Data Source NameData Source DescriptionFaçade Accessing the Data Source
1Federal NOTAM System (FNS)The modernized Notice to Airmen (NOTAM) management system designed to digitize the collection, dissemination, and storage of NOTAMs. The new process moves the responsibility for originating NOTAMs to those who directly observe the hazardous condition(s) within the National Airspace System (NAS). A digital NOTAM describes the temporary status change of a static feature caused by an event within the NAS in a standardized manner enabled by the Aeronautical Information Exchange Model (AIXM). Clause 4
2Traffic Flow Management System (TFMS)TFMS processes all available data sources such as flight plan messages, flight plan amendment messages, and departure and arrival messages. The FAA’s NAS Data Warehouse assembles TFMS flight messages into one record per flight. TFMS is restricted to the subset of flights that fly under Instrument Flight Rules (IFR) and are captured by the FAA’s en route computers. Clause 5
3SWIM Terminal Data Distribution System (STDDS)Converts legacy terminal data collected from airport towers and Terminal Radar Approach Control (TRACON) facilities into easily accessible information. STDDS is installed at 38 TRACONS within the NAS, providing access to data from over 200 airports, and over 400 individual systems. Clause 5
4SWIM Flight Data Publication Service (SFDPS)Provides en route flight data to National Airspace System (NAS) consumers. SFDPS allows consumers to receive real-time data for analytics, business processes, research, and other activities. Data is provided by data distribution systems located at each of the 20 Air Route Traffic Control Centers (ARTCCs) in the contiguous United States.Clause 5 and Clause 6
5Network Manager business-to-business web services (NM B2B)An interface provided by the EUROCONTROL Network Manager (NM) for system-to-system access to its services and data. NM B2B services include Flight Plan Preparation and Management, Flight Data Retrieval, Departure (DPI) and Arrival (API) Planning Information, among others. Clause 7

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.  Aeronautical Data Façade Service

The Aeronautical Façade Service provides Federal Notices to Airmen (NOTAMs) after extracting NOTAMs from the System Wide Information Management System (SWIM). Additionally, this component provides airport and airspace data extracted from various static data sources. All data is provided through APIs designed following approved or draft OGC API Standards. The Aeronautical Façade Service component was created by interactive instruments.

4.1.  Internal Architecture

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

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.  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.  Accessing NOTAM Data From SCDS

In order to access NOTAM data from the SWIM Cloud Distribution Service (SCDS), an SCDS account was created, followed by a subscription to the AIM FNS product. The subscription targeted all data items provided for that product; i.e. the subscription filter options for source type, NOTAM status / function / keyword, and airspace usage were not used.

SCDS delivers new data using a Java Messaging Service (JMS). JMS supports the publish-subscribe messaging pattern. The SCDS, acting as the data provider, publishes data on one or more JMS topics / message queues, to which subscribers connect in order to receive new messages.

In TB-17, interactive instruments developed a component that attaches itself to such a data feed. The component was written in Java, and leverages the SWIM feed handler project (open source, Apache License 2.0) to establish the connection and to receive NOTAM messages from SCDS.  Filtering and Enriching NOTAM Data

The interactive instruments NOTAM SWIM feed handler parses the following information from NOTAM messages received via JMS, including the JMS message headers:

  • NOTAM keyword — Keyword associated with the NOTAM

  • NOTAM function — Function of the NOTAM (New, Replacement, Cancelled)

  • Valid time (begin)

  • Valid time (end)

  • Text — NOTAM condition text

  • Q Code — Q Code value for the NOTAM.

  • Year — NOTAM year values per Annex-15 of the International Civil Aviation Organization (ICAO) Convention on International Civil Aviation.

  • Number — NOTAM number value per Annex-15 of the ICAO Convention on International Civil Aviation.

  • Scenario — Identifier of the event scenario used for digital encoding. The mapping can be found in the Event Scenario documents.

  • Flight Information Region — Flight Information Region (FIR) that is impacted by the NOTAM.

  • Location designator — NOTAM location designator of the affected airport/heliport or facility.

  • ICAO location designator — ICAO location designator, if published.

  • Series — NOTAM series value per Annex-15 of the ICAO Convention on International Civil Aviation.

  • Type — NOTAM type value per Annex-15 of the ICAO Convention on International Civil Aviation. Accepted values are: New (‘N’), Replace (‘R’), Cancel (‘C’).

  • Issued — Issue date/time of the NOTAM.

  • Traffic — NOTAM traffic value per Annex-15 of the ICAO Convention on International Civil Aviation.

  • Purpose — NOTAM purpose value per Annex-15 of the ICAO Convention on International Civil Aviation.

  • Scope — NOTAM scope value per Annex-15 of the ICAO Convention on International Civil Aviation.

  • Minimum flight level — NOTAM minimum flight level value per Annex-15 of the ICAO Convention on International Civil Aviation.

  • Maximum flight level — NOTAM maximum flight level value per Annex-15 of the ICAO Convention on International Civil Aviation.

  • Coordinates

  • Radius

  • Schedule — Contains a schedule of activity/outage if the hours of effect are less than 24 hours a day.

  • Lower limit — Specifies the lower height restriction of the NOTAM.

  • Upper limit — Specifies the upper height restriction of the NOTAM.

  • Geometry — Default geometry determined for the NOTAM

The last item, the default geometry, is exceptional because it is not parsed directly from the Digital NOTAM Event, but computed on-the-fly — as outlined below.  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 — 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 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

  • 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.  APIs

4.2.1.  Overview

Four APIs have been set up using:

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 (

  • WGS 84 latitude-longitude axis aligned (

  • Web Mercator (

  • NAD83 (

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{apiId} where {apiId} is airspaces, airports, airports2 or fns.  Read-only

The APIs only provide read-access.

With the exception to the resources at /collections/{collectionId}/items only the HTTP GET method is supported. That resource also supports the HTTP method POST with the form media type application/x-www-form-urlencoded in addition to GET in order to support queries with large geometries due to length restrictions for URLs.  Supported Encodings

Resources are in general available as HTML and JSON:

  • To fetch HTML, use HTTP content negotiation (e.g. set the Accept header to Accept: text/html) or use a query parameter f=html.

  • To fetch JSON/GeoJSON, use HTTP content negotiation (e.g. set the Accept header to Accept: application/json, application/geo+json) or use a query parameter f=json.

  • To fetch JSON/JSON-FG, use HTTP content negotiation (e.g. set the Accept header to Accept: application/json, application/vnd.ogc.fg+json) or use a query parameter f=jsonfg.

The metadata about the data that is used in the API configuration and to provide a human readable HTML representation has been derived from AIM documentation, the AIS Open Data Dictionary and the AIXM documentation.  General Information

  • / — the Landing Page, contains links to sub-resources in the API

  • /conformance — the Conformance Declaration, lists the URIs of the OGC API conformance classes implemented by the API; this resource is only relevant for clients that implement OGC API standards.

These resources are specified by OGC API Common / OGC API Features.  The Data That is Available

  • /collections — the Feature Collections available in this API

  • /collections/{collectionId} — the Feature Collection with id collectionId

  • /collections/{collectionId}/schema — the JSON schema describing the GeoJSON features that are returned for the Feature Collection with id collectionId

  • /collections/{collectionId}/queryables — the JSON schema describing the properties that can be used to filter the features in the Feature Collection with id collectionId

  • /collections/{collectionId}/context — the JSON-LD context referenced from the GeoJSON features that are returned for the Feature Collection with id collectionId

These resources are specified by OGC API Features or are ldproxy extensions.

The JSON-LD contexts are the result of early experiments, but are no longer used. The main reasons are that no clients in the testbed needed this information, and no vocabulary or ontology exists for AIXM that could be linked to.  Accessing Features

  • /collections/{collectionId}/items — access to features in the Feature Collection with id collectionId. This request supports a range of query parameters to filter the features or modify the feature representation that is returned (see the example requests below or consult the API definition).

  • /collections/{collectionId}/items/{featureId} — access the Feature with identifier featureId in the Feature Collection with id collectionId.

These resources are specified by OGC API — Features, sub-clauses 7.15 and 7.16.  Accessing Vector Tiles

  • /tiles/WebMercatorQuad/{tileMatrix}/{tileRow}/{tileCol} — access to vector tiles with features organized in layers (one for each airspace class). Only the standard tiling scheme that is used by Google Maps is supported.

  • /collections/{collectionId}/tiles/WebMercatorQuad/{tileMatrix}/{tileRow}/{tileCol} — access to vector tiles with features with a single layer with features from the Feature Collection with id collectionId; only the standard tiling scheme that is used by Google Maps is supported.

There are more resources, but these are the main ones to use in a typical mapping client.

These resources are specified in the draft OGC API — Tiles specification.  Style

  • /styles/{styleId} — access to styles that may have been configured for an API, available in the Mapbox Style encoding. The HTML representation renders a map using the style and the vector tiles.

There are more resources, but this is the main one to use in a typical mapping client.

These resources are specified in the draft OGC API — Styles specification.

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).  Similarities

Both APIs

  • aim at “a simplified machine-to-machine interface to help improve access to NOTAM data;”

  • are Web APIs specified and documented using OpenAPI 3.0;

  • target developers;

  • enable direct NOTAM queries with filtering without the need to locally store all NOTAMs;

  • use SCDS AIM-FNS as the source for NOTAMs;

  • integrate Temporary Flight Restriction (TFR) geometries;

  • publish the NOTAMs as GeoJSON with a very similar schema;  Differences


  • supports authentication through API keys (not relevant for TB-17);

  • supports AIDAP and AIXM 5.1 output formats in addition to GeoJSON (not relevant for Testbed-17);

  • integrates also Special Activity Airspace (SAA) geometries (no publicly available machine readable source for the SAA geometries could be determined); and

  • provides a JavaScript SDK.


  • supports HTML for all resources which enables direct use in a browser by anyone;

  • supports all filtering capabilities of the FAA API plus much richer capabilities through the support for CQL2 and a larger set of queryable properties (i.e. properties that can be used to filter the features in a Feature Collection);

  • conforms to approved and draft OGC API standards;

  • can be used with a growing number of tools, libraries and SDKs that support OGC API standards;

  • improved visualization in map clients through the support for vector tiles; and

  • publishes the NOTAMs also as JSON-FG encoded documents.

4.3.  Challenges and Lessons Learned

Challenges retrieving input data:

  • Finding aeronautical datasets on the FAA websites was challenging.

  • The datasets discovered did not have information about the license under which they can be used.

  • Some data still uses the old AIXM 5.0 standard, some data uses AIXM 5.1, but deviating from the guidance in the AIXM or Digital NOTAM specifications. interactive instruments was not successful in determining some of the FAA conventions (e.g. the NOTAM scenarios and their identifiers). The only reliable approach was to try and analyze the data and reverse engineer the content to determine how the data could be processed.

Challenges executing internal processes:

Challenges providing output data:

  • There was one issue that was raised by the map client (D108) with respect to the feature encoding. The client needs to know the feature type in order to select the appropriate portrayal style for the feature. Since GeoJSON does not have a feature type concept, it was decided to add a new JSON member “featureType” to indicate the AIXM feature type. This member is borrowed from the JSON-FG work and was included in the GeoJSON encoding to support the map client.

  • An advantage of the JSON-FG encoding is the “when” member as it — together with the datetime query parameter — supports that clients provide a time slider without the need to understand the feature schema.

  • JSON-FG also is clearer when geometries are not encoded in WGS 84 lon/lat due to the explicit support for other CRSs. However, the scenarios used in the testbed did not really have a need to use other CRSs.

  • Due to the lack of a referenceable AIXM vocabulary or ontology, it was not possible to enrich the JSON data with semantic annotations using JSON-LD contexts. At the same time, none of the clients was expecting such information, so this was not really an issue in this testbed.

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

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

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

  • 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.  SWIM Flight Position Façade Service

The SWIM Flight Position Façade Service provides flight position data from the Federal Aviation Administration’s (FAA) System Wide Information Management System (SWIM). D105 exposes separately flight data from three different SWIM sources:

These three sources of information provide the complete gate-to-gate story of a flight.

5.1.  Status Quo

SWIM delivers data for the three flight data feeds leveraged for D105 via Solace Java Message Service (JMS) messaging. JMS requires end users to read JMS Description Documents across the services (currently on NSRR), subscribe to a service, consume the data from the service, transform the data into a common language, and then map that data into a database.

Across that process of consuming the data, there are a few distinct challenges:

  • Firstly, the data coming from these feeds is not only limited to flight position data. Therefore, the developer needs to decide early on in the process what data will be needed for their specific use case. Usually the answer is “give me everything” but there are challenges with that approach as typically the end user has a specific use case in mind.

  • The data provided by SWIM is not necessarily in a consistent format. TFMS and STDDS data is provided in the FIXM format whereas SFDPS data is provided in a “custom” data format. These challenges, including the volume of data, make the data difficult to access and make sense of for the common user.

5.2.  Functional Overview

This component adds value for an end user because it provides data from the three SWIM data feeds via a consistent interface, with consistent documentation, and in a consistent format. By leveraging OGC’s APIs, a developer can expect to have a consistent experience with the data from these three feeds, which is not the case when accessing the data via SWIM JMS. Additionally, the façade solves data collection and storage tasks for the user. A user does not have to ingest or maintain a big database to store it all.

As seen on Figure 10, the façade is made of three sets of connectors, parsers, and servers. Each one of the three connectors is designed to communicate with a different SWIM flight feed: SFDPS, TFMS, and STDDS. SFDPS feeds custom XML to its connector, while both TFMS and STDDS feed FIXM data to its respective connectors. Each parser is designed to interpret the data coming from each one of its corresponding flight feeds, and relay flight data encoded in JSON format to its respective Post GIS Server. The API of the façade is designed to communicate with each one of these three GIS servers to retrieve information when requested. Figure 11 shows the end-to-end data flow of D105.

Figure 10 — Structure of the SWIM Flight Position Façade Service