v1.0.6

How to read the supporting material

Owned by WILSON Scott
Last updated: 2021 Apr 14 by VAN DER STRICHT Sam

This page explains how to read the supporting material.



Features

The main page includes a Features table that provides quick link to the various ED-99/DO-272 features and the corresponding AIXM and AIRM pages. 

Each ED-99/DO-272 feature has a dedicated page that details

  • correspondence
  • encoding

Correspondences

The section contains one page for each feature detailed in ED-99/DO-272. These contain the following details:

  • list the information items from the “User Requirements for Aerodrome Mapping Information” (EUROCAE ED-99 / RTCA DO-272).
  • detail which elements (classes, attributes and associations) to use in AIXM 5.1.1. to meet the requirements of the EUROCAE ED-99 / RTCA DO-272 standard.
  • give the semantic correspondences of the information items to the ATM Information Reference Model (AIRM).

Definitions:  Each entry starts with the latest ED-99/DO-272 definition of the feature and the AIXM 5.1.1 definition for the corresponding root feature.

Correspondence table with the following columns and rows:


ED-99/DO-272A | B | C | DAIXM 5.1.1AIRM 1.0.0
1

The first row gives the feature name in ED-99/DO-272

An 'x' is used to show if the feature appears in that version of the specification.

The first row gives the name of the AIXM feature that should act as the root for the correspondence.

Extension

Some correspondences are not possible using only AIXM 5.1.1. The AIXM 5.1.1 extensions are used to cover these items. 

Formatting

This column uses the AIXM Editorial conventions using bold and underline to highlight key components of the AIXM.

The urn of the corresponding AIRM data entity. Sometimes two urns are given as it is necessary to restrict the interpretation of the data entity.

The AIRM is the reference vocabulary that helps to connect different models and to show the relations between different terms. Its data entities can be used by service architects, information/data architects and system implementers.

2

Subsequent rows give the attributes of that feature in the order that they appear in ED-99D/DO-272D.

An 'x' is used to show if the attribute appears in that version of the specification.

Subsequent rows give the corresponding AIXM attribute. Where these are from a feature that is related to the root feature, the exact path is given. The syntax used is:

  • <property name>.<feature name>.<property name> e.g. associatedAirportHeliport.AirportHeliport.locationIndicatorICAO.
  • square brackets are used to give conditions on the values of a property e.g. Runway[type=‘FATO’]. This is important as AIXM is often more general that ED-99/DO-272.

  • resultOfQuery is used as shorthand in some correspondences. The query (QUERY=) should be detailed elsewhere in the table. Queries are used where there is no relationship between features in AIXM and no path can be established - the query, in effect, bridges the gap.

Notes:

  • some correspondences are to metadata fields.
    • For example, ED-99/DO-272’s ‘vres’ attribute maps to a metadata field and not to an attribute that is directly present in the corresponding AIXM 5.1.1 feature. Such correspondences begin with “gmd:Metadata”. 
  • AIXM 5.1.1’s temporality model makes use of “TimePrimitive”. This is expanded in the AIXM XML Schema using GML constructs. In order to better explain the correspondence, the GML constructs are used in the mapping. These begin with “gml:” e.g. “gml:TimePeriod”.
  • notes are included where relevant to the correspondence.

Extension

Some correspondences are not possible using only AIXM 5.1.1. The AIXM 5.1.1 extensions are used to cover these items. Hints at extension appear in italics in the tables.

The urn of the corresponding AIRM entity or property.

Notes on specific feature correspondences

  • In the case of some features detailing guidance lines and markings (e.g. Land and Hold Short Operations) a choice of mapping approach was possible. The option adopted was to use the marking element as main root of these mappings rather than e.g. the centreline point. This has a practical benefit and is more inline with the philosophy of ED-99/DO-272.

  • The FrequencyArea correspondence mapping is a difficult mapping case. The most correct mapping is to use GroundTrafficControlService and RadioCommunicationChannel. At first glance this seems less logical than using RadioFrqeuencyArea as the root of the mapping. However, the RadioFrequencyArea was intended to provide radio signal coverage limitations for navaids and ATC frequencies, not to designate the area in which a particular frequency has to be used. The AIXM Service concept was intended for that.

  • The feattype mapping is noted as ‘can be implied’. A query will need to be performed in order to fill out the correct value. The feattype enumeration mapping can be used to define the correct value.

Encoding

The supporting material includes a page for each feature that:

  • gives support for encoding the feature
  • gives an AIXM 5.1.1 of the encoding
  • The purpose of the examples is to provide AIXM 5.1.1 encodings.
  • The digitized examples are mostly reflecting real features of the Prague Airport, except when there was no feature of that type available, in which case a fictitious example is used to show the AIXM 5.1.1 encoding.
  • Within all provided features several common attributes are missing in the AIXM 5.1 data model but are part of the AIXM 5.1.1 extension.


Each page contains:

General part:

Short introduction to the feature and reference to the Data Catalogue based on type of required geometry.

AMD encoding:

Covers the details of the encoding of listed AIXM 5.1 features.

AIXM 5.1:

Explains mapping of ED-99 feature to the AIXM 5.1 data model.

Geometry and GML considerations parts explain the usage of geometry information in the process of feature encoding followed by visualization of specific feature as AMD.

Time explains based on what coding rules should the feature be created. 

AIXM 5.1 features describes the mapping of specific feature in AIXM 5.1 with associated links to the AIXM 5.1 page.

Coding examples are separated into two sections: the first coding example displays the structure of the attached xml file, while the second coding example displays full AIXM 5.1 identified feature as included in the xml example.

Following part of AIXM 5.1 part provides a link to Download feature in form of attached xml file.

Additionally if the specific feature is missing some properties/attributes that are not in the scope of AIXM 5.1, the link to the Aerodrome Mapping Data Exchange specific feature page is provided with a list of properties that are part of AIXM 5.1.1 extension.

The correspondence tables make use of the extension information where appropriate. The extensions are shown in italic.

Notes on specific feature visualizations

  • Pictures provided as background were not used for digitizing of features.
  • Pictures showing feature geometry may display a magenta colored vertex or green colored vertex of the geometry. This has no particular meaning.
  • Picture background images may be slightly shifted in relation to the displayed feature. This is caused by resolution and differences between the satellite image (background) and measured feature geometry.
  • For completeness reasons some fictitious features/attributes where provided. These are clearly indicated.

Enumerations, codelists and datatypes

The Enumeration and codelists section contains one page for each enumeration/codelist detailed in ED-119/DO-291. These contain the following details:

Correspondence tables with the following columns:

ED-119/DO-291

AIXM 5.1.1

The first row gives the codelist/enumeration name from the relevant version of ED-119/DO-291.

The first row gives the name of the AIXM codelist that should act as the root for the correspondence.

Subsequent rows list the possible values.

Subsequent rows give the corresponding value.

Notes on specific enumeration and codelists correspondences

  • ED-119/DO-291 uses a mixture of codelists and enumerations. However, AIXM 5.1.1 only uses codelists. These are open enumerations which means that if there is not direct mapping from the ED-119/DO-291 value, it is possible to use the construct “OTHER:UPPER_CASE_VALUE”. This has been used in several mappings.
  • In one case, surftyp, more than one AIXM 5.1.1 codelist is required in order to complete the mapping.
  • In one case, status, a ED-99/DO-272 attribute can map to two AIXM 5.1.1 codelist.
  • ED-99C/DO-291C added a “Reserved” value to many codelists. This is not mapped as it is a convention to show that certain numbers are not used in codelists, typically the value occurring at position [0].

Analysis of base types

The Aeronautical Information Exchange Model (AIXM) version 5.1.1 makes use of the ISO 19100 series of standards. This includes the uses of base-types (CharacterString, Boolean, Real) and the use of a specific set of stereotypes (e.g. <<Feature>>). The AIXM XML Schema makes use of ISO 19136 (GML) for geometries and ISO 19115 for its metadata encodings.

ED-99/DO-272 also talks about Features. The ED-119/DO-291 document, which provides the “interchange standards for terrain, obstacle, and aerodrome mapping data”, makes use of the ISO 19100 series of standards for attribute types.

These similarities mean that it is not necessary to perform a detailed analysis of the base types used in the models.

Metadata

This page provides summary of metadata information requirements put by several publications. 

Temporary change encoding

This shows how to use the temporality model for temporary changes within the AIXM 5.1 information exchange model. 

Status: Published