Skip to main content

Hi all,

I'm working on an assignemt where I must update positional information on objects stored in Avitech's Wiz@rd. Wiz@rd communicates through AIXM5.1 and I need to write complete AIXM5.1 objects back to be imported into Wiz@rd.

I receive a file containig, amongst other things, the UUID for an existing object and updated positional information. I request the existing data from Wiz@rd and receives this as a complete AIXM5.1 object. This is stored in a temporary file and read through FeatureReader to put the data into their correct attributes with which I can work. This seems to work correctly. Then I update the correct attributes with the new positinal information from my source file and write the complete object back using FeatureWriter.

My problem is related to the AirportHeliport object. The source AIXM5.1 contains aixm:subCondition group(s) whithin the aixm:usage group. I see these whithin the geometry aggregate after I have read the AIXM5.1 file, but the aixm:subCondition group(s) disappear when I have written the same object to my AIXM5.1 output file.

I have made a small workspace in FME Desktop 2019.1.1 build 19617, which reads the input AIXM5.1 file through FeatureReader and writes it back through the FeatureWriter. Still missing the aixm:subCondition group(s).

Any ideas or suggetions?

I've enclosed my litte test workspace, the input file and the output file.

I've made some progress on this by changing a key reader / writer configuration parameter.

Change Feature Properties > Map Embedded Objects from: 'Geometries' to 'Attributes'. This will cause the aixm:subCondition elements to be read as attributes instead of geometry traits.

There appears to be some problem with reading these highly nested objects as geometry traits. We will investigate further and let you know what we find. In the meantime try using this option on both your AIXM5 reader and writer. Note that for existing workspaces you will need to remove and re-add the reader / writer when changing this option as it affects the schema. Also note that while FeatureReader should work the same as the reader/writer, I find it easier to diagnose problems with the regular reader / writer since the schema that is scanned is clearly listed on the feature types.

See the attached example workspace: aixm52aixm5_heliport_safe.zip


Reply