[Requests] Comments on City Geography Markup Language (CityGML)

Dear OGC,
Please find enclosed comments on "OGC 08-007, OpenGIS City Geography Markup
Language (CityGML)" by the members of the Special Interest Group 3D (SIG
3D).
Best regards,
Claus Nagel,
Gerhard Groeger,
Haik Lorenz,
Thomas H. Kolbe
PART A
1. Evaluators:
Claus Nagel,
Institute for Geodesy and Geoinformation Science,
Berlin Institute of Technology, Germany
nagel at igg.tu-berlin.de
Gerhard Groeger,
Institute for Geodesy and Geoinformation,
University of Bonn, Germany
groeger at ikg.uni-bonn.de
Haik Lorenz,
Hasso-Plattner-Institute for IT Systems Engineering,
University of Potsdam, Germany
haik.lorenz at hpi.uni-potsdam.de
and Thomas H. Kolbe,
Institute for Geodesy and Geoinformation Science,
IGG, Berlin Institute of Technology, Germany
kolbe at igg.tu-berlin.de
on behalf of the members of the Special Interest Group 3D (SIG 3D) of the
initiative Geodata Infrastructure North-Rhine Westphalia (GDI NRW),
Germany
2. Submission:
OGC 08-007,
OpenGIS City Geography Markup Language (CityGML) Implementation
Specification
PART B
1.1 Requirement:
Generic attributes should be extracted from the CityGML core module and,
instead, be defined within the same extension module as generic city
objects. Consequently, this extension module should be renamed from
"GenericCityObject" to "Generics".
1.2 Implementation Specification Section number: 6.11, 10.1, 10.10 and
related clauses
1.3 Criticality: Normal
1.4 Comments/justifications for changes:
Generic attributes and generic city objects provide a uniform and consistent
way for modelling and exchanging application data that is not covered by the
overall CityGML data model. Due to this strong semantic relation, both
should be embraced by a single thematic extension module. By this means,
implementations can choose whether to support generics as a whole.
However, the current specification separates generic attributes and objects
into two modules: the core and the "GenericCityObject" module. Since generic
attributes are part of the core, they have to be supported by each
conformant system. In contrast, generic city objects may only be employed if
the corresponding extension module is supported. Thus, the concept of
generics is fragmented.
The definition of generic attributes and generic city objects within a
single extension module "Generics" places emphasis on their semantic
relation and eases implementations. Furthermore, the content of the core is
reduced. Generic attributes should be injected into the abstract base class
_CityObject of the core using CityGML's ADE mechanism.
2.1 Requirement:
Clarify the usage of xlinks for feature property types.
2.2 Implementation Specification Section number: General
2.3 Criticality: Normal
2.4 Comments/justifications for changes:
Some feature property types (associations to features) are not allowed to
refer to a feature by an xlink, but have to contain that feature inline. The
reason is that the referenced feature has to have an unique parent.
However, this constraint is currently not assured by the schema (and even
not stated in the document), since the gml:AssociationAttributeGroup
enabling xlinks is inherited from gml:AssociationType, which is the base of
the feature property types.
On the other hand, this xlink constraint also results in a lack of
flexibility. Therefore, the usage of xlinks could also be generally allowed
for all feature property types.
A discussion on the usage of xlinks for feature property types within the
SWG is suggested. If the xlink constraint is kept, the affected feature
property types should be explicitly enumerated within the specification
document (e.g. by corresponding conformance requirements).
3.1 Requirement:
Clarify the representation of texture coordinates within the Appearance
module.
3.2 Implementation Specification Section number: 9
3.3 Criticality: Normal
3.4 Comments/justifications for changes:
The Appearance module provides the means to texture a surface object using
texture coordinates. Texture coordinates define the mapping of the surface's
boundary points to corresponding points in texture space. As for the current
Appearance module, each boundary point of the surface must receive a
corresponding coordinate pair in texture space. Since the boundary of a
surface is described by gml:LinearRings, each gml:LinearRing (may it be
exterior or interior) composing the boundary of the target surface object
requires its own set of texture coordinates.
For this purpose, the Appearance module defines the class TexCoordList. A
TexCoordList object must contain as many <textureCoordinate> elements as the
target surface object contains (exterior and interior) gml:LinearRings. A
<textureCoordinate> element references the gml:id of the respective
gml:LinearRing.
However, this way to provide texture coordinates for surface objects is
impractical with respect to spatial data types of current geodatabase
systems. Usually, a single linear ring is not addressable within a spatial
data type representing a surface geometry, nor may it be assigned additional
attributes like a gml:id. Thus, the relation between linear rings and
texture coordinates is quite complex to express on the database level.
A discussion on the representation of texture coordinates within the SWG is
suggested.
4.1 Requirement:
Add a conformance requirement on referential integrity for the element
"cityObjectMember" to the CityGML core module.
4.2 Implementation Specification Section number: 10.1.7
4.3 Criticality: Major
4.4 Comments/justifications for changes:
The element "cityObjectMember" shall only contain or reference elements of
type _CityObject. This has to be ensured by a corresponding conformance
requirement, otherwise semantic interoperability is affected.
5.1 Requirement:
Add a conformance requirement on the allowed content of the element
"CityModel" to the CityGML core module.
5.2 Implementation Specification Section number: 10.1.7
5.3 Criticality: Major
5.4 Comments/justifications for changes:
The element "CityModel" may only contain "cityObjectMember",
"appearanceMember", and "featureMember" elements. This has to be ensured by
a corresponding conformance requirement, otherwise semantic interoperability
is affected.
6.1 Requirement:
Add an additional base conformance requirement to the Appearance module.
6.2 Implementation Specification Section number: 9.6
6.3 Criticality: Major
6.4 Comments/justifications for changes:
A surface geometry object may be the target of at most two textures and two
materials (one for front and back respectively) per theme. This has to be
enforced by a corresponding conformance requirement, otherwise semantic
interoperability is affected.
7.1 Requirement:
Add a conformance requirement on the allowed content of the element
"lod0Network" to the Transportation module.
7.2 Implementation Specification Section number: 10.5
7.3 Criticality: Major
7.4 Comments/justifications for changes:
The element "lod0Network" of "TransportationComplexType" is of type
"gml:GeometricComplexPropertyType". However, for LOD0 the geometry of a
TransportationComplex may only be modelled using straight line objects.
Therefore, only gml:CompositeCurve is allowed for
"gml:GeometricComplexPropertyType". This has to be ensured by a
corresponding conformance requirement, otherwise semantic interoperability
is affected.
8.1 Requirement:
Fig. 13 and chapter 9.3 need to be harmonized.
8.2 Implementation Specification Section number: Fig. 13, chapter 9.3
8.3 Criticality: Editorial
8.4 Comments/justifications for changes:
In chapter 9.3, the element "surfaceDataMember" of class Appearance is
referenced. Fig. 13 lists this element as "surfaceData".
9.1 Requirement:
Add an example to Annex F demonstrating texturing of a complex surface. The
example should include polygons with holes and compound surfaces.
9.2 Implementation Specification Section number: Annex F
9.3 Criticality: Editorial
9.4 Comments/justifications for changes:
Texturing polygons with holes seems complicated. An example could help.