Rules for storing geometries for features with nested sub-features

[clausnagel]

In CityGML 2.0, the geometry of a feature like Building can be stored with the feature itself but also spread across various sub-features on different hierarchy levels. Moreover, sometimes the parent's geometry should redundantly contain the child's geometry, and sometimes not. For example, the SIG3D modelling guide for buildings recommends that dormers should be modelled as individual BuildingInstallation sub-features with their own geometry and that this geometry should also be part of the geometry of the parent building (see here). Balconies should also be modelled as BuildingInstallations, but in contrast to dormers their geometry should be excluded from the building geometry (see here).

Due to this, collecting the geometry of a feature can become be a tedious task. I would therefore like to start a discussion whether we should introduce more rules in CityGML 3.0 to make consuming the data more easy.

Here are my first thoughts:

1. Every "space feature" (i.e. a feature derived from AbstractSpace) shall contain its geometry inline. It shall never use an XLink to reference a geometry from one of its (transitive) sub-features.
2. The geometry of a space sub-feature shall not be redundantly contained in the geometry of its (transitive) parent space feature (thus, the "balcony example" from above would be the correct one).
3. A space sub-feature shall not use XLinks to reference geometries from its (transitive) parent feature.
   • The only exception from this rule is when the sub-feature and its direct parent feature share a common boundary where they touch. Then the sub-feature may reference this boundary geometry from its direct parent to make the shared boundary explicit (the orientation must be reversed in this reference).
   • Note: Another option would be to drop this "XLink topology" from CityGML 3.0. Then rule 3 would have no exception.
4. A "boundary feature" (i.e. a feature derived from AbstractThematicSurface) is meant to be used to semantically classify one or more surfaces (or curves) in the geometry of its direct parent space feature (e.g. as wall or roof surfaces). Consequently, it shall not contain its geometry inline, but shall only reference the geometries of its direct parent space feature using XLinks (thus, a gml:ReferenceType should be used in the GML encoding).
   • The only exception from this rule are AbstractFillingSurfaces. They are meant to fill a "hole" inside a surface of the parent space feature and to classify this filling, for instance, as door or window. Since there is no geometry that they could reference, they shall provide the filling geometry inline.

I know that especially rule 4 is exactly the opposite way as it is done in CityGML 2.0. But I think the above proposal is much more consistent and easier. A viewer, for example, would just have to iterate over every "space feature" and draw its geometry without having to fear that it misses geometries or that geometries are redundantly drawn (leading to a flickering effect). Also enabling or disabling a sub-feature in the viewer becomes much easier (because of rule 2). Other tools like geometry validators would also benefit for similar reasons.

[3DXScape]

I think this is a good analysis and the final paragraph is a good suggestion that would simplify life for developers of software consuming CityGML 3.0. I also agree with dropping "XLink topology" unless there is a problem that I do not see - which is very possible.

Note: this issue (among several) is really a mixture of CM and GML encoding concerns and the content should be distributed across both the CM and the GML encoding projects. For now this is OK because it is good simply to have the issues in front of us, especially since the GML encoding is essential to demonstrating the implement ability of the CM.

[clausnagel]

Also see this issue: #6

[hlg]

Re pt 4: In my understanding of the concepts of spaces and boundaries, "boundary features" (i.e. features derived from AbstractThematicSurface) do not unambiguously fit into a hierarchical structure of spaces. They are almost always boundaries between two spaces (either combination of occupied and unoccupied spaces) and as such it would seem random to prescribe one as the only possible parent feature. However, once the parent is fixed, and if links are only allowed inside of the same space feature, I do not see much of a difference in the direction of the link.

[clausnagel]

Thanks Helga. I agree that boundaries can also be shared by spaces that are not in the same hierarchy. Thus, it must be possible that a boundary feature references the geometry of another boundary feature outside its space hierarchy.

So pt 4 should be changed such that a boundary feature shall either reference the geometries of its direct parent space feature using XLinks or the shared geometry of an adjacent boundary feature ("XLink topology").

[clausnagel]

Note: the issue has been moved here from the CityGML 3.0 Conceputal Model repository because it addresses the encoding of the CityGML 3 Conceptual Model rather than the Conceptual Model itself.

[TatjanaKutzner]

In our web meeting on 28 January 2021 we discussed that it would be useful to store geometries with spaces only and reference the geometries from the space boundaries. To understand better whether this feasible in practice, Volker and Claus will provide suitable test data sets until the next meeting on 11 February 2021 and we will then continue the discussion.

[TatjanaKutzner]

The results from our web meeting on 11 February 2021:

Storing geometries

Storing geometries with the individual spaces only would be favourable, but is not realisable easily as backwards compatibility with existing CityGML 2 data sets needs to be ensured.

Taking the example of buildings with building installations like dormers, current software is creating city models in such a way that the solid geometry of the Building feature references the boudaries of the Building feature and of the BuildingInstallation features.
One possibility would be to separate the geometries such that the solid geometry of the Building feature only references the boudaries of the Building feature and the multi-surface geometry of the BuildingInstallation references the boudaries of the BuildingInstallation feature. This however would mean that the Building is not a solid any more, but has a whole that whould need to be covered by a ClosureSurface.

Introducing a strict rule that geometries can only be stored with their corresponding spaces would lead to problems for conversion tools that convert CityGML 2 to 3 files.

Thus, we can only propose such a rule for new city models created directly compliant to CityGML 3 that contains the following recommendations:

• Every space has it's own geometry (solid and/or multi surface). If the space has boundary surfaces, the actual geometries (i.e. polygon definitions) are stored with the boundary surfaces. If the space does not have boundary surfaces, then the actual geometry (i.e. polygon definitions) is stored with geometry of the space.
• The link direction is from the space geometry to the space boundaries.

Advantages:
-> Spaces can be visualised independently (e.g. only BuildingInstallation features without the Building features).
-> Data sets from IFC can easily be mapped to this new rule, since each object contains its own geometry in IFC.

As workaround for existing city models we propose:

• The geometry remains with the main space (e.g. Building), but it should be duplicated for the sub-spaces (e.g. BuildingInstallation). This allows for easier conversion of CityGML 2 to 3 and also independent visualisation of the spaces will become possible in this way.

We also discussed, whether it would be possible and useful to change the order of the <boundary> element and the geometry elements, such as <lod2MultiSurface> and <lod2Solid>, so that the geometry elements come first. The order would then be the same as in CityGML 2 and it might be easier to parse the files when the geometries come first.
-> This should be possible, it only requires changing the numbering within the tagged value sequenceNumber of the individual attributes and relations.

XLinks between shared geometries

When two buildings share a wall in CityGML 2, the polygon is stored with the WallSurface of one Building and is referenced from the WallSurface of the other Building using XLinks at the geometry level ("geometry link").
Such XLinks between the geometries of different top-level features are problematic. Thus, these kinds of XLinks should be avoided.

We propose the following:

• The polygon is copied to the WallSurface of the second Building, i.e. the wall is represented redundantly in both buildings.
• The WallSurface features of both buildings are linked using a semantic relationship which has been introduced newly to CityGML 3 as CityObjectRelation. Within this semantic relationship it can be expressed that the wall surfaces are the "same". This is an XLink at the feature level ("feature link"). "Geometry links" won't be allowed any more.
• The coordinates of the copied polygon are reorganised with the surface normal in positive direction.

Advantages:
-> For visualisation it would be enough to render only one of the two surfaces (if the viewer is capabable of doing so).
-> The features can be rendered independently without having to take care of geometry links that might not easily be resolvable.
-> Maintenance becomes easier. For instance, when one of the features changes and also the geometry of that feature changes, or when the feature does not exist any more, it's difficult to maintain/update XLinks between the feature geometries.

Next steps

-> Claus will put the discussed examples on github.
-> Volker will look for examples in LOD3.
-> Thomas will look for examples regarding feature links between roads and bridges.

[clausnagel]

I added some examples to the xlinks-discussion branch: https://github.com/opengeospatial/CityGML-3.0Encodings/tree/xlinks-discussion/CityGML/Examples/Building/XLink_examples

[TatjanaKutzner]

At the web meeting on 25 February 2021 we discussed the examples from Claus, see above, as well as examples on links between roads and bridges, roads and buildings, and between roads sharing an intersection that are available in the Transportation examples folder: https://github.com/opengeospatial/CityGML-3.0Encodings/tree/master/CityGML/Examples/Transportation/Basic%20examples

As next step TUM will prepare a first draft of rules for when to use CityObjectRelation and when to use XLinks to relate objects that are shared by different features. This draft will be discussed in the next meeting on 11 March 2021.

[TatjanaKutzner]

At the web meeting on 11 March 2021 we discussed a first draft of the rules. We will have a further round of internal refinement of the rules, before we provide them for public comment.

Further todos:
-> Claus and Tatjana will go through issues and check which of them can already be closed and which of them should be discussed next
-> Tatjana will go through UML model and provide a proposal for which associations should be set to 'inline' or to 'byReference' encoding

[deanhintz]

I've discussed this at length with our development team and the main concern raised was that however we decide to implement support for XLinks, we should only allow geometry XLinks to point to other geometries, not to features. Our understanding is that this is implicit in the GML spec, but it would be worth underlining this for the context of CityGML 3.

This does not preclude the use of Xlinks for links to other features outside of the geometry, such as discussed in feature to feature references as discussed above in Tatjana's comment from Feb 12. We also do not imply that we prefer the use of Xlinks to spread around geometry definitions, since in general it is most often easiest to resolve a geometry inline rather than via reference. That said, if we do need to use geometry Xlinks - they should be to other geometries and not to other features.

This comment also relates to issue#6 raised earlier by Claus on 'Restrict Xlinks for GML encoding'