Geometric invalidity in the conversion from CityGML to CityJSON

[ozgetufan]

Hello,

I converted a file from CityGML to CityJSON using citygml-tools. While the CityGML file is valid (checked with FME, 3DCityDB, val3dity), the output CityJSON file seems to be invalid when it comes to the geometries. There are consecutive duplicate points in boundaries, and val3dity reported other errors as well (CONSECUTIVE_POINTS_SAME, RING_SELF_INTERSECTION, INTERSECTION_RINGS, etc).

Since the input CityGML file is valid, I thought this would be related to the conversion to CityJSON.

Thanks!

[clausnagel]

Check the number of significant digits of the geometry vertices in your CityGML file. Then use the --vertices-digits parameter of the to-cityjson command to set the number accordingly. The default value is 3, which means that only 3 digits are kept in the conversion. I guess this number is not enough for your data.

[ozgetufan]

Thanks for your answer!

In the CityGML file, the number of digits kept is 3 as you can see in the example below.

I still tried to use the --vertices-digits option to test keeping more digits (tried with 5, 7, 10, 20) with this command:

citygml-tools to-cityjson --vertices-digits=10 my_file.gml

But I still get the same errors in the end.

I also tried to increase the number of digits in the 3DCityDB Exporter as you described in that issue, but again I get the same errors.

[clausnagel]

Please provide (an excerpt of) your original CityGML file for testing and reproducing the issue. Thanks.

[ozgetufan]

Here is a subset of the CityGML file, thank you for all the help.

subset.zip

[clausnagel]

Thanks for sharing the file, @ozgetufan. Here are my findings:

1. Your CityGML file already contains geometry errors. For example, check the linear ring with the gml:id Polygon_UUID_e38b1261-4042-4463-a6f8-59bfb193d7e9_0_. The vertex [232035.577, 479958.526, 28.442] is duplicate for this ring. I checked your dataset with the CityDoctor validation tool (download an installer from here), and it finds more errors. Here is the full CityDoctor validation report: citydoctor-validation-report.zip. I also converted the dataset to CityJSON with citygml-tools and compared the converted geometry with the original CityGML file. According to my tests, the converted geometry is identical and citygml-tools does not change it. So, I cannot see a citygml-tools issue here. I cannot say why val3dity does not report the geometry errors in your CityGML file. I guess the val3dity folks can better help you with this.

2. However, I found another bug in citygml-tools. Some of the boundary surfaces in your CityGML dataset have a generic type attribute. When converting to CityJSON, citygml-tools adds this attribute to the corresponding semantic surface in the CityJSON file. However, this overrides the predefined "type" attribute of the semantic surfaces which is used by CityJSON to classify the semantic surface as, for instance, "WallSurface" or "RoofSurface". Thus, the semantic surfaces in the CityJSON output are not correctly classified and the output is invalid. I will fix this bug by omitting the generic type attribute in the conversion. As a workaround, I recommend that you rename the type attribute in your original CityGML files. If you have loaded all your CityGML into the 3DCityDB, then this can be easily done with a single update statement on the cityobject_genericattrib table.

[clausnagel]

Fixed #2 in master (663872d0d86db0790979c10693b961aff5642bda). The fix will be available in the next release. In the meantime, you can either build your own version from master or use the latest Docker image from DockerHub.

[ozgetufan]

Ah I see, I will check the input data to fix the geometry errors. Thank you so much for all the help!