FAQ

What would be a general approach for the European space to harmonize aerodrome mapping data provision?

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

What is the role of airports in the provision of aerodrome mapping data?

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?

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.

Are the ED-99, DO-272 and ED-119, DO-291 standards from EUROCAE/RTCA implemented and used?

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 set 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 a service made available to the user or a system for searching the data?

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

Is there information available which explains how the AMD metadata should be provided?

Metadata

Are aerodrome mapping ICAO Annex 14 and ICAO Annex 15 covering all the requirements for AMD as expressed by EUROCAE/RTCA?

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 Aerodrome Mapping Database (AMDB) and 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.

General requirements

What is the difference between AMD and AMDB, as defined in ICAO SARPs?

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.

Does ED-99C section 3.6 (Data Traceability) require a time/historical perspective?

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?

AIXM 5.1 is used to encode AMD as aeronautical information. AMXM is specified by EUROCAE/RTCA using a GIS layered approach to encode AMDBs.

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.

Which AMXM parts are normative and when? 

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

Is there a European reference implementation for aerodrome mapping provision?

This supporting material can be used as an input for European reference implementation of aerodrome mapping data provision.

Is there example data for AIXM available?

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.

Where to announce the availability of AMD?

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.

What specifications should a State use to develop an AMD set?

Currently there is no  AMD set specification. This supporting material can be used.

Standards landscape

AMD Features

How to start AMD implementation?

Several approaches for AMD implementation including State, ANSP and Airports are envisaged.

Are there any indications for a standard workflow to exchange aerodrome mapping data between aerodromes and AISP?

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

What is the purpose and intended use of the vertical structures, especially lines, polygons and their height? 

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.

What is the relation between terrain, obstacle and aerodrome mapping data? Are the terrain and obstacles part of the AMD set / AMDB?

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.

How can AMD features or properties (e.g. surface type) be obtained which cannot be derived from the orthophoto?

What AMD is required for the Digital NOTAM and digital briefing, and why? 

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.

Is it possible to extract an AMD from existing data models in order to continue maintaining data in existing data models, and be able to exchange AMD?

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

AMD Features

Are there any example of existing AMD provided by a State?

This appears in the planning of States in terms of data set provision but requires more specificity in terms of the data to be provided. This supporting material aims at supporting the encoding aspects in AIXM 5.1.1. 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).

What aerodromes should be eligible for provision of AMD?

States 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.

Why is there a need to have an AIXM 5.1.1 GuidanceLineMarking feature to code for the geometry of the runway exit as opposed to providing the line geometry directly as part of the AIXM 5.1.1 GuidanceLine feature?

Both AIXM 5.1.1 features GuidanceLineMarking and GuidanceLine allow for the coding of geometry. However these geometries may be different as explained further below.

The mapping between the AMDB RunwayExitLine and the AIXM5.1.1 target feature is based on the overall principle that AMDB data capture visible features in the real world.

Visible features correspond to the notion of markings in AIXM 5.1.1. This also implies that the captured geometries may not connect spatially due to interruptions of the painted markings. Summarizing: the purpose is to digitize what is visible. The geometries may appear disconnected.

In the AIXM 5.1.1 coding space the AIXM GuidanceLine feature is the operational guidance line which is a virtual line that ensures connectivity between the geometries of connecting guidance lines to create a graph (in GIS terms a linear topology) that can be traversed by an algorithm (e.g. for taxiway routing). Summarizing: the purpose is to digitize the logical path where the aircraft can roll. The geometries appear connected.

In addition, specifically for guidance lines on the runway this may lead to more spatial differences in the geometries captured. Indeed, in AIXM, since the AIXM 5.1.1 GuidanceLine is a “topological” feature, it connects with the runway centreline. However, the marking of a runway exit line is according to Annex 14 parallel (offset of 60 cm) to the runway centreline. That adds to the reason why the AMDB RunwayExitLine capturing the painted marking is mapped to the AIXM 5.1.1 GuidanceLineMarking feature and not to the AIXM 5.1.1 GuidanceLine feature.

Why are the runway centerline marking lines (i.e. curves) whereas per the ICAO ADC they are polygons?

This is indeed a discrepancy which stems from the AMDB industry standards where the runway AMDB PaintedCenterline feature is captured as a line connecting the thresholds along the runway centerline markings. As such in the AMDB context the name given “PaintedCenterline” seems to indicate that it is a marking that is needed whereas it is in fact a virtual line that is captured. In the mapping it was opted to maintain the line geometry to satisfy the Industry requirements but mapped to the AIXM 5.1.1 RunwayMarking feature with location ‘CL’.