Closed 3DXScape closed 3 years ago
Re C_3: ISO 19108 needs to be added to the ISO dependencies diagram.
Re C_7: The properties are not encoded in GML, because they are inherited from AbstractGML. However, they are provided in the UML model, so that they can be encoded in other data formats.
Re C_8: The "bounds" role was simply provided as conceptual information that space boundaries bound a space. The role is not listed in the feature catalog, since the association is unidirectional and, thus, it is not possible to navigate from AbstractSpaceBoundary to AbstractSpace. The role name could also be removed if it is confusing.
Re C_9: PointCloud and ImplicitGeometry are two different types of geometry. CityFurniture can be represented using ImplicitGeometry and/or PointClouds. An ImplicitGeometry, however, cannot be represented by a PointCloud.
Re C_12: The class WaterClosureSurface from CityGML 2.0 was removed from the UML model. To explicitly show that water bodies can still have closure surfaces, the class ClosureSurface was added to the UML model.
Re C_13: It should be added to the text that the dependency is not mandatory, it's only required, when Generics are used.
Re other points: We will add further figures, explanations and check the mentioned inconsistencies.
Re C_13: Elements defined in the /req/req-class-generics
package are used in the /req/req-class-construction
package. So we document that construction
is dependent on generics
. This dependency should also carry over to any Conceptual Model profile in order to maintain the consistency and integrity of the model. However, this may not be true for Implementation Specifications. The technical and operational constraints on an Implementation Specification (IS) may make generics
superfluous. In that case, I would not require that the IS explicitly support the generics
conformance class.
Should we include a discussion on how to use the CityGML Conceptual Model in the Users Guide?
Re C_5 - undefined: Yes, these should be defined. However the ISO neglected to do so. See issue #147
Re C_14 - Figure 12: The ISO classes were generated directly from the ISO TC211 Harmonized UML model. It appears that the definitions were copied from the source standards documents, including references to non-existent figures. These references have been removed from the text generated for this Standard.
Re C-14 - Target Class: These are UML associations. In UML an association has a source
class and a target
class. They also have a multiplicity
(number of instances) value for both the source and target. Since the CityGML Standard documents the normative UML model, we have chosen to use the UML terminology.
The following sub-issues have been implemented in the UML model:
C_3: ISO 19108 was added to dependencies diagram. C_8: The role "bounds" was removed. C_10 first point: The typo in ADEOfAuxiliaryTrafficArea was corrected. C_10 second point: TransportationSpaceClassValue, TransportationSpaceFunctionValue, and TransportationSpaceUsageValue were removed. C_14: There was an association from Building to GM_Surface which should not be there. It was removed.
The other sub-issues do not require updates to the UML model.
I checked the latest PDF, the changes to sub-issues C_10 first and second point and C_14 are not yet reflected in the PDF.
C_1: Current text is "This is especially important with respect to the cost-effective sustainable maintenance of 3D city models, allowing the reuse of the same data in different application fields."
C_6, C_10, and C_11 request additional figures. Do we have suitable figures to include?
Plan to add figures in next week.
C_2: The scope mentions now dynamics and point clouds.
C_3: ISO 8601 defines how to represent dates and times. Isn't that rather relevant for the encoding specifications?
Re C_4: Roads are identical to Rooms as described in Chapter 8.2.4. The Road is an UnoccupiedSpace, which means that the observer is located inside the UnoccupiedSpace. The surface normals of the thematic surfaces, i.e. TrafficArea and AuxiliaryTrafficArea, are pointing towards the observer, whereas the surface normals of the outer shell of the road volume are pointing in the opposite direction of the observer.
Have we found the needed figures for C_6, C_10, and C_11?
@TatjanaKutzner C_3 - ISO 8601 is listed in the normative references although it is never referenced in the text. Also, 8601 is not included in the UML model. So I'm at a loss on what to do with 8601 in this standard.
@cmheazel I suggest to remove ISO 8601 from the list of normative references, as it is not used anywhere. It seems rather relevant for encoding specifications. It was taken over from CityGML 2.0. ISO 8601 was included there as normative reference, but was also never referenced in the text or UML model.
@clausnagel Do you know what the purpose was of including ISO 8601 in the CityGML 2.0 specification document?
@clausnagel Do you know what the purpose was of including ISO 8601 in the CityGML 2.0 specification document?
Well, I cannot remember precisely why a normative reference to ISO 8601 was included. I assume because the CityGML 2.0 UML model uses date and time datatypes from XML schema such as xs:date
and xs:gYear
, and XML Schema entirely relies on a subset of ISO 8601 as the only supported format.
As a consequence, I agree that we can safely remove ISO 8601 from the normative references.
ISO 8601 is gone from the spec. Just waiting on figures.
Only open issue is inclusion of example figures. Those recommendations have been documented in issue #156 . This issue can now be closed.
The following 14 sub-issues relate to concepts in the 3.0 draft. In my opinion, they are substantive and require careful consideration by the editors and perhaps referral to the SWG for resolution.
Nobu_C_1:
Nobu_C_2: pp.10-11
Nobu_C_3:
Nobu_C_4: pp.32
Nobu_C_5:
Nobu_C_6: pp.46
Nobu_C_7:
Nobu_C_8: 8.2
Nobu_C_9: 8.9
Nobu_C_10: 8.11
Nobu_C_11: 8.13
Nobu_C_12: 8.14
Nobu_C_13: 8.15
Nobu_C_14: 9.1.8