/
[AIXM-607] Altimeter source revision

[AIXM-607] Altimeter source revision

Owned by POROSNICU Eduard
Last updated: 2024 Sept 03 by ADAM STYLES

ID:

AIXM-607

target version:

AIXM 5.2

version:

1.0

last updated:

07 AUG 2023

status:

APPROVED


Description

The AltimeterSource class is changed from feature into object. A new WeatherSource class, complemented with WeatherSourceAvailability and associations to AltimeterSource and InformationService is added. The remoteAltimeterMinima property of the Minima is removed. The association between MissedApproachGroup and AltimeterSource is removed. Some values in the CodeInformationServiceBaseType are added or adjusted.

Rationale for change

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

In some regions/countries altitudes/heights that are used in Procedures, such as Minima values, may change if a remote altimeter is used. The following diagram shows the AIXM classes, properties and data types that are relevant in this context:

A set of Minima values (OCA/OCH, DA/DH, MDA/MDH) may be labeled with the remoteAltimeterMinima as being valid when using either a local or a remote altimeter. This means that it is possible to code separately and explicitly both the minima values with a local altimeter and with a remote altimeter. In PANS-OPS, this corresponds to the adjustment of minima for “remote altimeter setting source” (RASS). The same information is available from the ApproachCondition parent class, which has an association with the AltimeterSource class.

However,  the AltimeterSource class has only “isRemote”  and “isPrimary” as attributes, which does not make sense for a <<feature>>. This class should become an <<object>> that allows qualifying the altimeter source.

In addition to altimeter sources, other weather information sources for wind, temperature, remote vision, etc. may be of interest to the users. The current model does not include such elements. Therefore, it is proposed that AltimeterSource is associated with a new <<feature>> WeatherSource, which is also associated with the InformationService that uses that source for the provision of specific meteorological data.

Impact assessment

[FWD_MAP_LOSS] Data mapping is possible, but some data would be lost (or converted into Notes) 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:

  • Add a new CodeRelativeLocationBaseType data type, stereotype <<CodeList>>, definition = “A code indicating the relative position of a resource in relation with a given place”, allowable values:
    • LOCAL = Locally situated
    • REMOTE = Remotely situated
    • OTHER = Other.
  • Add a new CodeRelativeLocationType data type, as a specialisation of the CodeRelativeLocationBaseType, stereotype <<datatype>>, definition = “A complex data type that enables the provision of a NIL reason for any attribute using this type.”, attributes:
    • nilReason, type NilReasonEnumeration
  • Add a new CodeWeatherSourceBaseType data type, stereotype <<CodeList>>, definition = “A code indicating a kind of weather sensor or a device that can be used to asses meteorological conditions at its location”, allowable values:
    • ALTIMETER = A barometric device that provides the relative distance between its location and the Mean Sea Level.
    • WIND = A device that provides information about wind (speed, direction, etc.) at its location
    • TEMPERATURE = A device that provides information about the air temperature at its location
    • CAMERA = A device that provides live or recorded images that can be used to asses the meteorological situation at its location
    • OTHER = Other.
  • Add a new CodeWeatherSourceType data type, as a specialisation of the CodeRelativeLocationBaseType, stereotype <<datatype>>, definition = “A complex data type that enables the provision of a NIL reason for any attribute using this type.”, attributes:
    • nilReason, type NilReasonEnumeration
  • Insert a new class WeatherSource <<feature>>, definition = “Information about a weather sensor or a device that can be used to asses meteorological conditions at its location and that is used to provide information to aviation users”, with the following attributes and associations:
    • designator, type TextDesignatorType, definition = “A name or a code that can be used to identify the weather source”
    • sensorType, type CodeWeatherSourceType, definition = “The type of data that the sensor provides”;
    • (composition) WeatherSource isLocatedAt ElevatedPoint
      • ElevatedPoint role “position”, definition = “The geographical position of the resource”, multiplicity 0..1
    • (composition) WeatherSource isAvailableBy WeatherSourceAvailability
      • WeatherSourceAvailability role “availability”, definition = “Information about the operational status of the resource”, multiplicity 0..*
    • (composition) WeatherSource hasAnnotations Note with
      • Note role “annotation” (definition = “A free text remark concerning the weather source or one of its properties.”), multiplicity 0…*
    • Add a new class WeatherSourceAvailability with <<object>> stereotype
      • Definition = “Information about the operational status of the weather source.”
      • Attributes
        • operationalStatus, type CodeStatusServiceType, definition = “The availability of the source device or service.”
      • Associations
        • WeatherSourceAvailability is a specialisation of the PropertiesWithSchedule class
      • In the InformationService class
        • add an association usesDataFrom WeatherSource
          • WeatherSource role “dataSource”, definition = “Identifies the source of the weather data used for the service provision”, multiplicity 0…*, navigable in towards WeatherSource
          • InformationsService multiplicity 0..*
        • In the CodeServiceInformationBaseType data type:
          • correct the definition of value AWOS = Automated Weather Observation System
          • add value LWIS = Limited Weather Information System
        • In the AltimeterSource class:
          • change its stereotype into <<object>>
          • change its definition into “Information about the location and source of the altimeter setting”
          • change its attributes as follows:
            • delete isPrimary
            • delete isRemote
            • add rank, data type CodeFacilityRankingType, definition = “An indication of the priority level of the altimeter setting source”
            • add relativeLocation, data type CodeRelativeLocationType, definition = “The relative position of the altimeter setting source”
            • distance, data type ValDIstanceType, definition = “The distance to the altimeter setting source, if applicable”
          • add an association AltimeterSource usesDataFrom WeatherSource, with:
            • WeatherSource multiplicity 0..1, role name “altimeterData” and role definition = “The equipment or device that provides the altimeter setting information”
            • AltimeterSource multiplicity 0..*
          • In the Minima class
            • delete the remoteAltimeterMinima attribute
          • Delete the AltimeterSourceStatus class (and all its relationships)
          • In the AirportHeliport class
            • change the relationship to AltimeterSource into “composition”
          • In the ApproachCondition class
            • change the relationship to AltimeterSource into “composition”
          • In the MissedApproachGroup class
            • delete the relationship to AltimeterSource

The following UML class diagram indicates the new/deleted classes and changes in lists of values:

Mapping AIXM 5.1.1 to AIXM 5.2 (forward)

The following algorithm shall be applied:

  • For each AltimeterSource
    • [MAPC-00] if it has an availability child element, then:
      • insert in the data set a copy of the AltimeterSource named WeatherSource, which:
      • preserves the availability child element, for which the AltimeterSourceAvailability descendant is renamed WeatherSourceAvailability, and if applicable change the value of its operationalStatus descendant element as follows:
        • change DOWNGRADED into LIMITED
        • change WORK_IN_PROGRESS into OTHER:WORK_IN_PROGRESS
      • gets a child element sensorType = ALTIMETER
      • does not retain the isPrimary and isRemote attributes

Note: only an AltimeterSource with availability information needs to be preserved as a feature. Otherwise, it has no properties that justify it to be a feature.

  • add a child an altimeterData element with its xlink:href attribute referencing the newly created WeatherSource element.
  • [MAPC-00] Apply the following temporary mapping, necessary before copying the AltimeterSource as a child element of a referencing AirportHeliport or ApproachCondition (as described further down).
    • if it has isPrimary child element, replace it with a rank child element with its value mapped as follows:
      • isPrimary = Yes -> rank = PRIMARY
      • isPrimary = No -> rank = ALTERNATE
      • isPrimary = OTHER -> rank = OTHER
    • if it has isRemote child element, replace it with a relativeLocation child element with its value mapped as follows:
      • isRemote = Yes -> relativeLocation = REMOTE
      • isRemote = No -> relativeLocation = LOCAL
      • isRemote = OTHER -> relativeLocation = OTHER
    • if it is referenced by an AirportHeliport or ApproachCondition
      • [MAPC-07] Find the corresponding AirportHeliport element and:
        • if necessary, apply the “timeSlice alignment” procedure described for this mapping case;
        • change its altimeterSource or altimeter child element (as applicable):
          • remove its xlink:href attribute
          • add an AltimeterSource child element having:
            • gml:identifier value concatenated as value of the AirportHeliport.gml:identifier and AltimeterSource.gml:identifier value
              • note: this concatenation will prevent the risk of colliding gml:identifiers for different AltimeterSource elements, in case of a circular mapping (AIXM 5.1 -> 5.2 -> 5.1);
            • all other properties copied from the AltimeterSource, modified as described earlier
          • if it is referenced by a MissedApproachGroup that has an altimeter child element:
            • [MAPC-02] from the three backward mapping options available, 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:
          • Add an annotation.Note associated with the owner class having
            • purpose=“OTHER:BACKWARD_MAPPING”;
            • LinguisticNote.note=”altimeter: isRemore = <value of related AltimeterSource.isRemote>, isPrimary = <value of related AltimeterSource.isLocal>;
          • Remove the AltimeterSource element
        • For each Minima element that has a remoteAltimeterMinima child element:
          • [MAPC-00] If the ancestor ApproachCondition is associated with an AltimeterSource having isRemote with the same value as the remoteAltimeterMinima, then no additional mapping is necessary;
          • [MAPC-02] If the ancestor ApproachCondition is not associated with an AltimeterSource having isRemote with the same value as the remoteAltimeterMinima, then from the three backward mapping options available, 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:
        • Add an annotation.Note associated with the owner class having
          • purpose=“OTHER:BACKWARD_MAPPING”;
          • LinguisticNote.note=”remoteAltimeterMinima: <value of remoteAltimeterMinima>;
        • [MAPC-01] For each InformationService that has type = OTHER:LWIS
          • change OTHER:LWIS into LWIS

Mapping AIXM 5.2 to AIXM 5.1.1 (backward)

****Note: see [AIXM-404] Add <<object>> persistent identifiers. It is assumed that, in order to facilitate the backward mapping, the AltimeterSource objects have their own unique gml:identifier (UUID) value.

The following algorithm shall be applied:

  • For each AltimeterSource child element:
    • [MAPC-07] Create an AltimeterSource <<feature>> element that retains the gml:identifier value and:
      • copy the parent’s feature validTime and lifetime values for the new AltimeterSource feature
      • if it has rank child element, replace it with a isPrimary child element with its value mapped as follows:
        • rank = PRIMARY -> isPrimary = Yes
        • rank = ALTERNATE -> isPrimary = No
        • rank = any other value -> isPrimary = OTHER
      • if it has relativeLocation child element, replace it with a isRemote child element with its value mapped as follows:
        • relativeLocation = REMOTE -> isRemote = Yes
        • relativeLocation = LOCAL -> isRemote = No
        • relativeLocation = OTHER -> isRemote = OTHER
      • if it references a WeatherSource that has an operationalStatus child element, then add a child AltimeterSourceAvailability element as a copy of the corresponding WeatherSourceAvailability, and if applicable change the value of its operationalStatus descendant element as follows:
        • change LIMITED into DOWNGRADED
        • change ON_TEST into WORK_IN_PROGRESS
        • change UPGRADED into OTHER:UPGRADED
      • if it references a WeatherSource that has a position child element, then from the three backward mapping options available, the first two (discard the values 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:
    • purpose=“OTHER:BACKWARD_MAPPING”;
    • LinguisticNote.note=”position: <value of related ElevatedPoint.gml:pos>, <value of related ElevatedPoint@srsName>;
      • if the parent element is an altimeterSource of an AirportHeliport:
        • copy the value of the AltimeterSource.gml:identifier into altimeterSource@xlink:href
      • if the parent element is an altimeter of an ApproachCondition:
        • copy the value of the AltimeterSource.gml:identifier into altimeter@xlink:href
      • delete the AltimeterSource element
    • [MAPC-99] For the rest of the WeatherSource element data no mapping is possible. Delete the WeatherSource element.
    • [MAPC-99] For each InformationService that has a dataSource child element, no mapping is possible. Delete the dataSource child element.
    • [MAPC-01] For each InformationService that has type = LWIS
      • change type into OTHER:LWIS

Mapping example

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

AIXM InputAIXM Output