Zhihang Yao

According to the offline discussion, we decided to keep the `address` table. Address features should be registered in the `feature` table See https://github.com/3dcitydb/3dcitydb/issues/146

OK, let's drop the column for the alpha release. I'll keep this ticket unclosed. Maybe we'll see some use cases, that need this column.

yes, for the current use case for storing the raw xalAddress content, the text/clob type should be sufficient enough.

How about rename `val_xml` -> `val_source` and use text/clob type for storing json and xml data? Also, we can add a new column `val_source_mime_type` to indicate the type of the...

~~So, we add a column `address_lines` in JSON type~~?

Done with 41f9b12

In general, I would like to drop all QUNIQUE constraints (e.g. unique_codelist_entry_codelist_id_code, unique_codelist_entry_codelist_id_code)from the alpha version of the 3DCityDB v5. No benefit regarding performance.

_the datatype should be given as a qualified datatype name from the CityGML schema (e.g. gml:GenericName, gml:DateTime)_ according to this doc https://github.com/tum-gis/3dcitydb-v5/blob/master/docs/meeting_recordings/2021_10_19_3DCityDB_Version_5.0_Kolbe.xlsx

agree with @clausnagel

@BWibo You summary about the release mangement is totally correct. I think we need Docker builds for _pre-releases/alpha releases_, which will be helpful for dev/testing purposes. I am not sure...