Skip to main content

I use the AIXM 5.1 Reader with the default settings to read all AirspaceTimeSlice. Some of them are missing geometry. For example, I have a feature which uses xlink:href  to reference the geometry of a CTR. The CTR in itself has an UNION and consists of two CTR's which are also referenced with xlink:href. How can I get FME to get this geometry. It somehow doesn't seem to follow up on the xlink:href.

 

I use FME Desktop 2019.2.3.1

Are the xlink:href's valid? Have you tried manually accessing them?

Can you post your AIXM sample so we can take a look at it?


Maybe a silly question, but how can I check that manually? If I compare the UUID's it is clear the reference is correct.

					<aixm:geometryComponent>
<aixm:AirspaceGeometryComponent gml:id="id.f9297067-8abe-4fc3-ae19-7338bbd463a7">
<aixm:theAirspaceVolume>
<aixm:AirspaceVolume gml:id="id.6352af81-3cd8-41d1-8661-ee49c3a59fbb">
<aixm:upperLimit uom="FT">1500.0</aixm:upperLimit>
<aixm:upperLimitReference>MSL</aixm:upperLimitReference>
<aixm:lowerLimit uom="FT">0.0</aixm:lowerLimit>
<aixm:lowerLimitReference>SFC</aixm:lowerLimitReference>
<aixm:contributorAirspace>
<aixm:AirspaceVolumeDependency gml:id="id.672f8b40-41ba-4215-b961-b83e7f48a202">
<aixm:dependency>HORZ_PROJECTION</aixm:dependency>
<aixm:theAirspace xlink:type="simple" xlink:href="urn:uuid:ecdcec4e-7884-4144-9a5e-1248a00d974e"/>
</aixm:AirspaceVolumeDependency>
</aixm:contributorAirspace>
</aixm:AirspaceVolume>
</aixm:theAirspaceVolume>
</aixm:AirspaceGeometryComponent>
</aixm:geometryComponent>
<aixm:Airspace gml:id="uuid.ecdcec4e-7884-4144-9a5e-1248a00d974e">
<gml:identifier codeSpace="urn:uuid:">ecdcec4e-7884-4144-9a5e-1248a00d974e</gml:identifier>
<aixm:timeSlice>
<aixm:AirspaceTimeSlice gml:id="id.5aab73f2-7349-4363-b27d-de28e5977ded">
<aixm:geometryComponent>
<aixm:AirspaceGeometryComponent gml:id="id.7f51dc1d-3cb1-47c6-b2c6-ae1479e1abeb">
<aixm:operation>BASE</aixm:operation>
<aixm:operationSequence>1</aixm:operationSequence>
<aixm:theAirspaceVolume>
<aixm:AirspaceVolume gml:id="id.33bb17ca-d8ed-4f41-bb9f-ab4ad95e3415">
<aixm:upperLimit uom="FT">1500.0</aixm:upperLimit>
<aixm:upperLimitReference>MSL</aixm:upperLimitReference>
<aixm:lowerLimit uom="FT">0.0</aixm:lowerLimit>
<aixm:lowerLimitReference>SFC</aixm:lowerLimitReference>
<aixm:contributorAirspace>
<aixm:AirspaceVolumeDependency gml:id="id.8260ac8f-27eb-4f95-8192-198553d9f53d">
<aixm:dependency>OTHER</aixm:dependency>
<aixm:theAirspace xlink:type="simple" xlink:href="urn:uuid:f0ef9331-55ff-4d16-bb17-302fbcb32798"/>
</aixm:AirspaceVolumeDependency>
</aixm:contributorAirspace>
</aixm:AirspaceVolume>
</aixm:theAirspaceVolume>
</aixm:AirspaceGeometryComponent>
</aixm:geometryComponent>
<aixm:geometryComponent>
<aixm:AirspaceGeometryComponent gml:id="id.f316a10f-cf00-4543-b6b0-846f8c578ef3">
<aixm:operation>UNION</aixm:operation>
<aixm:operationSequence>2</aixm:operationSequence>
<aixm:theAirspaceVolume>
<aixm:AirspaceVolume gml:id="id.c112ded9-409a-4243-80c8-c412fe586fe4">
<aixm:upperLimit uom="FT">2500.0</aixm:upperLimit>
<aixm:upperLimitReference>MSL</aixm:upperLimitReference>
<aixm:lowerLimit uom="FT">0.0</aixm:lowerLimit>
<aixm:lowerLimitReference>SFC</aixm:lowerLimitReference>
<aixm:contributorAirspace>
<aixm:AirspaceVolumeDependency gml:id="id.d2394ddc-8e70-4318-8c7a-9c392bd8fcba">
<aixm:dependency>OTHER</aixm:dependency>
<aixm:theAirspace xlink:type="simple" xlink:href="urn:uuid:deeb29a9-3c70-4205-ae0c-6caf180b14a8"/>
</aixm:AirspaceVolumeDependency>
</aixm:contributorAirspace>
</aixm:AirspaceVolume>
</aixm:theAirspaceVolume>
</aixm:AirspaceGeometryComponent>
</aixm:geometryComponent>

 


Maybe a silly question, but how can I check that manually? If I compare the UUID's it is clear the reference is correct.

					<aixm:geometryComponent>
<aixm:AirspaceGeometryComponent gml:id="id.f9297067-8abe-4fc3-ae19-7338bbd463a7">
<aixm:theAirspaceVolume>
<aixm:AirspaceVolume gml:id="id.6352af81-3cd8-41d1-8661-ee49c3a59fbb">
<aixm:upperLimit uom="FT">1500.0</aixm:upperLimit>
<aixm:upperLimitReference>MSL</aixm:upperLimitReference>
<aixm:lowerLimit uom="FT">0.0</aixm:lowerLimit>
<aixm:lowerLimitReference>SFC</aixm:lowerLimitReference>
<aixm:contributorAirspace>
<aixm:AirspaceVolumeDependency gml:id="id.672f8b40-41ba-4215-b961-b83e7f48a202">
<aixm:dependency>HORZ_PROJECTION</aixm:dependency>
<aixm:theAirspace xlink:type="simple" xlink:href="urn:uuid:ecdcec4e-7884-4144-9a5e-1248a00d974e"/>
</aixm:AirspaceVolumeDependency>
</aixm:contributorAirspace>
</aixm:AirspaceVolume>
</aixm:theAirspaceVolume>
</aixm:AirspaceGeometryComponent>
</aixm:geometryComponent>
<aixm:Airspace gml:id="uuid.ecdcec4e-7884-4144-9a5e-1248a00d974e">
<gml:identifier codeSpace="urn:uuid:">ecdcec4e-7884-4144-9a5e-1248a00d974e</gml:identifier>
<aixm:timeSlice>
<aixm:AirspaceTimeSlice gml:id="id.5aab73f2-7349-4363-b27d-de28e5977ded">
<aixm:geometryComponent>
<aixm:AirspaceGeometryComponent gml:id="id.7f51dc1d-3cb1-47c6-b2c6-ae1479e1abeb">
<aixm:operation>BASE</aixm:operation>
<aixm:operationSequence>1</aixm:operationSequence>
<aixm:theAirspaceVolume>
<aixm:AirspaceVolume gml:id="id.33bb17ca-d8ed-4f41-bb9f-ab4ad95e3415">
<aixm:upperLimit uom="FT">1500.0</aixm:upperLimit>
<aixm:upperLimitReference>MSL</aixm:upperLimitReference>
<aixm:lowerLimit uom="FT">0.0</aixm:lowerLimit>
<aixm:lowerLimitReference>SFC</aixm:lowerLimitReference>
<aixm:contributorAirspace>
<aixm:AirspaceVolumeDependency gml:id="id.8260ac8f-27eb-4f95-8192-198553d9f53d">
<aixm:dependency>OTHER</aixm:dependency>
<aixm:theAirspace xlink:type="simple" xlink:href="urn:uuid:f0ef9331-55ff-4d16-bb17-302fbcb32798"/>
</aixm:AirspaceVolumeDependency>
</aixm:contributorAirspace>
</aixm:AirspaceVolume>
</aixm:theAirspaceVolume>
</aixm:AirspaceGeometryComponent>
</aixm:geometryComponent>
<aixm:geometryComponent>
<aixm:AirspaceGeometryComponent gml:id="id.f316a10f-cf00-4543-b6b0-846f8c578ef3">
<aixm:operation>UNION</aixm:operation>
<aixm:operationSequence>2</aixm:operationSequence>
<aixm:theAirspaceVolume>
<aixm:AirspaceVolume gml:id="id.c112ded9-409a-4243-80c8-c412fe586fe4">
<aixm:upperLimit uom="FT">2500.0</aixm:upperLimit>
<aixm:upperLimitReference>MSL</aixm:upperLimitReference>
<aixm:lowerLimit uom="FT">0.0</aixm:lowerLimit>
<aixm:lowerLimitReference>SFC</aixm:lowerLimitReference>
<aixm:contributorAirspace>
<aixm:AirspaceVolumeDependency gml:id="id.d2394ddc-8e70-4318-8c7a-9c392bd8fcba">
<aixm:dependency>OTHER</aixm:dependency>
<aixm:theAirspace xlink:type="simple" xlink:href="urn:uuid:deeb29a9-3c70-4205-ae0c-6caf180b14a8"/>
</aixm:AirspaceVolumeDependency>
</aixm:contributorAirspace>
</aixm:AirspaceVolume>
</aixm:theAirspaceVolume>
</aixm:AirspaceGeometryComponent>
</aixm:geometryComponent>

 

@matthieuv​ Sorry, the silly question was on my side. I thought the AIXM was referencing features from http. I was suggesting you verify the web locations they are stored at.

As a suggestion you should look for the geometries of the BASE and the UNION as they also reference xlink:href's, to check if they actually exist.

So search for f0ef9331-55ff-4d16-bb17-302fbcb32798 and deeb29a9-3c70-4205-ae0c-6caf180b14a8. There is a chance that their geometries are missing.


@matthieuv​ Sorry, the silly question was on my side. I thought the AIXM was referencing features from http. I was suggesting you verify the web locations they are stored at.

As a suggestion you should look for the geometries of the BASE and the UNION as they also reference xlink:href's, to check if they actually exist.

So search for f0ef9331-55ff-4d16-bb17-302fbcb32798 and deeb29a9-3c70-4205-ae0c-6caf180b14a8. There is a chance that their geometries are missing.

Those exist.

I'm not sure if there is somehow something wrong with my AIXM file or that it is a bug in the FME Reader.


@matthieuv​ Sorry, the silly question was on my side. I thought the AIXM was referencing features from http. I was suggesting you verify the web locations they are stored at.

As a suggestion you should look for the geometries of the BASE and the UNION as they also reference xlink:href's, to check if they actually exist.

So search for f0ef9331-55ff-4d16-bb17-302fbcb32798 and deeb29a9-3c70-4205-ae0c-6caf180b14a8. There is a chance that their geometries are missing.

If you are wiling to share your entire AIXM file, I can take a better look.


Small update. I have been in contact with Safe about this and apparently it appears they currently not support reading in xlink:href geometries. The issue has been filed in their system and I hope a future version will bring support for this.


Small update. I have been in contact with Safe about this and apparently it appears they currently not support reading in xlink:href geometries. The issue has been filed in their system and I hope a future version will bring support for this.

Thank for the status update. I look forward to checking it out in a future version.


@matthieuv​ Do you know if this issue was addressed in FME 2020 or in the upcoming 2021 release?

 

Thanks


@matthieuv​ Do you know if this issue was addressed in FME 2020 or in the upcoming 2021 release?

 

Thanks

@grattop​ they told me it is an extensive code fix and that it would be 2021.1 at the earliest.


@grattop​ they told me it is an extensive code fix and that it would be 2021.1 at the earliest.

No better with 2021.1 ... the bug is still present in this release !


@grattop​ they told me it is an extensive code fix and that it would be 2021.1 at the earliest.

Hello @philippev​! Unfortunately, this has not been resolved just yet, I have added your comment to the issue and when the issue is resolved, we will update this thread! Hope this does not cause too many inconvienencies for you! Best, Kailin.


@grattop​ they told me it is an extensive code fix and that it would be 2021.1 at the earliest.

Hi @kailinatsafe (Safer)​, I am another user with the same requirement as @philippev​, is there anything us AIXM 5.1 users can do to accelerate the resolution process? Thanks


@grattop​ they told me it is an extensive code fix and that it would be 2021.1 at the earliest.

Hello @kailinatsafe​ , Thanks for the information. Unfortunately and as for @grattop​ , this is urgent. Currently I use to view AIXM the free Luciad AIXM Viewer (https://go.hexagongeospatial.com/luciad-aixm-5-viewer-download). In parallel I am looking for a workbench which could be a workaround by allowing processing geometry references, such as xlink: href geometries and/or try enabling it by setting the "PROCESS_XLINK_GEOMETRIES" parameter to "YES" using the reader OGC GML and other transformers. What can help us quickly while waiting for the bug to be fixed is to provide us with a workbench that does the job 🙂 Have a nice day, Philippe


@grattop​ they told me it is an extensive code fix and that it would be 2021.1 at the earliest.

Hello @philippev​ & @grattop​, sorry about the delay in response. I did look into potential workarounds, but there aren’t any that completely fit the bill (sort-of-speak).

 

AIXM xlink href geometry is challenging because this xlink referenced geometry in GML is designed to link geometry to other geometries, not geometry to features. The core problem here is that most AIXM we have seen which uses xlink href geometry is actually linking to other features, not geometry. So in effect you would have other features within these geometries, which is does not follow the GML standard or common GML practice. At this point our developers do not see a straightforward way to implement reading something that is not logically consistent with the GML standard. That said, it would be interesting to learn what other tools are able to read or work with this data.

 

Would you be able to share a sample AIXM that you’d like to be able to process in FME, and or names of applications you use currently to ingest AIXM (including xlink href)?

 

While investigating, I found a relevant parameter in our GML Reader. There is a section for GML SRS/Geometry Parameters with 'process xlink geometries'. This may prove useful, but success and performance depends on the structure & validity of GML. Note that you can use the GML reader to read AIXM data as long as you provide the appropriate application schemas, or they are referred to in the namespace header. This may be a potential workaround in some cases. Best, Kailin.


@grattop​ they told me it is an extensive code fix and that it would be 2021.1 at the earliest.

Hello Kailin,

 

Thank you for your message and your time!

 

I can confirm that unfortunately FME does not offer a workaround via GML reader or transformer settings. The GML SRS/Geometry settings with process xlink geometries are of no help.

 

You note that the AIXM xlink href geometry is a challenge as this xlink referenced geometry in GML is designed to link geometry to other geometries, this is surprising as in the case of AIXM the AirspaceTimeSlice feature geometries are linked to GeoBorderTimeSlice feature geometries. Indeed, a number of airspaces are built according to the consideration of the boundary. For example the EBR18B, the lateral boundaries are described as follows: "495850N 0040845E - an arc of circle, 25 NM radius, centred on 501437N 0043839E and traced clockwise to 501258N 0040000E - 501329N 0041041E - along the Belgian-French border - 495850N 0040845E. In this case, between the coordinates 501329N 0041041E and 495850N 0040845E of the AirspaceTimeSlice, the Belgian-French border geometry contained in the GeoBorderTimeSlice is used for this section.

Normally like this (with Luciad Hexagon):

imageBut with FME :

 

imageThis is at least how the AIXM data model is described by Eurocontrol (https://www.ead.eurocontrol.int/cms-eadbasic/opencms/en/ead-evolutions/page/) and included in the UML schema (https://www.aixm.aero/). This description is taken up in the OGC (https://www.ogc.org/pub/www/saa/index.html) and W3C.

 

The AIXM reader should build it directly. Given this bug, I try to overcome this problem by selecting the airspace concerned by a boundary and by a set of spatial selection, intersection and alphanumeric link via gml_parent_id: uuid.7ce3efcc-d992-494b-b9c2-d2c9a6798f8d ; gml_id: uuid.3 c72fe0f-9f2e-4f1f-8a1b-5a902d1c94ff; gml_parent_identifier: 7ce3efcc-d992-494b-b9c2-d2c9a6798f8d ; type: R ; designer: EBR18B between airspace and border I reconstructed the airspace boundaries as well as I could, but with a lot of problems, quite a lot of manual correction and poor performance. 

 

image 

I understand the difficulty of your developers, however if you could provide a Workbench to overcome this bug it would be a good point and would help us a lot.

 

I am happy to share the AIXM file that I use. I am sending it to you by email because of the confidentiality of the information contained. Can you give me an email address or a server?

 

As an example of software using AIXM, I can name Hexagon(Luciad) , the link is in my previous message, and esri via ArcGIS Pro with its Aviation Charting extension (https://pro.arcgis.com/en/pro-app/latest/tool-reference/aviation/import-aixm-5-1-message.htm) read without problem this type of format.

 

Hoping to have enlightened you and helped you to find a solution 😊

 

Have a nice day

 

Philippe


@grattop​ they told me it is an extensive code fix and that it would be 2021.1 at the earliest.

We have the same issue and a similar workaround; a big workspace where we follow the xlink:href ourself and then use that geometry, but still some problems.

 

Not directly related to this bug, but with the AIXM reader building geometry itself we ran into quite a lot of problems with the correctness of the airspaces. We now use the reader to get all the attributes but drop all geometry immediately and build it our self based on the information from the attributes.


@grattop​ they told me it is an extensive code fix and that it would be 2021.1 at the earliest.

Hello @philippev​ , thank you for your detailed response. I will be passing this information along to development. May I encourage you to submit a support case with us, in order to share your sample AIXM? I will pick up the case when I see it come through. Please feel free to do the same @matthieuv​! Thank you both for your understanding, Kailin.


@grattop​ they told me it is an extensive code fix and that it would be 2021.1 at the earliest.

Hello @kailinatsafe​ ,

 

Thank you for the proposition. The support case is submitted now.

 

Let me know if you have all info.

 

Have a nice day

 

Philippe


@grattop​ they told me it is an extensive code fix and that it would be 2021.1 at the earliest.

Hi @kailinatsafe​, as instructed above, I will also try to submit a support case to hopefully increase our odds of addressing this issue - is there something specific you require in the support case to facilitate the development? Thanks.


@grattop​ they told me it is an extensive code fix and that it would be 2021.1 at the earliest.

Hello @grattop​ , thank you in advance for your case submission. A sample AIXM that you'd ideally like to process with FME, and if you could shed light on any applications you currently use to consume/work with your AIXM (that can properly handle xlink:hrefs)? Hope this helps, Kailin.


Hello @kailinatsafe​ ,

 

It has been two weeks (11/25/2021) since the support was opened (Case: C665439).

 

Is it possible to have information about the progress of the resolution of the problem or a possible workaround?

 

Tank you for your time and your help,

 

Have a nice day

 

Philippe


@grattop​ they told me it is an extensive code fix and that it would be 2021.1 at the earliest.

Hello Kailin,

Please, can you give me feedback on the status of fixing this bug in FME?

Keep me informed of your progress.

Have a nice day,

Philippe


Philippe Vandevondele
Expert Urbanisme
T. +32 2 206 2452
M. +32 2 206 2452
Tervuursesteenweg 303 | B-1820 Steenokkerzeel
T. +32 2 206 21 11 | www.skeyes.be
BTW - TVA - VAT: BE0206.048.091
Member of FABEC
skeyes Mail Disclaimer

Hello @kailinatsafe​ ,

 

It has been two weeks (11/25/2021) since the support was opened (Case: C665439).

 

Is it possible to have information about the progress of the resolution of the problem or a possible workaround?

 

Tank you for your time and your help,

 

Have a nice day

 

Philippe

Hello @philippev​ , apologies for the delayed reply. Wanted to let you know we're actively working on this! Thanks again for helping us troubleshoot, Kailin.


Hello Kailin,

 

I am surprised not to have any information about this support, which I remind you is important and urgent.

 

What about the other workaround?

 

Thank you for keeping me informed.

 

Have a nice day

 

Philippe


Hello Kailin,

 

I am surprised not to have any information about this support, which I remind you is important and urgent.

 

What about the other workaround?

 

Thank you for keeping me informed.

 

Have a nice day

 

Philippe

Hello @philippev​ , thank you for following up. I'm including some more information about the issue.

 

The general problem here is that usually in GML when there is geometry by reference (eg. xlink href) the geometry link points to another geometry object. In the case of this dataset, the link points to another feature entirely - AirspaceTimeSlice geometries are linked to GeoBorderTimeSlice features. One challenge with this higher level linkage is that the geoborder geometry may extend beyond the airspace boundary and so a complex process of extracting just the appropriate parts of the geoborder is required in order to complete the airspace.

 

Its not atypical for AIXM datasets to be large and complex. So while we're expending significant effort exploring workarounds, and have proposed some that do work in limited cases, it is very likely that a more general solution will require significant new development effort on the AIXM Reader itself. This is why we have not been able to provide you with a solution to this yet, as we are waiting on a development fix / enhancement to handle this special case of related complex xlinked geometries.

 

I'm terribly sorry we haven't solved this yet, but I assure you we will continue to track this closely and let you know as soon as development makes progress on this.

 

Thanks for your understanding and patience, Kailin.


Reply