search

3dcitydb / citydb-tool

3D City Database 5.0 CLI to import/export city model data and to run database operations
Apache License 2.0
9 stars 2 forks source link

Store relation type for feature properties #12

Closed clausnagel closed 8 months ago

clausnagel commented 8 months ago

This PR proposes to replace the val_reference_type column of property with a new val_relation_type column.

val_reference_type is currently used to store information about whether a sub-feature is stored inline (value = NULL), as local reference (value = 1) or as global reference (value = 2). These values reflect the use of XLinks in the CityGML input dataset and allow to rebuild the XLinks during export. The value of val_reference_type is also used in recursive SQL queries to rebuild a feature hierarchy and to exclude features that are not part of the hierarchy. And the DELETE script uses the information to evaluate whether a referenced feature should be deleted (because it's part-of) or not.

The issue with val_reference_type is that the value depends on the context of the feature that is imported. For instance, when a building is imported, the decisision whether an XLink is considered to be "local" or "global" depends on whether the referenced feature is a sub-feature of the building or not. As long as we just export the same building again, the values of val_reference_type are fine, of course. However, as soon as we export a sub-feature of the building, the question whether references are "local" or "global" must be answered from the context of this sub-feature and not the building. Thus, the values stored in val_reference_type might be wrong for the sub-feature.

To solve the issue, val_reference_type is replaced with val_relation_type by this PR. The new column now stores the information whether the relation between a feature and its sub-feature is an aggregation (part-of, value = '1') or a simple association (value = '0'). For example, the "boundary" relation in CityGML is considered an aggregation, whereas the "relatedTo" relation is just an association. This information does not depend on the context of the feature that is imported or exported but follows from the CityGML schema (or of another input format). With this change, recursive SQL queries to retrive feature hierarchies now produce stable and deterministic results independent of the feature to be exported. Same is true for the DELETE script. And XLinks can still be correctly set in the output format.

yaozhihang commented 8 months ago

Nice, the feature XLINKS work now much more cleanly.