[AIXM-587] Add accuracy attributes for all numerical values

Description

Accuracy attributes are added in the model to all data types that are used by numerical value properties, for which accuracy can be specified in the ICAO PANS-AIM.

Rationale for change

See https://aixmccb.atlassian.net/browse/AIXM-269 and https://aixmccb.atlassian.net/browse/AIXM-287

The PANS-AIM data catalogue contains accuracy requirements for many dimensional values, such as magnetic variation, length/width of a runway, Localizer course, etc. In addition, the PANS-AIM requires in 5.1.3 that “the identification of geographical coordinates whose accuracy does not meet the requirements may be made either with an annotation or by explicitly providing the actual accuracy value.” In order to support this requirement, an explicit accuracy attribute is proposed to be added for all positional and numerical values, if it does not already exist in AIXM.

In the current model, only some dimensional or positional properties have a complementary attribute that can be used to express the accuracy. For example, verticalAccuracy in ElevatedPoint/Curve/Surface, fieldElevationAccuracy in AirportHeliport, as highlighted in the following examples:

Because the accuracy is directly related to the data type, the most efficient solution is to specify it, where possible, as an attribute of the corresponding data type. However, an exception needs to be made for the horizontal accuracy of geographical positions (latitude and longitude values), because GML data types are used. Only in this case separate attributes will continue to be necessary.

As for any data value in AIXM, it might also be necessary to have the possibility of indicating that the accuracy is “unknown”. This is proposed to be supported by defining the accuracy data types with a pattern that allows both the numerical format and values for nilReason that are realistically applicable for an accuracy value. This would allow the accuracy to be coded as indicated in the following XML examples:

<aixm:fieldElevation uom="M" accuracy="1.5">18.0</aixm:fieldElevation>

    or

<aixm:fieldElevation uom="M" accuracy="unknown">18.0</aixm:fieldElevation>

Note: ICAO requires that all numerical data is provided with a 95% confidence level, except for obstacle data, for which the required confidence level is only 90%. In some places in the current AIXM model, the definition of the horizontalAccuracy and verticalAccuracy attributes explicitly mentions "95% confidence level", which is incorrect for obstacle data. This is corrected in the Change Proposal AIXM-424.

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.

Change Proposal details

In the UML model:

• Add a new data type class NumericalWithNilReason as a specialisation of the xsd:string, with the stereotype <<Data Type>>, defined as “A data type that takes either a positive decimal value or a pre-defined NIL reason.”
  • pattern = “\d*[.\d]*|missing|unknown|withheld”
• Extend the data type classes ValAngleType, ValBearingType, ValDepthType, ValDistanceType, ValDistanceSignedType, ValDistanceVerticalType, ValMagneticVariationType, ValMagneticVariationChangeType, ValSlopeType, ValTemperatureType with the following attribute:
  • accuracy of type NumericalWithNilReason and definition “The degree of conformance (expressed as a maximum difference) between the estimated or measured value and the true value, based on the confidence level specified for the corresponding property in the ICAO PANS-AIM.”
• Delete the following attributes

• Class	attributes to be deleted
  AirportHeliport	fieldElevationAccuracy magneticVariationAccuracy
  NavaidEquipment	magneticVariationAccuracy
  Azimuth	trueBearingAccuracy
  Elevation	angleAccuracy
  ElevatedPoint	verticalAccuracy
  ElevatedCurve	verticalAccuracy
  ElevatedSurface	verticalAccuracy
  Glidepath	angleAccuracy, rdhAccuracy
  Localizer	magneticBearingAccuracy trueBearingAccuracy widthCourseAccuracy
  RadarEquipment	rangeAccuracy, magneticVariationAccuracy
  PrecisionApproachRadar	slopeAccuracy
  RunwayDirection	trueBearingAccuracy elevationTDZAccuracy
  Runway	lengthAccuracy, widthAccuracy
  NavaidEquipmentDistance	distanceAccuracy
  RunwayDeclaredDistanceValue	distanceAccuracy
  VerticalStructurePart	verticalExtentAccuracy

The following UML class diagram highlights the new data type and changes in existing data types:

The following UML class diagram shows the deleted attributes:

Mapping AIXM 5.1.1 to AIXM 5.2 (forward)

[MAPC-01] See the following table. For each of the “AIXM parent object” that has a value for the descendant “element to be removed”:

• copy the value of the “element to be removed’’ in the “related element”.@accuracy attribute.

Note: Although there exist business rules that try to prevent such situations, the following additional mapping actions need to be considered, where applicable:

• if the unit of measurement is different, convert the value into the same unit of measurement
• if the “related element” does not exist, it shall be added

• remove the “element to be removed”

Mapping AIXM 5.2 to AIXM 5.1.1 (backward)

[MAPC-01] See the following table. For each of the “AIXM parent object” that has a value for the @accuracy attribute of the “element”:

• add the “element to be added”
• if the @accuracy is a numerical value, then copy its value the “element to be added” and also copy the value of the @uom attribute of the “element” into the “element to be added”
• if the @accuracy has one of the values “missing”, “unknown” or “withheld”, then leave the “element to be added” empty, copy the @accuracy value into its @nilReason attribute and set its @xsi:nil attribute to ‘true’.
• remove the @accuracy attribute

[MAPC-02] See the following table. For each of the “AIXM parent object” that has a value for the @accuracy attribute of the “element”:

From the three backward mapping options applicable in this case, the first two (discard the attribute value or use an extension) are straightforward and do not need any further details. The 3^rd 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 @accuracy attribute
• Add an annotation.Note associated with the “AIXM Parent object” class having:
• purpose=“OTHER:BACKWARD_MAPPING”
• LinguisticNote.note=”accuracy: <value of height @accuracy> <value of @uom>”.

Data Types to be analyzed and full mapping to be documented after the final publication of AIXM 5.2 - : ValAngleType, ValBearingType, ValDepthType, ValDistanceType, ValDistanceSignedType, ValDistanceVerticalType, ValMagneticVariationType, ValMagneticVariationChangeType, ValSlopeType,  ValTemperatureType.

Mapping example

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

AIXM Input	AIXM Output