Document structure and content of the CityGML GML Encoding Standard

[TatjanaKutzner]

In the web meeting on 12 January we discussed the document structure.

• We will use the document structure provided by Chuck on github. This structure contains everything we need. Also, content is already provided for the Appearance Conformance Class, which can be used as a template for the other conformance classes.
• The Appearance Conformance Class contains a mapping table in section 6.2.2. which defines mappings between the UML classes and the corresponding XML schema elements. We decided to not provide these tables, since all UML classes are mapped 1:1 to XML schema elements and, thus, no additional value is given by these tables. We will only mention the few UML classes that have not been mapped to XML and refer to the XML schema file in the Appendix. In addition, we intend to provide an HTML documentation for the XML schemas, which is not normative.
• The Appearance Conformance Class contains the requirement "A conforming application shall support the CityGML XML elements listed in Table 4 in accordance with the GML XML schema specified in appearance.xsd". The text will be changed into "CityGML XML elements implemented by a conforming instance document shall conform to the GML XML schema in appearance.xsd" and will be used in this way also for the other Conformance Classes.
• Also, we do not think that the CityGML Data Dictionary from the Conceptual Model should be included in the Encoding Standard again and will remove it from the document structure.
• Chapter "6.1. Base Conformance Class" will be renamed to "Core Conformance Class".
• A new chapter "6.1. Global Requirements" will be added as first subchapter of chapter 6. This new chapter will contain all those general requirements that cannot be drawn from the XML schemas and that are valid for all Conformance Classes. This includes the rules for using CityObjectRelation and XLink and the rules for association classes defined here: https://github.com/opengeospatial/CityGML-3.0Encodings/tree/master/CityGML/Encoding%20Rules.

Homework tasks:

• Tatjana will fill the new chapter 6.1 and Annex C
• Tatjana will try out different XML editors for creating an HTML documentation (e.g. XMLSpy, Oxygen, Metanorma)
• Steve will write a chapter on code lists

[TatjanaKutzner]

Results and tasks from the web meeting on 2 February 2022:

• Metanorma is the preferred tool for creating an XML Schema documentation. Tatjana will ask OGC regarding an OGC template and some issues that occurred when creating the documentation with the Metanorma xs3p version.
• Tatjana will add tables with mappings between the UML classes and the corresponding XML schema elements for every module. The XML elements and UML class names will be linked to the XML Schema documentation and data dictionary entries.
• Claus will add to the Appearance conformance class important design decisions from CityGML 2.0 and on the compact geometries from GML 3.3.
• Claus will convert the Building examples from the CityGML 2.0 specification to CityGML 3.0 so that they can also be included in the CityGML 3.0 GML Encoding specification.
• Volker will provide XML examples for the new concepts in the Building module.
• Volker and Nobu will provide ADE examples for a chapter on ADEs. We will include one academic example and one real-world example (an excerpt from the Urban Planning ADE).
• Tatjana will add examples for Dynamizer and Versioning.
• Everybody will read the document and comment via github issues or pull requests.
• The CityGML SWG chairs plan to upload the document to the OGC portal within the 3 weeks rule for the next OGC meeting so that voting on the document by the CityGML SWG can take place soon and the standardisation process can proceed without delays.

[TatjanaKutzner]

Results and tasks from the web meeting on 24 February 2022:

• Claus converted the Building examples from the CityGML 2.0 specification to CityGML 3.0.
  -> They still need to be checked against the requirements of CityGML 3.0, such as, for example, correct use of XLinks.

• Volker and Abnet created Building Unit examples.
  -> Abnet will contact Tatjana for providing the examples on GitHub.

• Zhihang and Matthias have created a Test ADE including a UML model and an XSD schema.
  -> All group members will check the ADE.

• Nobu and Tatjana have mapped part of the Urban Planning ADE to CityGML 3.0 including a UML model and an XSD schema.
  -> Nobu will write a chapter on the ADE for the encoding specification.

• We need to define conformance requirements. We will define conformance requirements only for requirements that can be tested.
  Until the next meeting we go through the following modules and collect possible requirements (also by checking the requirements in the CityGML 2.0 specification to see what can be copied):
  -> Core: All
  -> Appearance: Claus
  -> Building, Construction: Steve + Volker (the CityGML QIE report which contains a list of conformance requirements for the CityGML 2.0 Building module will be used as basis)
  -> Dynamizer, Versioning: Diego + Tatjana
  -> Other modules: Anybody who has time is welcome to contribute

[TatjanaKutzner]

Summary of the web meeting on 16 March 2022:

The meeting focused on checking the progress of the tasks distributed in the previous meeting.
Progress has been made on all of the tasks mentioned above, but the tasks need between two to four more weeks of work.

In addition, we distributed further work:

• Diego will add descriptions for a second Versioning example and xAL 3 address examples to the Examples chapter
• Tatjana will review Chapter 3 References
• Steve will review Annex I.2 Abbreviated Terms
• Thomas will review Annex J Bibliography
• Tatjana will update the list of editors and submitting organisations
• Tatjana will define requirements for the OCL constraints and allowed boundary surfaces as specified in the Conceptual Model standard

[TatjanaKutzner]

Summary of the web meeting on 6 April 2022:

We checked the progress of the tasks distributed in the previous meetings.

• Finished are: ADE examples (Test ADE and Urban Planning ADE); Requirements for Appearance, OCL constraints and allowed thematic surface boundaries; Second Versioning example.
• The other tasks are still in progress, they will need more time.
• Peter will support us and check Chapter 3 References and Annex I.2 Abbreviated Terms

In Chapter 5 we will remove the sections on UML and XML notation and simply refer to the UML notation in the Conceptual Model standard and to the use of the encoding rules from ISO 19136 Annex E.

An XML Schema documentation in HTML format will be provided by OGC and Metanorma. This will, however, take a few months. In the meantime, so that we can continue with linking from the standard to the XML Schema documentation, a preliminary version of the documentation was provided to us here: https://opengeospatial.github.io/CityGML-3.0Encodings/xsd-doc/3.0/
Once the final schema documentation is available, the URLs will be replaced by OGC.

We discussed the use of EngineeringCRS:
It is possible to use multiple reference systems for the same object in different LODs in the same file, but software support is low. However, we do not recommend that, but will add an recommendation to the standard that all data in one file should be in one coordinate reference system.

Regarding issue #62 on CRS definition of ImplicitGeometry we discussed:
To support cases where the ImplicitGeometry is (after applying the transformation matrix and adding the reference point) in a different CRS than the rest of the file, a recommendation will be added that a specific CRS should be defined for the reference point of the ImplicitGeometry using the srsName attribute of the reference point.
In this way, also software will know that the CRS of the ImplicitGeometry differs from the rest of the file.

We discussed on the usefulness of the global requirement that CityGML instance documents shall use GML 3.2.1.
We concluded that it will be enough to say that the instance documents shall conform to the XML schemas. As the XML schemas are based on GML 3.2.1, this already implies that GML 3.2.1 must be used for the CityGML instance documents. Instance documents may then still use GML 3.3 in addition.

[TatjanaKutzner]

Summary of the web meeting on 27 April 2022:

We checked the progress on the individual tasks for the Encoding specification:

• Finished are: Chapter 3 References, Annex I.2 Abbreviated Terms, Chapter 5 UML + XML notation, Chapter B.2 Address Examples, linking of all XML element names in the mapping tables with the XML schema documentation, recommendation on the use of EngineeringCRS
• The other tasks are still in progress

We discussed again issue #62 on the CRS definition of ImplicitGeometry. Nobu will check whether the solution suggested in the meeting on 6 April 2022 works for him (see above). This solution would comply with CityGML 2.0.

Apart from that we discussed several formulations of our requirements and how they can be improved.
In particular, we also discussed the use of SHALL and MAY in requirements that consist of several statements. Statements with MAY cannot be considered testable requirements. We decided to include these statements as Notes in the requirements, as they provide useful information.

We also discussed BuildingUnit examples from Volker and concluded that Volker/Matthias will create a new and simpler example that will be provided in the github repository and described in the Examples Chapter.

[TatjanaKutzner]

Summary of the web meeting on 19 May 2022:

We checked the progress on the individual tasks for the GML Encoding standard:

• Finished are: BuildingUnit example, Requirements for Core module
• The other tasks are still in progress.

We agreed on the following roadmap for finalising the GML Encoding standard:

• June, 2nd, 2022 will be the final deadline for all open tasks. Everything which has not been finished until then will not be considered any more for the standard.
• After the final deadline, Claus and Tatjana will start to finalize the standard.

Steve defined several geometry requirements. Since these requirements are independent from the GML encoding, we decided to provide them for now in the CityGML 3.0 Conceptual Model Users Guide and reference them from the GML Encoding standard. A subgroup should be created to further test and discuss the requirements and after common agreement they should be moved to the Conceptual Model via a change request.

We also discussed again issue #62 on the CRS definition of ImplicitGeometry. We agreed now that the rule from CityGML 2 will also be provided in the GML Encoding specification.
Examples that were provided by Nobu need further discussion and afterwards should rather be provided in the Conceptual Model via a change request.