Since there is only a one-to-many relationship between semantic surfaces (just like in case of CityObjects), do we need to explicitly define the child --> parent relationship (eg. blue Door in example), or is defining child <-- parent enough (eg. red Door)? What is the reason for having both "children" and "parent"?
I see the existence of both "children" and "parent" property as an invitation for inconsistency, just like @clausnagel in his 3rd point in https://github.com/tudelft3d/cityjson/issues/38 . Also it means that one needs to double check the links between children and parents to make sure all relationships are discovered.
Furthermore, if the "parent" property is needed, does it make sense to harmonize it with the CityObject's "parentS" property, which is an array? Even though it would be an array with a single element most (all) of the cases.
Since there is only a one-to-many relationship between semantic surfaces (just like in case of CityObjects), do we need to explicitly define the child --> parent relationship (eg. blue Door in example), or is defining child <-- parent enough (eg. red Door)? What is the reason for having both "children" and "parent"?
I see the existence of both "children" and "parent" property as an invitation for inconsistency, just like @clausnagel in his 3rd point in https://github.com/tudelft3d/cityjson/issues/38 . Also it means that one needs to double check the links between children and parents to make sure all relationships are discovered.
Furthermore, if the "parent" property is needed, does it make sense to harmonize it with the CityObject's "parentS" property, which is an array? Even though it would be an array with a single element most (all) of the cases.