Zhihang Yao
Zhihang Yao
Is `val_is_xlink` more generic and can also be used for e.g. shared address? maybe `val_is_reference` is better because the "xlink" looks still XML/GML encoding specific.
The new `root_feature_id` should be a FK pointing to the corresponding top-level feature. This column would help for speeding up the export and delete process by avoiding recursive joins. Note...
There is already a "is_toplevel" column in the `objectclass` table. I think we can avoid such redundancy.
The following changes should be done for the two tables, since we don't map feature classes onto individual data tables anymore, 1. drop the column `join_table_or_column_name` from the `aggregation_info` table...
This column is not necessary. We can use NULL check of the `ade_id` to tell if a feature class belongs to an ADE.
We would like to avoid XML/GML-specific things. Also, the two tables have never reallly been used by the Importer/Exporter and ADE Manager
We need to decide which indexes should be registered into the "index_table" additionally: https://github.com/3dcitydb/3dcitydb/blob/v5-devel/postgresql/SQLScripts/SCHEMA/INDEX_TABLE/INDEX_TABLE.sql
More details: [3DCityDB_Geometry_Table.pdf](https://github.com/3dcitydb/3dcitydb/files/8803959/3DCityDB_Geometry_Table.pdf)
Drop the "name", "name_codespace", "description" columns from the appearance and surface_data tables
Drop these three columns for the alpha release. If we want to re-add the three columns, we need thought about making the `appearance` and `surface_data` tables to be subclass fo...
I think the `xml_source` column can be dropped. It is never used (at least in Importer/Exporter) in the current citydb v4.