To utilise a dataset, it is necessary to be able to separately identify its constituent parts. Specifically, AIXM requires this ability to express relationships between features and to identify features that are part of an AIXM message. Unique identifiers associated with each feature instance are used to achieve this.
Regarding the unique identifier concepts used, AIXM 4.5 differs significantly from AIXM 5.
Basically, there are two alternatives when implementing a mechanism for uniquely identifying objects in a database and the same is true for data formats such as AIXM: artificial or natural keys.
While AIXM 4.5 uses natural keys, for AIXM 5 a concept of artificial keys is applied.
AIXM 4.5 – Natural Key
A natural key is formed of attributes that already exist in the real world.
In an AIXM 4.5 message you will find for each feature a dedicated “Uid” element used to uniquely identify an instance of that feature. The name of this element is composed of the AIXM 4.5 specific three letter code for the feature, e.g. “Dpn” for Designated Point followed by the suffix “Uid”.
This Uid element then contains those attributes of the feature that allow to make it unique. For example, in the case of a Designated Point this are the position attributes (<geoLat> and <geoLong>) plus the coded identifier (<codeId>).
The big advantage of natural keys is that, by not relying on artificial identifiers, which would be system specific, the internal workings of a source or destination system need not to be known. This is important because data may originate from several different sources or systems.
The Uid of an AIXM 4.5 feature may also contain the Uid of another AIXM 4.5 feature. This is the case if the relationship to another feature is required to make an instance of that feature unique. For example: The unique identifier of a Runway (<RwyUid>) contains as an element, besides the Runway designator (<txtDesig>) also the unique identifier of the Aerodrome it belongs to (<AhpUid>).
But one issue to be solved is when one of the attributes forming the natural key of the feature is changed. For example, a VOR may be resurveyed. This may result in a change of the latitude and longitude values. A VOR is uniquely identified by its position (amongst other things), so such a change affects its natural key. When updating these attributes, how to ensure that we do not end up with two features of one and the same VOR?
Change of Natural Key
In an AIXM 4.5 message, the <Changed> element contains data about the modified attributes and relationships of one previously sent feature. In case of a changed natural key the <Changed> element shall contain first the previous natural key of the feature instance (<VorUid> in the example shown below) and then new <Vor> element, including its new natural key and the rest of its attributes and relationships.
Master Identifier (mid)
As you can see in the examples above, AIXM 4.5 also allows – in addition to the natural key – to use an artificial key as unique identifier. The “mid” attribute used for that purpose is optional.
The artificial keys may be useful in the case of data being exchanged between parties who have agreed on the form and the source of the keys, and when the values of those keys are persistent. By the way, the EAD/AIXM 4.5 system always populates the <mid> for all features automatically.
AIXM 5 – Artificial Key
Each AIXM 5 feature is identified through the use of the gml:identifier property. According to the AIXM Temporality Concept, the identifier property is the only time-invariant property. In other words, the only attribute of a feature that cannot be changed. Therefore, it is situated outside the TimeSlice element of an AIXM feature. The gml:identifier property can be transmitted along with any Feature TimeSlice, allowing to identify the feature to which the TimeSlice belongs.
The AIXM 5 relies on the use of universal unique identifiers (UUID) as artificial identifiers for AIXM features. A UUID is a 128-bit number that is encoded with a random number conventionally displayed in their ‘canonical’ form, which is a sequence of 32 hexadecimal digits grouped into a sequence of 8, 4, 4, 4 and 12 digits.
UUID generation algorithms can guarantee that the risk for the same UUID value to be generated by another system, for another feature, is extremely low.
But, it is important to note that the UUID does not identify a feature. It identifies the data that someone has about a feature! It is therefore possible that the same AIXM feature e.g. Washington Dulles Airport, exists in different systems having different UUIDs. When data from different sources is merged in a single system, the owner of that system might be confronted with the need to identify and merge duplicate feature data, based on actual properties of the feature, not on the gml:identifier (for more details about this issue, see our blog “Identification of aeronautical features”).
The most important advantage of using UUID as gml:identifier in AIXM is for software development. It is simpler and less error prone to write code that relies on UUID for feature identification and reference, as compared to the use of any kind of “natural key” combination.
Besides the gml:identifier you will also find a gml:id element in AIXM 5 data files. Every GML object is required to have a gml:id value. Compared to the gml:identifier which shall be universally unique, the gml:id is intended as a local unique identifier, within a XML data set. AIXM features, also being GML objects, must have a gml:id value as well.
Although not required (see example of AirportHeliport above), it is recommended that the gml:id of an AIXM features also makes use of the UUID value, prefixed with “uuid.”. Since UUIDs are globally unique, they are also locally unique, thus perfect candidates for the gml:id. This avoids taking care of two different identifiers for one feature when it comes to feature referencing.
The way how features are uniquely identified has an impact on how relationships are encoded. Find out more about that issue by reading our upcoming article of the AIXM 4.5 vs. AIXM 5 series “Feature Referencing”.