Zhihang Yao

One more thought: The `cityobject_member` table of the 3DCityDB v4 could be dropped and add an FK column `citymodel_id` to the `feature` table instead, since the citymodel and cityobject/feature mostly...

In an offline discussion with @clausnagel and @thomashkolbe , we decide to drop the `citymodel` table for the alpha version. This also means the following two small changes in the...

Yes, I agree this is a quick fix. But again, this will voilate the naming convention of the current 3DCityDB. For example, the columns `lod1_solid_id`, `lod1_multi_surface_id` are FK columns referencing...

Done with [b4b7e6c](https://github.com/3dcitydb/3dcitydb/commit/b4b7e6c50298a7a7234c09a903e6406558690b57)

This doc should be used as starting point. @muratkendir is this an up-to-date version? https://github.com/tum-gis/3dcitydb-v5/blob/master/docs/meeting_recordings/2021_11_02_feature_types_and_super_classes_by_space_Kendir.xls

Thanks @muratkendir. This doc provides a very good overview. Since a number of new classes are introduced in CityGML 3.0, we have to assign new IDs to them. Besides, the...

_name of the most specific CityGML abstract space or space boundary class (e.g. AbstractOccupiedSpace)_ accroding to this doc https://github.com/tum-gis/3dcitydb-v5/blob/master/docs/meeting_recordings/2021_10_19_3DCityDB_Version_5.0_Kolbe.xlsx

Let's move `space_or_boundary_type` to the objectclass table for alpha version

Good idea

好提议，非常期待在新版本中加入这个功能支持。