The specification mentions GML 3.3 and GML 3.2.1

[TatjanaKutzner]

Page 10 mentions both, GML version 3.3 and version 3.2.1, as encodings. Only one version should be mentioned.

Originally, we said to use GML 3.3, because this version allows us to encode UML association classes. However, GML 3.3 did not allow us any more to represent code lists in the same way as we did in CityGML 2.0. For this reason, we decided in #10 to use the GML 3.2.1 encoding rule again in ShapeChange and to add the association class encoding as extra rule taken from GML 3.3 to the ShapeChange configuration file.

This would mean, that currently we use GML 3.2.1, right? This would also mean that #79 is not relevant any more, since the GML 3.3 compact encoding cannot occur in instance documents any more.

In addition, instead of refering to GML 3.2.1 we should refer to GML 3.2.2 as there has been a corrigendum some time ago regarding the gml:id attribute on LinearRing geometries.

[cmheazel]

Recommended resolution: delete text "version 3.3" on page 10 paragraph 2.
CityGML 3.0 is a conceptual model and is not tied to ANY encoding. You are free to use any version of GML (or any other type of encoding) you like.

[EmDevys]

For the conceptual model, the recommended resolution is fine. When the GML encoding is done, it will be necessary to adjust which GML is used (3.2.2 and/or GML 3.3). The choice is to be done on basis of analysis of constraints, as recommended by Tatjana. However I would like to point out that GML 3.3 offers a more efficient encoding in support of TIN terrain (in GML). Woudl there be a way to incorporate this in the GML encoding of CityGML 3? This is something of interest because as you know, TIN terrain in CityGML 2.0 is extremely heavy on large areas.

[TatjanaKutzner]

When discussing this issue with Thomas two days ago, we wanted to suggest to write in the text that the preliminary encoding of CityGML is based on GML 3.2.2, because in that way the GML encoding can still make use of the same code list representation as in CityGML 2.0 and that, in addition, to be able to encode association classes, an additional rule was taken over from GML 3.3.

But the proposed resolution not to mention GML at all in the conceptual model specification is probably even better.

[heidivanparys]

Perhaps GML should be mentioned in some accompanying text when the standard is sent out for public comment, as it is still relevant to know that a - proposed - GML encoding already exists, then reviewers can look at that too.

If a version is mentioned, the patch version number should be left out, so "GML 3.2" and not "GML 3.2.2". It is not very likely, but if a "minor bug" would be found with the GML standard and it would be fixed, then GML 3.3.3 would be released, using the same namespace http://www.opengis.net/gml/3.2 , and physically residing in the same location as the current GML 3.2.2, thus in folder http://schemas.opengis.net/gml/3.2.1/. As was done with the update from GML 3.2.1 to GML 3.2.2.

[3DXScape]

Do not mention GML in specification. Explain that GML implementation has been prototyped and is available in information that accompanies/introduces the specification.

[cmheazel]

Changes to section 2 (Scope). Removed version from the first reference to GML. Removed the patch number from the reference to the preliminary encoding. I cannot find any other references to GML except as a separate encoding standard for the Conceptual Model.

[3DXScape]

Agreed to close at 20 August 2020 SWG meeting.