3DCityDB 4.x: delete CityObjectGroup WITHOUT its members? about 3dcitydb HOT 3 OPEN

Yes, the behaviour of this delete function has been changed since 3DCityDB 4.0. When deleting a CityObjectGroup, its members are only deleted if they are not referenced by another CityObjectGroup.

from 3dcitydb.

Hi Zhihang!

Thanks for the quick reply. A couple of comments:

• Maybe this behaviour should be stated somewhere in the documentation. The del_cityobjectgroup behaves indeed a bit differently from the other functions (and compared to the past!) and my impression is that it could lead to unwanted "disasters"... :-)

• Then we are missing the option to simply delete the cityobject group.

• Maybe:

a) the default behaviour of function del_cityobjectgroup should NOT delete the group members. This is also the one that it is called from within del_cityobject().

b) To delete also the members, there could be another ad hoc function (e.g. del_cityobjectgroup_cascade(int[]) which works as the current one. On the one hand we have another function (unlike 3DCityDB 3.x), but on the other hand it is rather easy to add.

What do you think? Just my two cents! ;-)

All the best!

GA

from 3dcitydb.

Hi Giorgio,

thanks very much for your comments. Since 3DCityDB version 4.0, all delete and envelope function code have been automatically derived using the ADE-Manager plugin. The derivation follows a set of common rules in order to support CityGML ADEs in a generic way. One rule is the followings:

1. Classes with association relationship: If one object is deleted, the associated objects will not be deleted.
2. Classes with aggregation relationship: If a parent is deleted, the children will only be deleted if it has no other parent. (This is the case for CityObjectGroup)
3. Classes with composition relationship: If a parent is deleted, the children will be deleted immediately.

The meta-information about the class association types can be obtained from the 3DCityDB aggregation_info table, where the first row refelects the aggregation relationship between CityObjectGroup and _CityObject.

I fully agree with your points. Although the CityObjectGroup and _CityObject has an aggregation relationship, the delete function should behave differently, since the children are top-level features and they shall not be deleted in a cascaded fashion. (in most practical use cases)

I'll try to improve this for the next 3DCityDB version.

Cheers,

Zhihang

from 3dcitydb.