search

opengeospatial / CityGML-3.0CM

CityGML 3.0 Conceptional Model
MIT License
86 stars 15 forks source link

CityObjectRelation vs. GenericCityObjectRelation #80

Closed clausnagel closed 4 years ago

clausnagel commented 5 years ago

What is the rationale behind having a GenericCityObjectRelation (Generics module) in addition to the CityObjectRelation (Core module)? Is it just to be able to assign generic attributes? If so, then why isn't that simply modelled for CityObjectRelation? I do not see the need for having both of them.

thomashkolbe commented 4 years ago

The support of generic attributes should only be possible when a software implements the Generics module. Hence, in order to formally express this, the data type GenericCityObjectRelation extends CityObjectRelation within the Generics module.

The data type CityObjectRelation is defined in the Core module, because we want to show that now all CityObjects in principle can be augmented by relations to other CityObjects (similar to the IFCRELATION concept in IFC). Since some thematic modules may even define more specific relationships, they should use CityObjectRelation as the supertype of their more specific relation types.

thomashkolbe commented 4 years ago

One addition: one of the predefined kind of relationships that makes sense for all CityObjects is the set of topological relations (as shown in the current UML model). It is important to note, that this relationship refers to the semantics of the real world objects, not necessarily to their geometric representations. For example, if a building is in the real world directly adjacent to a pedwalk, then an explicit touch relation between the pedwalk and the building feature can be expressed. This relationship might not be reflected on the given geometry representations, though, e.g. when the pedwalk is represented by a center line and the building by a solid. Such topological relationship given on the semantic level of the real world objects could be used to verify, if also the geometries in the different LODs are consistent with it. On the other side, if the topological relationship of the geometries is explicitly represented or known, one can also derive this semantic level relationship between the city objects.

The nice thing is here, that we abstract from the multiple LODs and their many different combinations of two objects. Users in the end do not want to know, if a polygon of a ground surface in LOD2 touches the boundary of a polygon from a traffic surface in LOD2 (or 3?), but they simply want to query for all the buildings that are adjacent to a specific road. And this can be realized by this modeling.

clausnagel commented 4 years ago

In today's modelling subgroup meeting there was consensus that we should use the newly introduced abstract class AbstractGenericAttribute to avoid a dependency between the Generics and the Core module.

Thus, we should add a new association from CityObjectRelation to AbstractGenericAttribute - just like it is modelled for AbstractCityObject. This way, generic attributes can optionally be added to any CityObjectRelation object. But software can still choose not to implement the Generics module at all.

With this solution, GenericCityObjectRelation is obsolete and can be removed.

TatjanaKutzner commented 4 years ago

We discussed in the subgroup meeting on 21 October 2019 to already close this issue.