Remove "bounds" property from core:AbstractThematicSurfaceType

[clausnagel]

As agreed on in the modelling subgroup, core:AbstractThematicSurfaceType shall not contain a property element to core:AbstractSpaceType to avoid that a space is encoded as nested element of its thematic surface. In constrast, thematic surfaces shall be encoded as nested element of their space.

The bounds property of core:AbstractThematicSurfaceType must therefore be removed.

[clausnagel]

Note that this issue is related to opengeospatial/CityGML-3.0CM#85. It is not sufficient to just check the bounds property.

As described in opengeospatial/CityGML-3.0CM#85, the relationship between AbstractSpace and AbstractThematicSurface is restricted in many extension modules. For example, AbstractConstructionSpace should only be bounded by AbstractConstructionSurface and the bounds direction shall not be navigable.

The current encoding does not enforce this at all:

1. core:AbstractSpaceType has a boundary property element to core:AbstractThematicSurfacePropertyType. Since con:AbstractConstructionType is transitively derived from core:AbstractSpaceType, it inherits this property. Thus, the restriction to AbstractConstructionSurface from the UML diagram does not have any effect.

2. In addition to the inherited boundary property, con:AbstractConstructionType also defines a constructionSurface property which is then meant to implement the restricted boundary relationship to AbstractConstructionSurface. So, con:AbstractConstructionType even has two boundary relationships instead of a single restricted one.

3. Since con:AbstractConstructionSurfaceType is derived from core:AbstractThematicSurfaceType it also inherits the bounds property to any abstract space (see my first post). Again, this means that the intended restriction in the Construction module that a AbstractConstructionSurface should not contain its AbstractConstructionSpace is pointless.

This needs to be fixed.

[TatjanaKutzner]

At the web conference on 6 September 2019 and at the OGC meeting in Banff we discussed to replace the subsets of the bounds-boundary relation and use the original bounds-boundary relation in the thematic modules to illustrate the relationship. In this way, no additional relationships are derived in the GML application schemas.
In addition, we discussed to make the bounds-boundary relation in the Core module uni-directional.

I implemented it now in this way.
However, I saw that core:AbstractThematicSurfaceType still contains the bounds property, altough in the UML model the relation is now uni-directional, with AbstractThematicSurface being the target class of the relation. Thus, the property should not be there in the encoding. This might be a bug in ShapeChange.

[TatjanaKutzner]

Has been solved, see also opengeospatial/CityGML-3.0CM#117.