FAQ

The general approach in Europe should be based on the provision of digital data services also known as information services following the ICAO SWIM concept. These services should share AIXM 5.1 encoded data as described in the Eurocontrol supporting material for AMD.

Implementation

Creation of AMD

AMD Features

The role of airports as data originator and validator should increase. Through SWIM, airports can significantly improve timeliness and quality of shared information to the benefit of all involved actors. When moving into SWIM a collaborative and service oriented environment is envisaged.

Implementation

When should states provide aerodrome mapping data?

Suggested guidance for the implementation of AMD provision including the State approach is described in Chapter 3 of this document. AMD should be made available to the aeronautical information services for aerodromes deemed relevant by States where safety and/or performance-based operations suggest possible benefits.

Yes. The mentioned standards are used to drive the data standardization in support of multiple systems (e.g. A-SMGCS, Electronic Flight Bags, and cockpit displays with moving map function).

In section 3.7.2 of ED-99C it is stated that a list of changes is to be provided:. How is this to be handled in terms of the history of the changes applied?

Should this be included in the AMD metadata? 

In case of AIXM 5.1 data sets provision, the list of changes shall be provided in the form of separate file that includes only the changes/updates for a specific features. Also, the information regarding the list of changes should be contained in the lineage section of the metadata, where all process details shall be captured.

Metadata

Creation of AMD

Should the provision of AMD metadata be supported by:

1. a service made available to the user
2. a system for searching the data

In general a MD file that accompanies the AMD is sufficient. In addition it is good practice to support users with search and discovery capabilities for MD. In cases where AMD are provided through services, the SWIM Registry can be used for this purpose.

Is there any description available which explains how the AMD metadata should be provided to the end-user?

How is traceability information as defined by ED-99, DO-272 and ED-119, DO-291 to be provided through the use of AMD metadata?

AMD Features

It is important to note that ICAO refers to the EUROCAE / RTCA AMDB standards in an informative way whereas those standards demand additional requirements. As consequence, the ICAO provisions do not mandate any AMDB publication in the sense of the comprehensive Industry requirements but rather fosters an approach to ensure the usability of State published aerodrome data in the context of AMDB generation. This is more or less facilitated by the level at which the EUROCAE / RTCA requirements (e.g. geometrical constraints) are taken into account by the State data provision.

Standards landscape

What are the ICAO requirements for

1. Aerodrome Mapping Database (AMDB)
2. Aerodrome Mapping Data (AMD)?

The ICAO requirements address AMD whereas the Industry provides comprehensive AMDB requirements. ICAO refers to the Industry EUROCAE / RTCA AMDB requirements on an informative basis. Specific requirements from ICAO Annex 14 and Annex 15 are listed and explained in the Chapter 2 and Chapter 4 - General requirements of this guidance.

Standards landscape

AMD Features

The expressions AMD and AMDB and their difference is explained in Chapter 2 of this document. ICAO defines the AMD as "Data collected for the purpose of compiling aerodrome mapping information for aeronautical uses" and AMDB as "A collection of aerodrome mapping data organized and arranged as a structured data set". It is recommended to use the term AMD if not all Industry AMDB requirements are satisfied. It is recommended to speak about AMD set when providing AIXM 5.1 encoded AMD.

No. The traceability shall be kept as information captured in the lineage section of the metadata provided within each change/update of AMD.

Metadata

What is the relation between AIXM5.1, AMXM and other related formats?

The difference between AIXM 5.1 and AMXM is described in detail in Chapter 4. From an exchange schema point of view both are based on the use of GML. AMXM data can also be provided in mainstream GIS data formats.

Information exchange models

Are there examples and guidelines on how the IDNUMBER, which provides a unique ID through the lifetime of an AMDB feature, should practically remain unchanged in the context of AMD provision (i.e. the IDNUMBER is carried over between feature states)?

From the AIXM 5.1 point of view the details of creating and usage of IDNUMBER (UUID) is contained in AIXM 5 Feature Identification and Reference.

The AMXM UML Model is the normative part of the AMXM. The AMXM UML Model is applicable when it is required to strictly follow ED-99D / DO-272D. This further implies that data formats which do not meet the AMXM UML Model requirements don’t qualify to encode AMDBs as specified by ED-99D / DO-272D.

The AMXM XML Schema is the informative part of the AMXM as provided by ED-119C / DO-291C. It is a possible means of compliance to AMXM UML Model.
Other exchange schemas than AMXM XML Schema can be used to exchange AMDB, for instance using mainstream GIS data formats to comply with the Industry requirements.

It should be noted that ICAO references for the data encoding the related Industry standards on an informative basis. From an ICAO point of view the provision of AMD encoded in AIXM5.1 is a possible means of compliance. The EUROCONTROL supporting material facilitates the data transformations between AIXM 5.1 and AMXM.

Information exchange models

(EU) 2020/469 repeals the "ADQ IR" but confirms the provision of AMD sets. The new IR requires AMD sets to contain aerodrome features based on ISO19100 and follow a data product specification. The  content  and  structure  of  aerodrome  mapping  data  sets  shall  be  defined  in  terms  of  an application schema and a feature catalogue.

Yes, this guidance material provides European reference implementation for aerodrome mapping provision. More information can be found at EUROCONTROL AIM Toolkit

https://www.eurocontrol.int/project/aeronautical-information-management-toolkit 

What are the possible usages of AMD in a State?

There are number of possible usages of AMD not just on a State level but also in different parts of industry.

Several possible usages for all industry participants are described in Chapter 5 of this document.

If AMD is provided, the availability shall be clearly stated in the State AIP. It is not yet stated where this information shall be published in the AIP.  In cases where aerodrome data are provided through information services, the SWIM Registry can be used for this purpose.

Currently there is no  AMD set specification. The aeronautical data catalogue contains requirements. Creation of a specification is considered as potential future work.

Further support for AMD provision is available in this guidance.

Standards landscape

AMD Features

This guidance material defines and describes several approaches for AMD implementation including State, ANSP and Aerodrome initiation. Each approach is specified and described in Chapter 3.

Setting up collaborative workflow management is to be envisaged. However this needs to be adapted to each particular case.

The purpose of vertical structures in AMD is to capture all objects with the point, line or polygon geometry and specific height in the vicinity of the aerodrome. Some of these vertical structures can based on specific criteria classified as Obstacles in TOD data set.

No. TOD and AMD are two separate digital data sets, where each contains different type of data. The only information they have in common are the Vertical Structures (AMD) and Obstacles (TOD). Some of Vertical Structures from AMD can be classified as Obstacles in the TOD.

Every Digital NOTAM event specification requires specific AMD features and additional aeronautical information. For example the Digital NOTAM scenario Runway Closure requires AirportHeliport, Runway, RunwayDirection and RunwayElement where only RunwayElement is an AMD feature as specified by the Industry standards. The encoding of AMD in AIXM5.1 adds the information needed.

Yes. AMD data can be transformed between AIXM 5.1.1. and AMXM. The mappings thereto are provided as part of this guidance..

AMD Features

Currently (2020) States are not providing AMD since not a priority. The topic appears however on the planning of States in terms of data set provision but requires more specificity in terms of the data to be provided. This guidance aims at supporting the coding aspects. Specifying an AMD set remains a future topic to be discussed.

Why should a State provide AMD if AMDBs are already provided commercially?

• facilitation of AMDB creation trough provision of AIXM5.1 encoded AMD in accordance with State applicable data quality requirements exceeding the commercially available AMBD quality requirements (e.g. horizontal accuracy);
• facilitation of collaborative data exchange and information management workflows that include various actors (e.g. airports).

The State should specify individual aerodromes (as described in ICAO Annex 14, Chapter 2) for the provision of AMD where safety and/or performance-based operations suggest possible benefits.