AIXM 5.1 geometry from AirspaceTimeSlice not loaded when referenced with xlink:href
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
Page 2 / 2
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.
Hello Kailin,
Thank you for your message and your info about the progress.
Don't give up.
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.
Hi @kailinatsafe , following-up to see if there has been any progress with this issue.
Thanks,
Hi, @kailinatsafe I’m looking forward for a solution too.
Thanks
Good morning all,
I’ve found a possible workaround for our problem, please could you test it and share with me possible errors?
I used OGC GML READER, for AIRSPACETIMESLICE then folowing the attached schema I used aggragator and featuremerger. I also attached the configurations used.
Have a nice day.
Emanuele
Hi all,
I suggest you have a look at the newest release (2024.2), there have been updates to the AIXM reader which so far seems to resolve my issues with this (e.g. a reference to a geoborder).
It does require a slightly different way to read it, since the information is stored in the geometrycomponents and the logic to base, union and subtract has not been refined yet. The information is there, I would suggest deaggregating and using the geometrypropertyextractor to extract the Traits (if you leave the Extract Traits empty, it will extract all of them). Something to note is that when deaggregating you will find parts that are not a geometry part, but mostly storing other information, such as an activation or class, so after aggregating and extracting the data I need from activation and class, I have added an attributefilter to _geometry_name to specifically get the geometryComponent objects.
I have added a screenshot of when I was using the 2024.2 BETA with the TechPreview of this implemented AIXM 5.x reader. In the first screenshot you can see one airspace consisting of multiple parts. The second screenshot is an example of two airspaces that include a geoborder reference, which now seems to work well. Have not figured out the fine details of whether the intersection point is exactly right or not...