Skip to main content
Solved

CityGML: XLinks for referencing BoundarySurfaces onto Solid geometry.

P
Forum|alt.badge.img

Hello everyone,

 

I need urgent help with my workspace for converting Sketchup to Citygml. Some posts among the forum say that FME wouldn't support the creation of XLinks. Therefore I created my workbench according to this old "How to write Citygml in FME"-Tutorial and used gml_id and gml_parent_id to express the part-whole-relationships. Now I found that if I use the Citygml_feature_types.xml file within the program folder to import the Writer Type, the autocomplete function provides a list attribute called citygml_bounded_by{}.xlink_href. I tried it out and indeed it created XLinks for the gml_ids I gave to it, but how can I manage to create a Solid with only XLinks referencing the BoundarySurfaces? With my current workspace it creates the geometries for the BoundarySurfaces twice + XLinks once.

 

I hope you guys can help me -- many thanks in advance. I can also provide sample files to clearify my problem.

 

Kind regards,

 

Philip

Best answer by deanatsafe

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.

View original
Did this help you find an answer to your question?

17 replies

virtualcitymatt
Celebrity
Forum|alt.badge.img+34

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.

P
Forum|alt.badge.img
  • phiber
  • Author
  • October 15, 2018
virtualcitymatt wrote:

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.
virtualcitymatt
Celebrity
Forum|alt.badge.img+34
phiber wrote:
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.

 

 

 

 

deanatsafe
Safer
Forum|alt.badge.img+6
  • deanatsafeSafer
  • Safer
  • Best Answer
  • October 22, 2018

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.

virtualcitymatt
Celebrity
Forum|alt.badge.img+34
deanatsafe wrote:

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!

 

P
Forum|alt.badge.img
  • phiber
  • Author
  • October 24, 2018

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!

virtualcitymatt
Celebrity
Forum|alt.badge.img+34

It looks like this This is now supported in the FME 2019.0 beta! Thanks @DeanAtSafe! I'm gonna give is some testing.

P
Forum|alt.badge.img
  • phiber
  • Author
  • June 10, 2019

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

virtualcitymatt
Celebrity
Forum|alt.badge.img+34
phiber wrote:

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).

 

P
Forum|alt.badge.img
  • phiber
  • Author
  • June 11, 2019
virtualcitymatt wrote:

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!

virtualcitymatt
Celebrity
Forum|alt.badge.img+34
phiber wrote:
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.

drones_n_maps

@deanatsafe any chance this will make it into the AIXM5 reader?

nampreetatsafe
Safer
Forum|alt.badge.img+12
drones_n_maps wrote:

@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.

M
phiber wrote:
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!

virtualcitymatt
Celebrity
Forum|alt.badge.img+34
mamaieron wrote:

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
M
virtualcitymatt wrote:

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.

M
virtualcitymatt wrote:

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

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!

Reply


Helpful Members This Week

Community Stats

30,944
Posts
117,267
Replies
38,743
Members

Latest FME

Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.