Murat Kendir

@yaozhihang you have right, it is never used, but you may remember that we have copied addresses into feature table. In upsert scripts, i stored xal_source columns into two different...

Actually, i don't suggest to drop any columns at this moment. Even it is useless / always empty, it should be kept till to decide a "total revision". The reason...

@clausnagel If input dataset is CityJSON, then we can use val_complex column, it is in json data type. @yaozhihang if we will convert val_xml into text data type, then it...

> The most generic solution would be to keep such snippets independent from a specific encoding. I am not agree with this statement, i mean if it is really generic...

is_toplevel column in objectclas table can only store hierarchical relation between objectclasses, on the other hand is_toplevel column in feature table can give brief information about hierarchical status between even...

It is a column to keep properties decomposable. For example. lod2Solid properties in the table have namespace values as "core", name values as "lod2Solid" and they have "gml:Solid" as datatype...

I feel myself very conservative at this moment :) So, i prefer to keep datatype column.

Need to check that, actually defining as character varying will be enough for postgresql, but not i am not sure about Oracle.

I think no, we don't need to use materialized views in 3DCityDB_v5 empty schema, because they designed to re-produce (reversely populate) the data from new tables as original (v4) tables....

It is in address table, which is actually considered as feature in upgrade scripts. Yes, objectid should be rewritten as object_id, but also there are another things that we need...