Unsupported geometry type MULTI_GEOMETRY, Data is int CityGML format LOD3 level

[SurajitChowbey]

Unable to import CityGML format data which is in LOD3 level.
I have uploaded the error log data with this issue.
error.txt

[FxKu]

This is a known limitation of the Importer/Exporter. Usually, you can fix it yourself by changing all MultiGeometry properties into MultiSurface ones. See also #27.

[SurajitChowbey]

Thanks, now I am getting the error but, still the Multi data is not getting displayed.
Can you please tell me where can I get this kind of information that Importer/Exporter support this not this.
I really appreciate your help.

[FxKu]

Like in #27 it helps if you can provide sample data . Objects modelled with gml:MultiSurface should be displayed. Unsupported features are usually documented in the manual. Not in this case afaik, so we should add this info.

[SurajitChowbey]

Okay I have upladed the sample data.
link:
https://drive.google.com/open?id=0ByPmpvXvo7O2TnRPcHRnUGV5c3M

[FxKu]

so I removed all the multigeometry objects and was able to see some pipes in Google Earth

[SurajitChowbey]

Yes, it should look like that.
I'm new in this field so, I don't have good knowledge in it.
Can you please guide me what changes I need to do in the GML file and also, please send me the updated gml file, so I can understand it better.

My mail-id: [email protected]

Thanks for your time.

[FxKu]

You are working with FME, right? Maybe you can change the CityGML write process, that it does not write these MultiGeometry properties. I simply removed the corresponding tags (incl. geometry member) from the XML file within a text editor. Got some XLink errors during the import, but the export looks ok. Try it out. Have to catch my plane, now :)

[SurajitChowbey]

Thanks for your time.
I have tried a lot and still doing it, but as I new in this domain, still not getting the right result from the CityGML file.

It will be very helpful for me, if you please share the modified CityGML file.

[FxKu]

Alright. I've send the file to your address.

[SurajitChowbey]

Thanks, it's working.
You may close this issue.

[FxKu]

Closing issue. Feel free to re-open if new questions arose regarding MultiGeometry properties.

[lsdanger]

Hello everybody,
I have the same issue as described by SurajitChowbey. I created a CityGML document containing Solitary Vegetation Objects with Implicit Representation using FME and this template (https://hub.safe.com/templates/citygml-create-solitaryvegetationobject-with-implicit-representation)

I tried to edit the file in Notepad++ to remove the MultiGeometry properties but didn’t achieve to output a valid CityGML file. I tried contacting the support mentioned in the link of the template to ask about this issue but didn't get a response. I uploaded the CityGML file to: https://1drv.ms/u/s!AgkAhopG56qAhmM-H2r3JZeAnS4q and would be thankful for support regarding this issue.

[FxKu]

The next release will support CityGML with MultiGeometry properties - at least if it consists out of polygons, regarding to b70b656. Thanks @clausnagel ! Close, when you think it's done.

[clausnagel]

@lsdanger I took a look at your dataset. Your implicit geometry not only uses a gml:MultiGeometry, but a hierarchy of nested gml:MultiGeometry elements. For the simple tree geometry you want to store (which basically consists of a bunch of polygons) this is way too complicated and unnecessary. So my first recommendation is to fix your FME workspace and get your data right.

Nevertheless, I wrote some lines of code to let the importer support gml:MultiGeometry. If the gml:MultiGeometry only contains surface geometries then it implicitly gets converted into a gml:MultiSurface which can be handled by the 3DCityDB. So your nested tree of gml:MultiGeometry elements results in a single gml:MultiSurface (so a bunch of polygons...)

Hope this helps. You have to build the Importer/Exporter from the master branch in order to test this new behaviour.

@SurajitChowbey Hope this fixes your issue as well.

[lsdanger]

@clausnagel Thank you for your response and great effort at improving the 3DCityDB. I was able to fix my FME Workspace and change the GeometryType to MultiSurface by adding a GeometryRefiner Transformer right after the tree model input. But I still have trouble with the export. The file validates and after importing this is the log:

[12:30:41 INFO] Resolving XLink references.
[12:30:41 INFO] Resolving geometry XLinks...
[12:30:41 INFO] Cleaning temporary cache.
[12:30:41 INFO] Imported CityGML features:
[12:30:41 INFO] IMPLICIT_GEOMETRY: 1
[12:30:41 INFO] SOLITARY_VEGETATION_OBJECT: 219452
[12:30:41 INFO] Processed geometry objects: 549
[12:30:41 INFO] Total import time: 35 s.
[12:30:41 INFO] Database import successfully finished.

Which looks OK to me. The file is also getting correctly displayed in FME Data Inspector. The export writes no errors as far as I can see but the output looks like this:

[13:24:01 INFO] Exported CityGML features:
[13:24:01 INFO] SOLITARY_VEGETATION_OBJECT: 6
[13:24:01 INFO] Processed geometry objects: 1644
[13:24:01 INFO] Total export time: 19 m, 59 s.
[13:24:01 INFO] Database export successfully finished.

I don't know why six features get exported but it could be due my Postgis Database being jumbled. Could also only be one exported solitary vegetation object in a fresh database (I'll try and report back asap). EDIT: This the case. Only one solitary vegetation object gets exported. My guess is that there is an issue with the xlink refernces or how i build the implicit geometry. But I don't know how to tackle the issue as there are no error messages.

EDIT2: The issue was not with my data but in the database. I found this hint in the documentation to solve my export issue.

The calculation of the bounding box is based on the values stored in the ENVELOPE column of the CITYOBJECT table. If this column is NULL or contains an incorrect value (e.g., in case the value could not correctly filled during import or the geometry representation of a city object has been changed), then the resulting bounding box will be wrong and subsequent operations might not provide the expected result. To fix the ENVELOPE values in the database, simply let the Importer/Exporter create missing values (i.e., replace NULL values) or recreate all values by clicking on the corresponding buttons [5]. This update process either affects only the city objects of a given feature type or all city objects based on the selection made in [1].
Note: This process directly updates the ENVELOPE column of the affected city objects and might take long to complete since the new values are calculated by evaluating all geometries of the city objects in all LoDs including implicit geometries.__

[FxKu]

Ok, I think we can close this issue now. @lsdanger glad you were able to change your FME workbench to produce better CityGML :)