special treatment for geometry references needed

[porosnie]

This issue was raised by Wolfi Scheucher. Reference from ASE ATZ,EADH to DPN This is done by gml:pointProperty to a DPN (b35409d8-f236-4303-a12d-795e9e9c8751) EADH ARP. Is a local referencing done acc. to the OGC paper (for the CircleByCenterPoint of the Airspace). So I don’t think that should be an error. See also: https://ext.eurocontrol.int/aixm_confluence/pages/viewpage.action?pageId=13075961

There are some particular cases that need a special treatment.

[antavelos]

@porosnie So, it should be considered as an association link or it should not be considered at all in the graph?

[porosnie]

It should be considered as an association link. The difficulty is that this is coded with an internal reference (xlink:href="#P0001"). Does the Graph also support internal references?

This is a more general question, since all other xlink:href could use the local reference (prefixed with "#"), in which case it points to the gml:id attribute of the target feature, not its gml:identifier.

Please see http://www.aixm.aero/sites/aixm.aero/files/imce/AIXM51/aixm_feature_identification_and_reference-1.0.pdf, which explains the two types of references used in AIXM files (abstract and local). Only sections 3.2 Concrete local references within a message and 3.4.1 abstract refereces using UUID are actually used.

[antavelos]

@porosnie the graph does not currently support such kind of references. It's gonna need some changes. I'll have a look on the document an will come back.

[antavelos]

In the general case I could keep track of the local references as well and check both when trying to find associations.

In this specific case I can adjust the code to check the internal geometry references. However, are we expecting any other type of internal reference of is it only for this specific case?

[porosnie]

Internal references can be used on any other xlink:href, instead of the abstract references by gml:identifier. Therefore, if you can add support for internal references everywhere, that would be the best solution.

[antavelos]

@porosnie in order to find associations that are based on internal references we'll need to keep track of the element fields that have a gml:id attribute.

1. Do we need to report those fields in the skeleton as well just like the other key fields?
2. Do we need to create an extension at the referenced feature?

[porosnie]

1. yes. I see that the gml:id is already there for the target feature, such as below: If there is for example a SpecialDate pointing to this OrganisationAuthority by internal reference, that Navaid will have a child element such as the one below: It is in no way different from how an abstract link is recorded.

2. Yes. I am thinking that the reverse association (from the referenced feature, such as OrganisationAuthority in this case) should always be done by gml:id and not by gml:identifier (as done currently). That's because the gml:id will always exist, it is imposed by the AIXM schema. The gml:identifier, although widely used, it is not mandatory. There are systems that export AIXM 5.1 files without gml:identifier. All the associations are coded with internal links (to the gml:id).

The application would be more robust if the reverse associations were changed to always use the gml:id of the target feature. Sorry that I did not realise that earlier... Is it a lot of work to refactor this part?

As a side note, in many examples the gml:id value is the same as the gml:identifier value. Please do not consider this a rule, it is just a best practice. Some data sources do not follow it.

[antavelos]

Regarding point [1] I mostly refer to elements such as the one which this case was opened for. An Airspace has an xlink refering to this element of a DesignatedPoint: `

52.288888888888884 -32.035 30 ` Should we report this element (and every similar element) at the skeleton version of the DesignatedPoint? Regarding the use of gml:id instead of identifier it's not a big change.

[porosnie]

[1] yes, please add these links in the skeleton file. Even if the second one is not supported by the reverse MXIA extension, we will update the MXIA extension later. Is that OK?

[antavelos]

those elements are usually nested under some other elements. I guess we need the whole element and not only the one with the gml:id, right?

For example here do we only need the Point element or the whole location element?

[porosnie]

If we consider this example: https://ext.eurocontrol.int/aixm_confluence/pages/viewpage.action?pageId=13075961 (the second XML code sample on that page).

[a] For the direct link, we do not need the whole chain (theAirspaceVolume/horizontalProjection/etc.). It is sufficient to have the last element in the skeleton file, directly under the AirspaceTimeSlice: .

However, this link cannot be resolved directly because the target is not in the skeleton file. This can be resolved either adding the ElevatedPoint in the skeletion file (under Navaid). Is this what you propose? In this case, the ElevatedPoint can be added directly under NavaidTimeSlice. We do not need the intermediate location element.

[b] For the reverse link, the gml:PointProperty references a descendant element of the Navaid. This is a particular situation. However, for the reverse link, I think that we can use directly the parent feature identifier (Airspace in this case). We do not need to know in the skeleton file that the reference comes from a descendant element of the Airspace. For example:

2d2c95dc-cfec-4eae-96ca-dc95fff03756 VOR_DME XYZ

[antavelos]

Ok, now it's more clear, thanks!

[antavelos]

@porosnie Done.

The approach of finding associations within a file is as follows:

For every xlink:href of a feature scan all the other features and check if the xlink:href matches with:

• the gml:id of the feature
• or the identifier of the feature
• or the gml:id of any of the properties of the feature

If there is a match then an extension is created at the target feature. If not, then the xlink is marked as broken.