/
[AIXM-529] Add dataAssessmentStatus to VerticalStructure

[AIXM-529] Add dataAssessmentStatus to VerticalStructure

Owned by georgiana.andrei04
Last updated: 2024 Mar 28 by POROSNICU Eduard

ID:

AIXM-529

target version:

AIXM 5.2

version:

1.0

last updated:

08 AUG 2022

status:

APPROVED


Description

An additional dataAssessmentStatus attribute is added to VerticalStructure to allow for the indication if the data provided for the feature was not subject to the regular data quality assurance process.

Rationale for change

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

It was identified that there may exist obstacles (VerticalStructures), for which the data is published without passing through the tools and processes normally used to ensure the quality of the data. This may happen when a member of the flying community reports an obstacle that is not present on their charts and the information is promulgated in the interest of safety, but without being thoroughly verified. Usually this also comes with a low accuracy value.

The new dataAssessmentStatus attribute is added to VerticalStructure to allow for the indication, if the data provided for the feature was not subject to the regular data quality assurance process.

Impact assessment

[FWD_1:1] No data mapping is necessary 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, in the VerticalStructure feature:

  • Add a new dataAssessmentStatus attribute defined as “An indication if the data provided for the feature was not subject to the regular data quality assurance process.”, data type CodeDataAssessmentStatusBaseType.

In the UML model, add the following data type:

  • CodeDataAssessmentStatusBaseType (stereotype <<codelist>>, definition: “A coded value indicating if the data provided for the feature was not subject to the regular data quality assurance process.”), with the following list of values:
    • VERIFIED, type = string, definition = “The data has passed the processes for validation and verification.”
    • NOT_VERIFIED, type = string, definition = “The data is provided without having passed the processes for validation and verification and could be inaccurate.”
    • OTHER, type = string, definition = ”Other”
  • CodeDataAssessmentStatusType (specialisation of CodeDataAssessmentStatusBaseType, 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 new attribute:


Mapping AIXM 5.1.1 to AIXM 5.2 (forward)

Not applicable

Mapping AIXM 5.2 to AIXM 5.1.1 (backward)

[MAPC-02] 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:

  1. Remove the new attribute dataAssessmentStatus.
  2. Add an annotation.Note associated with the owner class having
  • purpose=“OTHER:BACKWARD_MAPPING”;
  • LinguisticNote.note=”dataAssessmentStatus:<value of dataAssessmentStatus>”

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)