ID:

AIXM-406

target version:

AIXM 5.2

version:

1.0

last updated:

15 MAY 2019

status:

APPROVED


Description

Add a new association from CheckpointINS to AircraftStand.

Rationale for change

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

Aircraft parking/docking charts typically provide a table with the INS coordinates for each aircraft stand. In AIXM 5.1(.1), it is possible to code separately:

  • the INS checkpoint (see CheckpointINS class) and its position as direct association to ElevatedPoint
  • a "location" for each AircraftStand 

However, it is not possible to indicate that the CheckpointINS is actually located at an aircraft stand or that the aircraft stand location is actually an INS checkpoint. This can lead to duplicate coding of INS positions, both as CheckPointINS and as AicraftStandLocation.

To avoid this duplicate coding, a direct association between an CheckPointINS and AircraftStand is necessary.

According to the ICAO Annex 14, Volume I, (2.5.4) "The geographical coordinates of each aircraft stand shall be measured and reported to the aeronautical information services authority in degrees, minutes, seconds and hundredths of seconds." Although this does not explicitly indicate that the stand position is used as an INS point, Appendix 5 indicates that the "aircraft stand points/INS checkpoints" shall be surveyed with an accuracy of 0.5 m.

Thus, it cannot be excluded that an AircraftStand has a position which is not formally declared as an INS checkpoint or that it also has an associated INS checkpoint with a slightly different longitude/latitude value. Therefore, a direct association between AircraftStand and CheckPointINS would not replace the possibility to specify directly a location for an AircraftStand, which is not an INS position. Similarly for an INS position which is not an AircraftStand.

Impact assessment

There is no impact on existing implementations as the current AIXM 5.1(.1) data remains fully valid against AIXM 5.2.

AIXM 5.2 files that use the new attributes would be invalid against the AIXM 5.1.1 schema and will need to be converted, applying one of the options specified in the mapping rules.

Change Proposal details

In the UML model, add a new association as follows:

  • CheckpointINS ‘isLocatedAt’ AircraftStand
    • 0...1 on the CheckpointINS side, 
    • 0…1 on the AircraftStand side, “location” role name, definition = “The INS checkpoint latitude and longitude coordinates, which are the same as for the aircraft parking stand position.”

This is new association is represented in blue on the UML class diagram.

Mapping AIXM 5.1.1 to AIXM 5.2 (forward)

Not applicable.

Mapping AIXM 5.2 to AIXM 5.1.1 (backward)

[MAPC-02] In general, the mapping case for a new association is applied. However, in most situations the position of the AircraftStand needs to be recuperated and copied as a position of the CheckpointINS. From the three backward mapping options applicable in the nominal case, the first two (discard the value or use an extension) are straightforward and do not need any further details. The 3rd option (backward mapping into a Note) is detailed in order to provide a complete description of this case and its conversion option. The following mapping into Note algorithm is proposed:

  • For each CheckpointINS that has a location element:
    • add an annotation.Note to the CheckpointINS with:
      • purpose=“OTHER:BACKWARD_MAPPING”;
      • translatedNote.LinguisticNote.note=”isLocatedAt AircraftStand with xlink:href: <location.xlink:href>; 
      • propertyName = ”position”
    • In addition, if it does not have a position descendant with an assigned value, then retrieve the AircraftStand feature instance identified through the isLocatedAt.@xlink:href value and copy its position as position for the CheckpointINS;
    • Remove the location element.


Mapping example

Mapping example to be added...


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

AIXM 5.2AIXM 5.1(.1)
<pre>
  ...</pre>





<pre>
...</pre>