Page tree
Skip to end of metadata
Go to start of metadata

ID:

AIXM-404

target version:

AIXM 5.2

version:

1.0

last updated:

15 MAY 2019

status:

APPROVED


Description

The possibility to specify a unique identifier for AIXM objects, which is persistent across the lifetime of the AIXM object, is added in the model. This is based on the GML object identifier.

Rationale for change

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

The current model is missing the possibility to provide a persistent unique identifier to an AIXM <<object>>. Such identifiers are foreseen in the GML schema. 

Adding the possibility to uniquely identify the features' complex properties, e.g. by adding an equivalent attribute of the gml:identifier (UUID) would allow, as a minimum, an easier identification of the differences between two time slices of the same feature with positive effects in the data driven applications such as electronic charting, eAIP, etc. This brings benefits especially in the case of multi-occurrence properties like cityServed of an AirportHeliport. The order of the objects of a multi-occuring property is not important from a users perspective. Changing the order of a multi-occurrence property does not change the interpretation of the data. This leads to a heuristic comparison algorithm. Identifiers on AIXM objects can simplify the comparison of two time slices.

GML requires the attribute gml:id for each <<object>>. This id shall be unique within an XML document. Usually this is not persistent, because this can lead to duplicates within an XML document (for example, both BASELINE and PERMDELTA would have the same object with the same gml:id), which is forbidden; Another use case is the unambiguous identification of the objects through the lifetime of the underlying feature.

A reason for the change is the discrepancy of the inheritance chains modelled in UML and implemented within the XSD. The following UML diagrams represents the situation as it is implemented within the AIXM 5.1 XSDs.



The UML diagram to the right shows the current class inheritance chain for any AIXM <<feature>> type, using as example the AirportHeliportType. The property “identifier” and some others are defined by the root class “AbstractGMLType”. The class AbstractAIXMFeatureBaseType restricts by inheritance the applicable properties to “boundedBy”, “description”, “identifier” and “name”. The feature types itself extends this base type.

The second UML diagram shows the current inheritance structure of AIXM <<object>> types. The class “AbstractAIXMObjectType” is a restriction of the root class AbstractGMLType, but does not define applicable properties.

The third UML diagram  shows the changes on UML level. The entity “AbstractAIXMObjectType” derives still from “AbstractGMLType” by restriction, but declares the attribute “identifier” as an applicable property.

Points, Curves and Surfaces are also AIXM objects, but they are not a derivation of “AbstractAIXMObjectType”. The inheritance chain for geometry types is shown in the UML diagram below and is using only extension as inheritance type. This leads to unused properties for the geometry object types. In other words, the geometry classes are already compliant with this change proposal.

Impact assessment

There is no impact on existing implementations as the current AIXM 5.1(.1) data remains fully valid against AIXM 5.2. The new <<object>> identifiers do not play any role in the Temporality Concept. It is just an optional facility for applications that wish to exploit it.

When receiving data from AIXM 5.2 implementations, current AIXM 5.1(.1) systems will have to remove or ignore the <<object>> identifiers, as described in the mapping rules further down in this document.

Change Proposal details

  • The UML model does not use inheritance from the abstract AIXM_Object class, therefore no real change of the UML model needed. However, an update of the AIXM abstract UML diagram shall indicate that an object can have an identifier, as indicated in the UML class diagrams further in this document.
  • In the XML Schema, the “AIXM_AbstractGML_ObjectTypes.xsd” is re-worked similarly to the definition of the class “AbstractAIXMFeatureBaseType”, as indicated in the XSD structure diagrams further in this document.
  • No change of the temporal model needed.
  • GML profile is not affected by this change proposal. 

UML Model

The UML Class diagram below shows the updated UML diagram with the class “AIXMObject” and the new property “identifier”. 

XML Schema (XSD)



Current definition of “AbstractAIXMObjectType”
<complexType name="AbstractAIXMObjectType" abstract="true">
   		 <annotation>
   			 <documentation>Base type for AIXM complex types that are NOT features. For example, City, ContactInformation, AirspaceVolume, etc. It derives from AbstractGMLType so that AIXM objects are recognised as GML objects, thus ensuring that GML-aware applications recognise them properly. Retains only the mandatory gml:id attribute.</documentation>
   	 </annotation>
   		 <complexContent>
   			 <restriction base="gml:AbstractGMLType">
   				 <sequence>
   					 <sequence/>
   			 	</sequence>
   			 	<attribute ref="gml:id" use="required"/>
   		 	</restriction>
   		 </complexContent>
  	  </complexType>



Proposed definition of “AbstractAIXMObjectType”
<complexType name="AbstractAIXMObjectType" abstract="true">
   		 <annotation>
   			 <documentation>Base type for AIXM complex types that are NOT features. For example, City, ContactInformation, AirspaceVolume, etc. It derives from AbstractGMLType so that AIXM objects are recognised as GML objects, thus ensuring that GML-aware applications recognise them properly. Retains only the mandatory gml:id attribute.</documentation>
   	 </annotation>
   		 <complexContent>
   			 <restriction base="gml:AbstractGMLType">
   				 <sequence>
					<element ref="gml:identifier" minOccurs="0"/>
   			 	</sequence>
   			 	<attribute ref="gml:id" use="required"/>
   		 	</restriction>
   		 </complexContent>
  	  </complexType>



Mapping AIXM 5.1.1 to AIXM 5.2 (forward)

NIL (Not applicable)

Mapping AIXM 5.2 to AIXM 5.1.1 (backward)

[MAPC-99] The following algorithm shall be applied:

  • For each AIXM object except “Point”, “Curve”, “Surface”, “ElevatedPoint”, “ElevatedCurve” and “ElevatedSurface”: AIXM 5.1.1 does not have an AIXM object identifier. Therefore the algorithm can drop AIXM 5.2 object identifiers. 
  • For each  “Point”, “Curve”, “Surface”, “ElevatedPoint”, “ElevatedCurve” and “ElevatedSurface”: Not applicable.

Mapping example

Mapping example to be added...


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

AIXM 5.2AIXM 5.1(.1)
  ...





...



  • No labels