Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

ID:

AIXM-473

target version:

AIXM 5.2

version:

1.0

last updated:

04 AUG 2021

status:

PROPOSED

Table of Contents
printablefalse

Description

The ApproachCondition class is enhanced with additional properties (landingPrecisionCategory, satelliteApproachType, specialAuthorisation, minBaroVNAVTemperature, maxBaroVNAVTemperature, stepDownFix association to TerminalSegmentPoint) in order to allow coding of sets of minima for the same FinalLeg. As a consequence, the landingSystemCategory,  guidanceSystem and minimumBaroVnavTemperature are removed from the FinalLeg. The multiplicity of the association with the Minima class is increased and the association to Aircraft Characteristics is moved at the Minima class level. The properties of the Minima class that support the coding of various types of minima are refactored, separate attributes being introduced for the coding of OCA/OCH, MDA/MDH and DA/DH. Separate attributes are introduced in order to code military specific minima, runway visual range and the militaryMinima is replaced with a militaryCeiling attribute.

Rationale for change

See https://aixmccb.atlassian.net/browse/AIXM-308, https://aixmccb.atlassian.net/browse/AIXM-119, https://aixmccb.atlassian.net/browse/AIXM-306

Several ‘minima lines’ may appear on an Instrument Approach Procedure chart. According to ICAO PANS-OPS, these can have two meanings:

  • either that more than one Instrument Approach Procedure is represented on the same chart, which can occur when “when the procedures for the intermediate approach, final approach and missed approach segments are identical”;
  • or that additional sets of minima are specified for the same Instrument Approach Procedure “to cater for specific aircraft dimensions, improved missed approach performance and use of autopilot in Category II approach when applicable.

In the current model (see the first UML class diagram further down in this document), the Minima are associated with the FinalLeg, through the intermediate of the ApproachCondition. Therefore, the possibility to specify several sets of minima for the same Instrument Approach Procedure is practically limited by the properties (associations and attributes) offered by the ApproachCondition class:

  • finalApproachPath - allows distinguishing between straight-in, circling, etc.)
  • climbGradient - which allows to specify minima for specific missed approach gradients (such as 2.5%, 4.0%, etc.)
  • requiredNavigationPerformance - which allows to specify different minima for specific RNP/PBN performance characteristics
  • association with AircraftCharacteristics - allows different minima to be specified to each aircraft category;

The first three bullet points typically correspond to “minima table lines”, while the aircraft landing category (coded with AircraftCharacteristics) corresponds to “minima table columns”. The association with AircraftCharacteristics means that the ApproachCondition needs to be coded separately for each aircraft landing category that has a different set of minima.

The Minima class has attributes that can be used for the coding of various types of Minima (OCA/OCH, MDA/MDH, DA/DH) and their specificities, such as military, RVR required, etc.

The following diagram shows the classes, properties and lists of values from the current AIXM 5.1.1 model, which are relevant when discussing the rationale for this change proposal:

The following issues affect the usability of the current ApproachCondition model for coding the real world data:

  • it does not allow to provide additional minima lines for specific ILS landing performance
    • the FinalLeg.landingSystemCategory has values such as: NON_PRECISION, ILS_PRECISION_CAT_I, ILS_PRECISION_CAT_II, etc. However, this means that the FinalLeg would have to be duplicated if a procedure has different minima lines for CAT I/CAT II/CAT II with autopilot/etc.;
  • for satellite based approaches, it does not allow distinguishing between the different types of minima based on later/vertical guidance, such as LPV/LNAV/etc.
    • the FinalLeg.guidanceSystem has values such as VOR, ILS, LNAV, LNAV_VNAV, LP, LPV, PAR, MLS, etc. However, this means that the FinalLeg would have to be duplicated if a procedure has two different sets of minima, for example for LPV and LNAV approaches. In addition, the list of values CodeFinalGuidanceType is a large duplicate of the InstrumentApproachProcedure.approachType. As the type of procedure is in fact the same as the type of approach for the final leg, once the values that identify satellite approach types  for minima lines are moved in the ApproachCondition, the guidanceSystem attribute is no longer necessary.
  • it does not allow to provide additional minima that depend on step-down fixes. According to PANS-OPS, Volume I, Part 1, 5.2.5.1: "A stepdown fix may be incorporated in some non-precision approach procedures. In this case, two OCA/H values are published:
    a)         a higher value applicable to the primary procedure; and
                b)         a lower value applicable only if the stepdown fix is positively identified during the approach
    ". In the current model, the TerminalSegmentPoint.role attribute can be used in order to indicate that a SignificantPoint is a stepdown fix. However, this would require the coding of partially duplicate final SegmentLeg for the same InstrumentApproachProcedure;
  • it does not allow to indicate that the minima is subject to special authorisation, which is a safety critical information;
  • it does not support the coding of a maximum temperature for uncompensated barometric VNAV approaches. In addition, the current minimumBaroVnavTemperature is located at the level of the FinalLeg, which would create difficulties for coding when other minima lines (such as LNAV only) remain valid outside the temperature range;
  • if different minima “columns” are specified, typically for different aircraft categories, the model requires a duplication of the ApproachCondition;
  • the attributes of the Minima class do not allow to code both OCA/OCH values and DA/DH values;
  • It is not possible to code minima values that are associated with both visibility and RVR requirements because the current mandatoryRVR is just a yes/no value;
  • the militaryHeight attribute has a misleading name and an unclear definition. In practice, it is used to code a minimum height of the cloud base that conditions the use of the minima for military aircraft;
  • there exist military specific minima values, for the same aircraft landing categories as for civil aircraft. THe model is missing a “military minima” attribute to indicate that the minima are specific for military operators.

A related issue concerns the guidanceSystem attribute of the FinalLeg, which is an unnecessary duplication of the approachType attribute of the InstrumentApproachProcedure, as the type of procedure is the same as the final approach type. The two lists of values are almost identical, which is also an indication of the duplication.

In order to correct these model issues and limitations, the ApproachCondition needs to be extended with additional properties that allow it to identify a set of minima (presented as a “minima line” in the minima tables of Instrument Approach Charts). As a consequence, the current FinalLeg properties that identify “minima lines” (guidanceSystem and landingSystemCategory) need to be removed from the model. The Minima class needs to be completely reviewed in order to allow coding multiple types of minima values and their associated conditions without multiplying the ApproachCondition.

Impact assessment

When providing AIXM 5.1(.1) data to AIXM 5.2 systems, the forward mapping rules described further in this document may be applied.

When receiving data from AIXM 5.2 implementations, the backward mapping rules described further in this document may be applied in order to recuperate the data. These conversion rules are based on the current AIXM 5.1(.1) workarounds.

Change Proposal details

In the UML model:

  • In the FinalLeg class:
    • Delete the minimumBaroVnavTemperature attribute
    • Delete the guidanceSystem attribute
    • Delete the landingSystemCategory attribute
  • Delete the <<codelist>> CodeFinalGuidanceBaseType and the <<datatype>> CodeFinalGuidanceType
  • In the ApproachCondition class:
    • add a new landingPrecisionCategory attribute defined as “The precision of the final segment guidance system to which the associated Minima refer”, data type CodeApproachPrecisionCategoryType
    • add a new satelliteApproachType attribute, defined as “The type of the final segment vertical and/or horizontal guidance in case of a GNSS procedure, to which the associated Minima refer”, data type CodeSatelliteApproachType
    • add a new specialAuthorisation attribute defined as “The associated minima can be used only with special authorisation. Note: this is a different thing from the RNP AR APCH.”, data type CodeYesNoType.
    • add a new minBaroVNAVTemperature attribute, defined as “The airport temperature below which the use of Baro-VNAV is not authorized to the LNAV/VNAV minima.”, data type ValTemperatureType
    • add a new maxBaroVNAVTemperature attribute, defined as “The airport temperature above which the use of Baro-VNAV is not authorized to the LNAV/VNAV minima.”, data type ValTemperatureType
    • add a new association “hasStepdownFix” to TerminalSegmentPoint
      • 0…*, role “stepdownFix” on the TerminalSegmentPoint side, definition = “A position on the final segment of a non-precision approach that, when positively identified, enables a lower set of minima.
    • delete the association isApprovedFor AircraftCharacteristic
  • In the Minima class:
    • delete the altitude attribute
    • delete the altitudeCode attribute
    • add a new attribute obstacleClearanceAltitude, data type ValDistanceVerticalType, definition = “The lowest altitude used in establishing compliance with appropriate obstacle clearance criteria.”
    • add a new attribute decisionAltitude, data type ValDistanceVerticalType, definition = “A specified altitude in reference to mean sea level in an approach with vertical guidance at which a missed approach must be initiated if the required visual references to continue the approach have not been established.”
    • add a new attribute minimumDescentAltitude, data type ValDistanceVerticalType, definition = “A specified altitude in a non-precision approach or circling approach below which descent must not be made without the required visual reference.
    • delete the height attribute
    • delete the heightCode attribute
    • add a new attribute obstacleClearanceHeight, data type ValDistanceVerticalType, definition = “The lowest height above the elevation of the relevant runway threshold or the aerodrome elevation as applicable, used in establishing compliance with appropriate obstacle clearance criteria.
    • add a new attribute decisionHeight, data type ValDistanceVerticalType, definition = A specified height in the precision approach or approach with vertical guidance at which a missed approach must be initiated if the required visual reference to continue the approach has not been established.
    • add a new attribute minimumDescentHeight, data type ValDistanceVerticalType, definition = “A specified height in a non-precision approach or circling approach below which descent must not be made without the required visual reference.
    • delete the militaryHeight attribute;
    • add a new attribute militaryCeiling, data type ValDistanceVerticalType, definition=”The minimum height of the cloud base applicable to military aircraft in relation with the minima values”.
    • add a new attribute militaryMinima, data type CodeYesNoType, definition=”An indication that the minima values are applicable to military operations”;
    • delete the mandatoryRVR attribute;
    • add a new runwayVisualRange attribute, data type ValDistanceType, definition=“A minimum RVR value provided by a standardised Runway Visual Range (RVR) equipment, associated with the minima”;
    • increase the multiplicity of the Minima class from 0..1 to .* in the association with ApproachCondition;
    • add a new composition association isApprovedFor AircraftCharacteristic
      • .*, role “aircraftCategory”on the AircraftCharacteristic side, definition = “A category of aircraft, usually based on the landing performance classification, for which the Minima is provided”.
    • Delete the CodeMinimumHeightBaseType <<CodeList>>
    • Delete the CodeMinimumHeightType <<DataType>>
    • Delete the CodeMinimumAltitudeBaseType <<CodeList>>
    • Delete the CodeMinimumAltitudeType <<DataType>>
    • Add a new <<CodeList>> CodeApproachPrecisionCategoryBaseType defined as “A categorisation of the final approach leg of an Instrument Approach Procedure based on the precision of the 3D guidance systems used”, list of values:
      • CAT_I = Precision Approach Category I
      • CAT_II = Precision Approach Category II
      • CAT_II_AUTOPILOT = Precision Approach Category II flown with autopilot
      • CAT_III = Precision Approach Category III
      • GP_INOP = Localizer Approach (lateral guidance only, no vertical guidance). Also known as “GP-INOP” in the base of a ILS system.
      • NON_PRECISION = Non-precision Approach
      • OTHER
    • Add a new data type CodeApproachPrecisionCategoryType (specialisation of CodeApproachPrecisionCategoryBaseType, stereotype <<datatype>>, definition: “ A complex data type that enables the provision of a NIL reason for any attribute using this type.”), attribute:
      • nilReason (type: NilReasonEnumeration)
    • Add a new <<CodeList>> CodeSatelliteApproachBaseType defined as “A categorisation of the final segment vertical and/or horizontal guidance in case of a GNSS procedure”, list of values:
      • LPV = “Localizer performance with vertical guidance (LPV). The label to denote minima lines associated with APV-I or APV-II performance on approach charts.
      • LNAV = “Lateral navigation (LNAV) . The lateral navigation without positive vertical guidance. This type of navigation is associated with non-precision approach procedures.
      • LNAV_VNAV = “Lateral navigation/Vertical navigation
      • LP = “Localizer performance (LP). The label to denote minima lines associated with the lateral element of APV-1 performance on approach charts”
      • GLS = “GBAS landing system (GLS). A system for approach and landing operations utilizing GNSS, augmented by a ground-based augmentation system (GBAS), as the primary navigational reference.
      • RNP = ”RNP final approach”
      • OTHER
    • Add a new data type CodeSatelliteApproachType (specialisation of CodeSatelliteApproachBaseType, stereotype <<datatype>>, definition: “ A complex data type that enables the provision of a NIL reason for any attribute using this type.”), attribute:
      • nilReason (type: NilReasonEnumeration)

The following UML class diagram shows the main elements of the new model for minima. The new/changed elements are indicated with in blue, the deleted elements are indicated in red:

Note: for completeness sake, the diagram also includes relevant changes coming from other Change Proposals, such as the modified list of values for the CodeApproachType, changed attributes related to PBN, etc.

Mapping AIXM 5.1.1 to AIXM 5.2 (forward)

The following algorithm shall be applied:

  • [MAPC-00] For each FinalLeg that has minimumBaroVnavTemperature or guidanceSystem or landingSystemCategory child elements:
    • if it has no child ApproachCondition element, then add a new ApproachCondition element;
    • in each ApproachCondition child elements:
      • if present, copy the value of the FinalLeg.minimumBaroVnavTemperature into the ApproachCondition.minBaroVNAVTemperature
      • if present, map the value of the FinalLeg.landingSystemCategory into the ApproachCondition.landingPrecisionCategory as follows:
        • NON_PRECISION -> NON_PRECISION
        • ILS_PRECISION_CAT_I -> CAT_I
        • ILS_PRECISION_CAT_II -> CAT_II
        • ILS_PRECISION_CAT_IIIA -> CAT_III
        • ILS_PRECISION_CAT_IIIB -> CAT_III
        • ILS_PRECISION_CAT_IIIC -> CAT_III
        • ILS_PRECISION_CAT_IIID -> CAT_III
        • MLS_PRECISION -> OTHER:MLS_PRECISIONS
        • OTHER:CAT_II_AUTOPILOT -> CAT_II_AUTOPILOT
        • OTHER:GP_INOP -> GP_INOP
        • OTHER -> OTHER
      • [MAPC-99] if present, the value of the FinalLeg.guidanceType is not mapped forward. For values such as LVAV, LVAV_VNAV, GLS, etc. it is assumed that the workaround with OTHER:... value is used for satellite approach types, as indicated below. For the other values, it is assumed that same information is provided through the InstrumentApproachProcedure.approachType.
      • delete the minimumBaroVnavTemperature element;
      • delete the guidanceSystem element;
      • delete the landingSystemCategory element;
      • if present, map the value of the ApproachCondition.finalApproachPath as follows:

AIXM 5.1(.1)

AIXM 5.2

 finalApproachPath

finalApproachPath

satelliteApproachType

STRAIGHT_IN

STRAIGHT_IN

-

CIRCLING

CIRCLING

-

SIDESTEP

SIDESTEP

-

OTHER

OTHER

-

OTHER:STRAIGHT_IN_LPV

STRAIGHT_IN

LPV

OTHER:STRAIGHT_IN_LVAV

STRAIGHT_IN

LNAV

OTHER:STRAIGHT_IN_LVAV_VNAV

STRAIGHT_IN

LNAV_VNAV

OTHER:STRAIGHT_IN_LP

STRAIGHT_IN

LP

OTHER:STRAIGHT_IN_GLS

STRAIGHT_IN

GLS

OTHER:STRAIGHT_IN_RNP

STRAIGHT_IN

RNP

OTHER:CIRCLING_LPV

CIRCLING

LPV

OTHER:CIRCLING_LVAV

CIRCLING

LNAV

OTHER:CIRCLING_LVAV_VNAV

CIRCLING

LNAV_VNAV

OTHER:CIRCLING_LP

CIRCLING

LP

OTHER:CIRCLING_GLS

CIRCLING

GLS

OTHER:CIRCLING_RNP

CIRCLING

RNP

OTHER:SIDESTEP_LPV

SIDESTEP

LPV

OTHER:SIDESTEP_LVAV

SIDESTEP

LNAV

OTHER:SIDESTEP_LVAV_VNAV

SIDESTEP

LNAV_VNAV

OTHER:SIDESTEP_LP

SIDESTEP

LP

OTHER:SIDESTEP_GLS

SIDESTEP

GLS

OTHER:SIDESTEP_RNP

SIDESTEP

RNP


  • [MAPC-00] For each ApproachCondition that has aircraftCategory child elements
    • if the ApproachCondition has no Minima child element, then add a Minima child element;
    • in the Minima element copy the ApproachCondition.aircraftCategory elements;
    • delete the ApproachCondition.aircraftCategory elements
  • [MAPC-00] [MAPC-02] For each Minima element that has altitude or altitudeCode child elements:
    • map the altitude and altitudeCode attributes as follows:

AIXM 5.1(.1)

AIXM 5.2

altitude

altitudeCode

obstacleClearanceAltitude

decisionAltitude

minimumDescentAltitude

annotation.Note

value

OCA

value

-

-

-

value

DA

-

value

-

-

value

MDA

-

-

value

-

value

OTHER

-

-

-

purpose=“OTHER:FORWARD_MAPPING”;

translatedNote.LinguisticNote.note=”altitude<value of the altitudeCode>, <value of the altitude>, <value of the altitude.uom>;


  • [MAPC-00] [MAPC-02] For each Minima element that has height, heightCode or militaryHeight child elements:
    • if both the height and the militaryHeight elements have a value, then duplicate the Minima element and map separately the height and militaryHeight attributes as follows (each in one of the Minima elements created as a copy of the original Minima):

AIXM 5.1(.1)

AIXM 5.2

height or militaryHeight

heightCode

obstacleClearanceHeight

decisionHeight

minimumDescentHeight

annotation.Note

value

OCH

value

-

-

-

value

DH

-

value

-

-

value

MDH

-

-

value

-

value

OTHER

-

-

-

purpose=“OTHER:FORWARD_MAPPING”;

translatedNote.LinguisticNote.note=”height<value of the heightCode>, <value of the height/militaryHeight>, <value of the height/militaryHeight.uom>;

  • if militaryHeight is mapped, then also set the child militaryMinima = ‘Yes’
  • [MAPC-00] [MAPC-02] For each Minima element that has a mandatoryRVR child element:
    • map the visibility and mandatoryRVR attributes as follows:

AIXM 5.1(.1)

AIXM 5.2

visibility

mandatoryRVR

visibility

runwayVisualRange

annotation.Note

value

No or NIL

value

-

-

value

Yes

-

value

-

value

OTHER

value

-

purpose=“OTHER:FORWARD_MAPPING”;

translatedNote.LinguisticNote.note=”mandatoryRVR<value of the mandatoryRVR>;

Mapping AIXM 5.2 to AIXM 5.1.1 (backward)

The following algorithm shall be applied, in the order specified below:

  • STEP 1 [MAPC-00] For each Minima element apply the following mapping
    • if obstacleClearanceAltitude and/or obstacleClearanceHeight have an assigned value, then create a separate Minima[1] instance
    • if decisionAltitude and/or decisionHeight have an assigned value, then create a separate Minima[2] instance
    • if minimumDescentAltitude and/or minimumDescentHeight have an assigned value, then create a separate Minima[3] instance
    • map the original Minima class as follows, using the one, two or three Minima instances created above, as necessary:


AIXM 5.2

AIXM 5.1(.1)

obstacleClearanceAltitude

decisionAltitude

minimumDescentAltitude

Minima instance

altitude

altitudeCode

value

-

-

[1]

value

OCA

-

value

-

[2]

value

DA

-

-

value

[3]

value

MDA

AIXM 5.2

AIXM 5.1(.1)

obstacleClearanceHeight

decisionHeight

minimumDescentHeight

Minima instance

height

heightCode

value

-

-

[1]

value

OCH

-

value

-

[2]

value

DH

-

-

value

[3]

value

MDH

  • [MAPC-02] If the militaryMinima has an assigned value, 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 militaryMinima
    • Add an annotation.Note associated to each of the Minima [1], [2] and/or [3] instances having
      • purpose=“OTHER:BACKWARD_MAPPING”;
      • LinguisticNote.note=”militaryMinima: <value of the militaryMinima>”
  • [MAPC-02] If the militaryCeiling has an assigned value, 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 militaryMinima
    • Add an annotation.Note associated to each of the Minima [1], [2] and/or [3] instances having
      • purpose=“OTHER:BACKWARD_MAPPING”;
      • LinguisticNote.note=”militaryCeiling: <value of the militaryCeiling> <value of the militaryCeiling.uom>”
  • [MAPC-00] [MAPC-02] If the runwayVisualRange has an assigned value, in each of the Minima [1], [2] and/or [3] instances apply the following mapping:

AIXM 5.2

AIXM 5.1(.1)

visibility

runwayVisualRange

visibility

mandatoryRVR

annotation

-

value

value

Yes

-

value

same value

value

Yes

-

value

different value

value

Yes

purpose=“OTHER:BACKWARD_MAPPING”;

translatedNote.LinguisticNote.note=”runwayVisualRange<value of the runwayVisualRange> <value of the runwayVisualRange.uom>

  • [MAPC-00] copy the rest of the Minima child elements and their descendants identical in all Minima [1], [2] and/or [3] instances, as applicable


  • STEP2 [MAPC-00] For each Minima element, including the additional instances created in Step 1:
    • create a separate copy of the parent ApproachCondition element and associate each Minima with that copy
    • if present, copy each aircraftCategory and its descendants into the parent ApproachCondition element
    • delete the aircraftCategory and its descendants
  • STEP3 For each ApproachCondition element, including the additional instances created in Step 2:
    • [MAPC-01] if landingPrecisionCategory or satelliteApproachType have an assigned value, apply the following mapping:
      • concatenate the values of the finalApproachPath, landingPrecisionCategory and satelliteApproachType using intermediate “_” characters and save the value in the finalApproachPath element
      • delete the landingPrecisionCategory or satelliteApproachType
    • [MAPC-02] if specialAuthorisation has an assigned value, 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 specialAuthorisation
      • Add an annotation.Note associated to each of the Minima [1], [2] and/or [3] instances having
        • purpose=“OTHER:BACKWARD_MAPPING”;
        • LinguisticNote.note=”specialAuthorisation: <value of the specialAuthorisation>”
    • [MAPC-02] if minBaroVNAVTemperature has an assigned value, 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 minBaroVNAVTemperature
      • Add an annotation.Note associated to each of the Minima [1], [2] and/or [3] instances having
        • purpose=“OTHER:BACKWARD_MAPPING”;
        • LinguisticNote.note=”minBaroVNAVTemperature: <value of the minBaroVNAVTemperature> <value of the minBaroVNAVTemperature.uom>”
    • [MAPC-02] if maxBaroVNAVTemperature has an assigned value, 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 maxBaroVNAVTemperature
      • Add an annotation.Note associated to each of the Minima [1], [2] and/or [3] instances having
        • purpose=“OTHER:BACKWARD_MAPPING”;
        • LinguisticNote.note=”maxBaroVNAVTemperature: <value of the maxBaroVNAVTemperature> <value of the maxBaroVNAVTemperature.uom>”
    • [MAPC-02] if stepdownFix has an assigned value, 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 stepdownFix
      • Add an annotation.Note associated to each of the Minima [1], [2] and/or [3] instances having
        • purpose=“OTHER:BACKWARD_MAPPING”;
        • LinguisticNote.note=”stepdownFix (xlink:href): <value of the stepdownFix.href>”

Mapping example

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

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





HTML
<pre>
...</pre>