[AIXM-492] Add MOCA and MEA to SegmentLeg

Description

The possibility to code a minimumObstacleClearanceAltitude is extended from DepartureLeg to all SegmentLegs, together with a minimumObstacleClearanceHeight. The DepartureArrivalCondition is renamed SegmentLegAltitudeCondition and it is re-associated with SegmentLeg instead of just DepartureLeg.

Rationale for change

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

Minimum obstacle clearance altitude/height is defined by ICAO as follows: “The minimum altitude/height for a defined segment that provides the required obstacle clearance”.

In the current model, minimum obstacle clearance altitudes can be encoded only for DepartureLeg using the dedicated minimumObstacleClearanceAltitude attribute. However, it is not very common to have MOCA values specified for departure segments.

Instead, it is much more common to have MOCA values specified for Arrival and Approach legs, but there is no solution for the encoding of such values in the current AIXM version. Therefore, minimumObstacleClearanceAltitude and minimumObstacleClearanceHeight are proposed to be added in the SegmentLeg and inherited by all its specialisations.

For DepartureLeg, it is possible to specify minimum en-route altitudes and crossing altitudes at the end of the segment using the association to DepartureArrivalCondition. This can be further refined by specifying aircraft engine types (jet versus propeller, for example) through the association to AircraftCharacteristic.

Considering the name of the class that includes both “Arrival” and “Departure”, this association was also intended for arrival and initial approach legs. The name of the DepartureArrivalCondition class is misleading as its attributes are limited to altitude values. The crossing altitudes at the end of the segment may also be applicable to other procedure legs.

Therefore, it is proposed that this class is renamed into SegmentLegAltitudeCondition and it is associated with SegmentLeg directly, from which the association will be inherited to all types of legs. Also, some of the attribute definitions need to be corrected as they refer to the RoutePortion, which was probably a copy/paste error in the original model.

Impact assessment

[FWD_MAP_1:1] Data mapping is possible 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.

Mapping AIXM 5.1.1 to AIXM 5.2 (forward)

[MAPC-00] For each DepartureLeg that has a condition/DepartureArrivalCondition element:

• rename the condition element into altitudeCondition
• rename the DepartureArrivalCondition element into SegmentLegAltitudeCondition

Mapping AIXM 5.2 to AIXM 5.1.1 (backward)

[MAPC-02] For each DepartureLeg, ArrivalLeg, ArrivalFeederLeg , FinalLeg , InitialLeg , IntermediateLeg , MissedApproachLeg that has minimumObstacleClearanceHeight from the three backward mapping options applicable in this 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:

• Remove the minimumObstacleClearanceHeight element
• Add an annotation.Note associated having
  • purpose=“OTHER:BACKWARD_MAPPING”;
  • translatedNote.LinguisticNote.note=”minimumObstacleClearanceHeight:<value of the minimumObstacleClearanceHeight>”

[MAPC-02] For each ArrivalLeg, ArrivalFeederLeg , FinalLeg , InitialLeg , IntermediateLeg , MissedApproachLeg that has minimumObstacleClearanceAltitude, from the three backward mapping options applicable in this 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:

• Remove the minimumObstacleClearanceAltitude element
• Add an annotation.Note associated having
  • purpose=“OTHER:BACKWARD_MAPPING”;
  • translatedNote.LinguisticNote.note=”minimumObstacleClearanceAltitude: <value of the minimumObstacleClearanceAltitude>”

[MAPC-00] For each DepartureLeg that has an altitudeCondition/SegmentLegAltitudeCondition element:

• rename the altitudeCondition element into condition
• rename the SegmentLegAltitudeCondition element into DepartureArrivalCondition

[MAPC-02] For each ArrivalLeg, ArrivalFeederLeg , FinalLeg , InitialLeg , IntermediateLeg , MissedApproachLeg that has an altitudeCondition/SegmentLegAltitudeCondition, from the three backward mapping options applicable in this 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:

• Remove the altitudeCondition and the child SegmentLegAltitudeCondition elements
• Add an annotation.Note associated having
  • purpose=“OTHER:BACKWARD_MAPPING”;
  • translatedNote.LinguisticNote.note=”altitudeCondition.minimumEnrouteAltitude: <value of the minimumEnrouteAltitude> <value of the minimumEnrouteAltitude.uom>; altitudeCondition.minimumCrossingAtEnd:<value of the minimumCrossingAtEnd> <value of the minimumCrossingAtEnd.uom> <value of the minimumCrossingAtEndReference>; altitudeCondition.maximumCrossingAtEnd:<value of the maximumCrossingAtEnd> <value of the maximumCrossingAtEnd.uom> <value of the maximumCrossingAtEndReference>”

Mapping example

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

AIXM Input	AIXM Output