Zhihang Yao
Zhihang Yao
This ist a deprecated column, since the `feature_relation` table dosn't exist anymore
We want to use the `feature` table to store mulitple versions of the same city objects, and the `gmlid` column values may not always keep UNIQUE. The UNIQUE constraint must...
We note that it would be more efficient/easier for performing address queries, if the complex xalAddress data are mapped onto a separate table `address` like in the current 3DCityDB v4.
We'll add a new column `lod` to the property table for facilitating e.g. lod filter export. The first proposal for alpha release is to use string type to store any...
A tiny change to make the naming consistent like in the table `implicit_geometry` and `tex_image`
The following UNIQUE constraint is defined in the current `property` table: ``` CONSTRAINT property_unique_feature_id_namespace_name_index UNIQUE ( feature_id, namespace, name, index_number ) ``` How about the following case, where the unique...
Most FK columns (e.g. `val_grid_coverage`, `val_appearance`, `val_dynamizer`) follows the naming convention "val_[referencedTable]". An exception is `val_implicitgeom_id`. We should make it consistent by renaming this column to `val_implicitgeom` or add the...
It is currently not clear, which columns (especially in the `feature` and `property` tables). We have to decide it for the Alpha release.
[DbSchema ](https://dbschema.com/)is a good database design tool that could be used for the upcoming major release v5. It comprises a number of nice features regarding e.g. flexible graphical layout, which...
The materialized views are used for rebuilding the 3DCityDB v4 table structures, which allows the current Importer/Exporter tool to access the data stored in the 3DCityDB v5 tables. It is...