CityGML 3 Draft Review by 石丸伸裕 : Conceptual Issues

[3DXScape]

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:

• [x] allowing the possibility of selling the same data to customers from different application fields -> [Is it possible to mention the merits not only for data providers but also for data users such as government?]

Nobu_C_2: pp.10-11

• [x] "Features of the CityGML v3.0 Conceptual Model:" How about mentioning the new concepts such as Dynamizer and Versioning? Or should include all new concepts such as PointCloud and Construction?

Nobu_C_3:

• [x] Should ISO 19108 be added since TM_Position is used?
• [x] Is ISO 8601 needed in this CM specification?

Nobu_C_4: pp.32

• [x] [Question: Though Roads are UnoccupiedSpaces, I understand that the surface normals should be directed towards the observer. Is it correct to apply the opposite direction to Roads?]

Nobu_C_5:

• [x] [Table 4] undefined -> [should be defined?]

Nobu_C_6: pp.46

• [ ] [Question: Are there any figures about the AbstractSpaceBoundary and AbstractLogicalSpace in this specification? Those figures will help readers to understand new concepts. Or is it possible to add an explanation of SpaceBoundary to Figure 16?]

Nobu_C_7:

• [x] I found several inconsistencies between Section 8 UML diagrams, Section 9 Data Dictionary, and schema files. For example, featuerID, identifies, name, and description in AbstractFeature are not defined in cityGMLBase.xsd. I understand that the schema files are not normative, so I have reviewed only UML diagrams and Data Dictionaries.

Nobu_C_8: 8.2

• [x] Figure 17, 19 Is the role "bounds" correct at the one direction association between AbstractSpace and AbstractSpaceBoundary? There is only "boundary" in AbstractSpaceType in pp.121, and no "bounds" in AbstractSpaceBoundaryType in pp.122.

Nobu_C_9: 8.9

• [x] pp.72 [Question] I would like to confirm how PointCloud can be used in CityFurniture. Does that mean as ImplicitGeometry?

Nobu_C_10: 8.11

• [ ] Since granularity is new concept and overall transportation concepts are relatively complicated, it may be better to add an example figure here. A simple figure such as Figure 6 or 15 may be enough.
• [x] pp.79 "ADEOfAuxiliaryTrafficAra" -> "ADEOfAuxiliaryTrafficArea"
• [x] pp.81-82 Are TransportationSpaceClassValue, TransportationSpaceFunctionValue, and TransportationSpaceUsageValue correct? I couldn't find them in Figure 28.

Nobu_C_11: 8.13

• [ ] Since Versioning is new concept, it may be better to add an example figure here. A simple figure such as Figure 6 or 15 may be enough.

Nobu_C_12: 8.14

• [x] In Figure 31, is ClosureSurface needed here?

Nobu_C_13: 8.15

• [x] Dependency: Is "/req/req-class-generics" mandatory?

Nobu_C_14: 9.1.8

• [x] Which Figure 12? It should be linked.
• [x] What is the meaning of "Target class and multiplicity"
• [x] why only "Building" is mentioned here?

[TatjanaKutzner]

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.

[cmheazel]

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?

[cmheazel]

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.

[TatjanaKutzner]

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.

[TatjanaKutzner]

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.

[cmheazel]

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."

[cmheazel]

C_6, C_10, and C_11 request additional figures. Do we have suitable figures to include?

[3DXScape]

Plan to add figures in next week.

[TatjanaKutzner]

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?

[TatjanaKutzner]

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.

[3DXScape]

Have we found the needed figures for C_6, C_10, and C_11?

[cmheazel]

@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.

[TatjanaKutzner]

@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]

@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.

[cmheazel]

ISO 8601 is gone from the spec. Just waiting on figures.

[cmheazel]

Only open issue is inclusion of example figures. Those recommendations have been documented in issue #156 . This issue can now be closed.