/
[AIXM-553] Change in the association of TaxiwayElement & Taxiway

[AIXM-553] Change in the association of TaxiwayElement & Taxiway

ID:

AIXM-553

target version:

AIXM 5.2

version:

1.0

last updated:

08 AUG 2022

status:

APPROVED


Description

Multiplicity of Taxiway in association to TaxiwayElement is changed from 0..1 to 0..*.

Rationale for change

See https://aixmccb.atlassian.net/browse/AIXM-510

Based on the examples provided in the Jira issue, it was identified that a TaxiwayElement may be associated with several Taxiways (e.g. intersecting ones). The proposed change will also align AIXM 5.2 implementations with AMDB standard ED-99/DO-272.

It is proposed that the multiplicity of a TaxiwayElement association on the side of Taxiway is changed to 0..* (0 to many).

Impact assessment

[FWD_1:1] No data mapping is necessary and no data loss occurs when data is exchanged from a system (A) that uses AIXM 5.1.1 for output towards a system (B) that uses AIXM 5.2 for input.

[BWD_MAP_LOSS] Data mapping is possible, but some data would be lost (or converted into Notes) when data is exchanged from a system (B) that uses AIXM 5.2 for output towards a system (A) that uses AIXM 5.1.1 for input.

Change Proposal details

In the UML model:

  • Change TaxiwayElement ‘describesPartOf’ Taxiway association:
    • .* on the Taxiway side.

The following UML class diagram shows the modified association multiplicity:

Mapping AIXM 5.1.1 to AIXM 5.2 (forward)

Not applicable

Mapping AIXM 5.2 to AIXM 5.1.1 (backward)

The following algorithm shall be applied:

[MAPC-05] The following algorithm shall be applied.

For each TaxiwayElement that has more than one associatedTaxiway element.

From the four backward mapping options discussed for this case, the first one (discard the additional occurrences) is not really possible due to the importance of the data that is mapped. The use of an extension is straightforward and does not need any further details.

The 3rd option (create copies of the ‘source’ for each additional ‘destination’) and the 4th option (backward mapping of the additional occurrences into a Note) are detailed in order to provide complete descriptions of these cases and conversion options.

3rd option) The following mapping algorithm by multiplying the source class is proposed:

  • Identify the occurrence of the associatedTaxiway that is preserved
  • For each additional occurrence of the associatedTaxiway element:
    • Remove the associatedTaxiway element
    • Create a copy of the TaxiwayElement class, with exactly the same child elements, except for:
      • gml:identifier, which gets as value a concatenation of the gml:identifier of the source (TaxiwayElement), followed by a separator (“-”) and the gml:identifier of the destination (Taxiway) that is mapped;
      • associatedTaxiway which gets only one occurence (that one that is being mapped);
      • Note that the gml:id might also need to be replaced, if the result of the conversion algorithm is an AIXM 5.1(.1) file, to avoid a conflict of XML ID values.

4th option) The following mapping into Note algorithm is proposed:

  • Identify the occurrence of the associatedTaxiway occurrence of that is preserved and remove the other associatedTaxiway elements;
  • Add an annotation.Note associated with the owner class having
  • purpose=“OTHER:BACKWARD_MAPPING”;
  • LinguisticNote.note=”associatedTaxiway[1].(Taxiway): <associatedTaxiway).xlink:href>;associatedTaxiway[2].(Taxiway): <associatedTaxiway).xlink:href>; etc.”
    • “[1]”, “[2]” indicate that this needs to be repeated as many times as necessary to cover all occurrences that are not preserved;
  • propertyName=”associatedTaxiway”.

Mapping example

(Note: for mapping test data see: https://github.com/aixm/mapping_52_511/tree/master/AIXM-xxx

AIXM InputAIXM Output