v1.0.6

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

This page explains how to read the various correspondence tables.

Correspondences for features

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

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:


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. 

The urn of the corresponding AIRM concept. Sometimes two urns are given as it is necessary to restrict the interpretation of the concept.
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 concept.

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

Correspondences for enumerations and codelists

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.

  • No labels

Status: Published