If you are writing out any geometries with the solid (the building) this could be where the duplication comes from. Have you used a GeometryRemover before the buildings? Would that work? Sorry without seeing the workspace itself I can't really tell if what I said is valid.
If you are writing out any geometries with the solid (the building) this could be where the duplication comes from. Have you used a GeometryRemover before the buildings? Would that work? Sorry without seeing the workspace itself I can't really tell if what I said is valid.
Thanks for your reply! Yes, I have already tried that. With a GeometryRemover inbetween the Solid will be left out completely in the final document. I believe this arises due to the fact that the lod2Solid statement within the citygml_feature_role trait which is used by the Building Feature Type writer is also removed by the GeometryRemover. I will add my workspace so that you can have a closer look.
Thanks for your reply! Yes, I have already tried that. With a GeometryRemover inbetween the Solid will be left out completely in the final document. I believe this arises due to the fact that the lod2Solid statement within the citygml_feature_role trait which is used by the Building Feature Type writer is also removed by the GeometryRemover. I will add my workspace so that you can have a closer look.
Hmm, looking at the created files, I think is still wont work. You need to create a gml:id on the geometries themselves - this would be at the surface/polygon level. The xlink can either be on a geometry inside the solid or inside the list of boundedBy features.
In addition the geometry which is to be represented by the xlink needs to have this xlink as a trait. For this to work it requires the writer to recognize this trait and then know not to write out the geometry by just the trait in the format of the correct xlink.
Indeed when viewing the file created without the GeometryRemover I would expect to see FME to duplicate the geometries somewhere but when reading it doesn't which suggests that, unfortunately, this method isn't sufficient for creating geometry links.
Note that we are working on xlinked geometry support for FME 2019 - hopefully something will be available in a month or so. The approach that Matt described might work, but once we have full support you will only need to set an advanced setting on the writer to control whether you want to preserve or resolve geometry links, and then FME will do the rest.
At the moment there are 2 approaches - you can either try to set the geometry properties and see if they are written out correctly by the CityGML writer as Matt suggested. The other approach is that for a few versions now for the GML writer (not CityGML) we changed fields of data type = xml_geometry to accept xml as well as geometry. That means if you create a field with the same name as the xml_geometry field, and you remove the feature geometry, you can use a combination of GMLFeatureComposer, GeometryExtractor and XMLTemplater to customize your geometries before you write them. You could try this using the GML writer with the CityGML app schemas for one or 2 feature types. But this is rather involved, low level GML/XML work, and wouldnt support textures, so I expect it would be a lot easier to just wait for xlink geometry support coming soon in FME 2019.
Note that we are working on xlinked geometry support for FME 2019 - hopefully something will be available in a month or so. The approach that Matt described might work, but once we have full support you will only need to set an advanced setting on the writer to control whether you want to preserve or resolve geometry links, and then FME will do the rest.
At the moment there are 2 approaches - you can either try to set the geometry properties and see if they are written out correctly by the CityGML writer as Matt suggested. The other approach is that for a few versions now for the GML writer (not CityGML) we changed fields of data type = xml_geometry to accept xml as well as geometry. That means if you create a field with the same name as the xml_geometry field, and you remove the feature geometry, you can use a combination of GMLFeatureComposer, GeometryExtractor and XMLTemplater to customize your geometries before you write them. You could try this using the GML writer with the CityGML app schemas for one or 2 feature types. But this is rather involved, low level GML/XML work, and wouldnt support textures, so I expect it would be a lot easier to just wait for xlink geometry support coming soon in FME 2019.
Awesome @DeanAtSafe, Thanks for the great feedback on this!
Many thanks to both of you @virtualcitymatt and @DeanAtSafe !
It's good to know, that xlink support is officially on the way, as it is such an integral part of CityGML as well as its ADEs. Also FME is about the best available and versatile tool for implementing different kinds of data in CityGML. I will try to achieve some results with the suggestions you provided and keep you updated!
It looks like this This is now supported in the FME 2019.0 beta! Thanks @DeanAtSafe! I'm gonna give is some testing.
Hello again everyone,
since the CityGML writer in FME 2019 received an update and can now use a xlink_href trait in order to write geometry references, which is exactly what I needed earlier when I origanlly posted this Question. I played around with it a Little bit but couldn't figure out the correct procedure to produce a valid file.
Can someone provide me with an Explanation or demo workbench (ideally Trimble SketchUp2CityGML) in which this is demonstrated how to create a Solid geometry with Xlinks refering the BoundarySurfaces? Or Maybe a good Explanation will also do the trick.
Im just not sure how to create the solid and what goes into the Building writer and what should go into the Writers for the surfaces?
Many thanks in Advance!
Kind regards,
Philip
Hello again everyone,
since the CityGML writer in FME 2019 received an update and can now use a xlink_href trait in order to write geometry references, which is exactly what I needed earlier when I origanlly posted this Question. I played around with it a Little bit but couldn't figure out the correct procedure to produce a valid file.
Can someone provide me with an Explanation or demo workbench (ideally Trimble SketchUp2CityGML) in which this is demonstrated how to create a Solid geometry with Xlinks refering the BoundarySurfaces? Or Maybe a good Explanation will also do the trick.
Im just not sure how to create the solid and what goes into the Building writer and what should go into the Writers for the surfaces?
Many thanks in Advance!
Kind regards,
Philip
Hi @phiber,
Great question - it's a little tricky and to get it right - what worked for me was to actually see how FME read in the data from a correct building and work backwards.
There is a lot of GeometryProperies which cause headaches. Essentially each Wall, Ground, Roof surface making up the solid needs to be reference in the GeometryProperties of the solid (see below for what works for me on output).
Hi @phiber,
Great question - it's a little tricky and to get it right - what worked for me was to actually see how FME read in the data from a correct building and work backwards.
There is a lot of GeometryProperies which cause headaches. Essentially each Wall, Ground, Roof surface making up the solid needs to be reference in the GeometryProperties of the solid (see below for what works for me on output).
Hi there @virtualcitymatt,
thanks for your reply and many thanks for your input - I finally got it to work. Still I'm wondering if the 2019 version will also create thermalBoundaries with the (formally specified in the docs) energy_relatesTo{}xlink.href attribute? Do you have any experiences in this direction or should I better just be happy with what can finally be achieved?
Kind regards!
Hi there @virtualcitymatt,
thanks for your reply and many thanks for your input - I finally got it to work. Still I'm wondering if the 2019 version will also create thermalBoundaries with the (formally specified in the docs) energy_relatesTo{}xlink.href attribute? Do you have any experiences in this direction or should I better just be happy with what can finally be achieved?
Kind regards!
Hi @phiber, sorry I don't know about that specifically. I suspect that it should work in the same kind of way. But again I would try reading a test file where this is correctly implemented and work backwards - but perhaps @deanatsafe has some more information as to the xlinks and if it extends to ADE's for CityGML as using xlinks does not appear to be an option in the general GML writer.
@deanatsafe any chance this will make it into the AIXM5 reader?
@deanatsafe any chance this will make it into the AIXM5 reader?
Hi @drones_n_maps: thanks for your comment! I would suggest posting a New Idea on the Ideas Forum for greater visibility.
Hi there @virtualcitymatt,
thanks for your reply and many thanks for your input - I finally got it to work. Still I'm wondering if the 2019 version will also create thermalBoundaries with the (formally specified in the docs) energy_relatesTo{}xlink.href attribute? Do you have any experiences in this direction or should I better just be happy with what can finally be achieved?
Kind regards!
Hi @phiber. I'm trying to build a citygml LoD2 model from CAD data and i´m stuck in this surface referencing. The data samples that i found online set the building as composite surface and the xlink_href to the wall/ground/roof surface as surfaceMember. Would you mind sharing your solution? I have tried everything to set the xlink_href as a surfaceMember without success.
Thanks in advance!
Hi @phiber. I'm trying to build a citygml LoD2 model from CAD data and i´m stuck in this surface referencing. The data samples that i found online set the building as composite surface and the xlink_href to the wall/ground/roof surface as surfaceMember. Would you mind sharing your solution? I have tried everything to set the xlink_href as a surfaceMember without success.
Thanks in advance!
Hi @mamaieron,
Have a look at this if you haven't already:
https://hub.safe.com/publishers/con-terra/templates/citygml-create-building-lod-2-using-xlinks
Thank you very much for the reply @virtualcitymatt! I followed the steps and got the same standard in my xml output. Unfortunately, there is still a problem I have to deal with. In the case of two buildings sharing a surface, there must be an xlink on each one for the shared surface; this is possible, however, the gml_parent_id attribute of the surface does not allow double filling. Therefore, a surface can have only one parent building. From the modeling point of view it is correct, however, in this case it creates a problem. To illustrate, I put the example below, where only one gml_parent_id was placed for the surfaces. When I deleted a building, the surfaces that were shared, despite being referenced, do not appear. Do you have any thoughts on that? Thanks again for the workspace and attention.
Hi @virtualcitymatt. I figured out how to keep xlinks_href traits to both parents. I had the gml_id of the parents in a list(surface_parent_id{}.gml_id), so i i used two separeted attribute managers to set a new gml_id followed by a simple aggregator grouping by gml_id. The nexts and previous steps are in the workspace you pointed me. Thanks again for your help!
