Zhihang Yao

If necessary, we may consider adding this functionality to the KML/COLLADA/glTF-Exporter in the future release.

Have you implemented the Java code for importing your surface geometries? Please check the example code of the Test ADE here: https://github.com/3dcitydb/extension-test-ade/blob/master/test-ade-citydb/src/main/java/org/citydb/ade/test/importer/BuildingUnitImporter.java#L162

I think such kind of `heathcheck` function is good. We coud extend this function in future and use it to do heath check of migrated or upgraded 3DCityDB instance.

Fully agree. The name `featureid` is good. `feature_id` looks like a bigint FK column.

Yes, the behaviour of this delete function has been changed since 3DCityDB 4.0. When deleting a CityObjectGroup, its members are only deleted if they are not referenced by another CityObjectGroup.

Hi Giorgio, thanks very much for your comments. Since 3DCityDB version 4.0, all delete and envelope function code have been automatically derived using the ADE-Manager plugin. The derivation follows a...

Well, pgModeler supports the type modifiers (e.g. POINTZ, LINESTRING, POLYGON, POLYGONZ) for geometry columns. The current [schema scripts](https://github.com/3dcitydb/3dcitydb/blob/master/postgresql/SQLScripts/SCHEMA/SCHEMA.sql) were automatically derived from the pgModeler model and use the geometry type...

OK, I've investigated futher the DbSchema tool. It allows to define new column data types e.g. `geometry(POINTZ)`. So, DbSchema should be sufficient enough for our 3DCityDB v5

The table `geometry` must be renamed, because "geometry" is a keyword used by PostGIS and may cause unexpected issues. My proposal is to rename it to `explicit_geometry` or `geometry_info` or...

"will" cause the issue. Wenn using the "geometry" table name, i got the following error when creating the schema: ``` ERROR: FEHLER: Typmodifikator ist für Typ »geometry« nicht erlaubt ```