CityGML Plantcover to cityJSON

[ZehraKoc91]

Hello. I am dealing with converting CityGML tree files to CityJSON files to reduce file size.

In my case, 6 images (3 different tree trunks and tree) have been used. CityGML tree features were also completed in the FME workspace using random pictures (one pair of three tree images) for100 tree features.

Finally, when I converted my CityGML file to CityJSON, it returns with 3 tree features instead of 100. Is that because the appearance folder has 6 images or something else about tree conversion? If I use 200image pairs for 100 trees, it doesn't make sense to reduce file size.

Thanks in advance.

[clausnagel]

Hi @ZehraKoc91, not sure that I fully get the issue. In general, both CityGML and CityJSON support the concept of "implicit" (CityGML) or "template" (CityJSON) geometries, where you store the geometry only once and reuse it for multiple and different objects. If the use of implicit geometries is correct in your CityGML input file, then citygml-tools should correctly map them onto CityJSON template geometries in the output file.

Can you please provide a test dataset to reproduce the issue?

[ZehraKoc91]

agaccityjson.zip Hi,

I have uploaded my test data both CityGML version and converted CityJSON file result into the zip file. In CityGML I have 100 trees and in the converted CityJSON file has 3 trees.

[clausnagel]

Thanks. The CityGML file is empty, unfortunately. Could you please upload it once more?

[ZehraKoc91]

agaccityjson.zip Hi, Sorry for missing the data. I uploaded again.

[clausnagel]

Thanks. Ok, I checked the CityGML file and it really has a lot of issues. You can easily unreveal some of the issues by performing an XML validation on the dataset using citygml-tools:

$ citygml-tools validate xml /path/to/your/deneme_agac3.gml

This command reports not less than 113,080 errors in the file. Wow. Who or how was this file created? Most of the errors are because of duplicate gml:id values, which must be unqiue within one and the same dataset.

This is also the reason why your CityJSON output file only contains one city object. All trees in the CityGML file share the same gml:id "Agac1". In CityJSON, this id value is used as key for the "CityObjects" collection. And since the keys in this collection must also be unique, there can only be one CityObject with "Agac1" as key.

For test purposes, I therefore removed all gml:ids of value "Agac1" from your CityGML input file. Afterwards, all trees are contained in the CityJSON output file: deneme_agac3_new.zip. Note that citygml-tools is very forgiving and can produce an outpout file even though there are so many more issues in the input file.

Ok, some things you should repair in your CityGML file:

• PlantCover is the wrong CityGML feature type for single trees. Use SolitaryVegetationObject instead.
• The CityGML file is not using the concept of implicit geometries. In contrast, every tree object has its own geometry. This might also explain why the geometries share the same gml:ids. As a consequence, the converted CityJSON output does neither use template geometries. You should really consider using implicit geometries. This would not just reduce file sizes (both for CityGML and CityJSON) but would also improve, for instance, visualization of a high number of trees.
• Due to the high number of duplicate gml:ids, also the assignment of textures in your CityGML is crap (because of a lot of redundancy) and must be fixed.

[ZehraKoc91]

Thank you so much! I have realized the issue. I just used FME for the generation of CityGML tree files and also the files were published on Cesium, so I didn't check the resulted gml files for validation just used the tool to convert them to CityJSON. With the file you have provided I understood the problem and also regulated my CityGML files as correcting the workspace of generation. Thank you. The next step is to chance featuretype for trees from plantcover to solitaryvegetationobject.

[clausnagel]

Good to hear. Closing this issue now. Feel free to re-open if you need more support.