Closed dstenger closed 3 weeks ago
@jiann
Abstract Test 3
Still not sure about the expressions: "//:spaceType" and "//:SpaceBoundary".
The spec states:
...
NOTE Spaces are represented in the CityGML 3.0 Conceptual Model by those classes that are derived from the class AbstractSpace.
...
NOTE Space boundaries are represented in the CityGML 3.0 Conceptual Model by those classes that are derived from the class AbstractSpaceBoundary.
...
@jiann Abstract test 3 looks much better, now. However, I do not see that this is tested: "If the geometry is stored with the space in addition, it references the geometry from the space boundary using XLinks." Can you please check this? If an implementation is too complex, I am also fine simplifying the test.
@jiann Can you please review, test and merge the pull request (https://github.com/opengeospatial/ets-citygml30-part2/pull/44) created by @bpross-52n?
Abstract Test 3:
Spec states: "Geometries stored inline a space boundary are not redundantly stored as geometry of a space. If the geometry is stored with the space in addition, it references the geometry from the space boundary using XLinks."
The expressions "//:spaceType" and "//:SpaceBoundary" seem to be incorrect. Please see definitions of
Abstract Test 4:
Spec states: "Verify that LoDs are self-contained: Geometries are not shared between different LoDs using XLinks."
The code checks whether a single LoD element has two or more XLinks and fails if that is true. The spec, however, describes that geometries shall not be shared between different LoDs.
Abstract Test 5
Spec states: "If two top-level features share a common geometry, the shared geometry is stored for each top-level feature separately."
This bullet point seems not to be tested by the implementation.