Page tree
Skip to end of metadata
Go to start of metadata

Why necessary

The interoperability of systems using AIXM is closely related to the definition of a use cases supported by these systems.

By design, AIXM 5.x has the ability to support a variety of use cases, such as data origination, charting, static data coding, Digital NOTAM, etc. Such a board range of applications imposed a certain openness, which is embedded in the AIXM specification. For example, there are no mandatory feature properties (in order to allow the coding of "differences"), no predefined feature keys (both natural and artificial keys can be used, depending on the context), etc.

For a specific use case, such as provision by States of the ICAO Data Sets, the AIXM flexibility needs to be constrained with rules that limit the coding possibilities and ensure that the data is actually fit for the intended use. The objective of the interoperability rules identified here is to ensure that the end users, in particular data integrators, are able to seamlessly merge the digital data coming from different States. These rules also ensure that States can exchange between themselves the AIP and the other digital data sets specified by ICAO Annex 15.

Similar to the data coding rules, most of the interoperability rules can also be formulated as AIXM Business Rules, using SBVR. This enables to verify a particular data set for compliance with these rules, both on the data provider and on the data user side.

Use Cases

State publishes Data Set

Actors: State AIS, Neighboring State AIS

Use cases:

  • (optional) State AIS collects latest published data sets from Neighboring State AIS
  • (optional) State AIS coordinates data set changes with Neighboring State AIS
  • State AIS provide initial data set (it is possible not all features are included in this initial release)
  • (conditional) State AIS provide AIRAC updates of the data set
  • (conditional) State AIS provide non-AIRAC updates of the data set
  • (optional) State AIS extend data set with new features

Issues that require special attention:

  • data with shared responsibility
    • Airspace borders that make reference to State or other natural or administrative borders
    • waypoints on the border
    • cross-border route segments
  • neighboring State data
    • navaids used for procedures that extend in the the neighboring State airspace
    • other neighboring State data included “for convenience”

Data integrator collects Data Set

Actors: Data Integrator

Use cases:

  • receive initial data set from a State
  • receive AIRAC updates from a State
  • receive non-AIRAC updates from a State
  • receive extended data set from a State


Issues that require special attention:

  • Minimal list of attributes that are expected to exist (nil Reasons?)
  • Harmonised encoding of certain data
  • Mixed versions of AIXM
  • Data duplicates, conflicts (such as the same waypoint having different coordinates), gaps, etc.
  • data with shared responsibility (if the data is not coordinated, the same feature could have two different UUID in the two or more data sets)
    • Airspace borders that make reference to State or other natural or administrative borders
    • waypoints on the border
    • cross-border route segments
  • neighboring State data
    • navaids used for procedures that extend in the the neighboring State airspace
    • other neighboring State data included “for convenience”


Rules and Recommendations

The following topics are subject to specific interoperability rules

Editorial conventions

The rules (“shall” statements) provided in this section must be applied by all Data Set providers in order to ensure that the (downstream) data users get the data necessary for the intended use of this data set and are able to seamlessly merge the data from different States.

The recommendations (“should” statements) provided in this section are meant to improve the usability of the Data Sets and to facilitate their use. Therefore, providers of Data Sets are strongly encouraged to also comply with these recommendations.

This section also contains some explicit permissions (introduced by the word “may”), which usually include subsequent rules or recommendations. If one of these permissions is actually used in the provision of a Data Set, the subsequent rules and recommendations become applicable to the data set.

  • No labels