[Requests] CityGML 1.1 public comments from 3D pilot NL

Linda van den Brink l.vandenbrink at geonovum.nl
Mon Sep 12 03:20:58 EDT 2011


CityGML 1.1 public comments

 

PART A

 

1. Evaluator: [CONTACT INFORMATION]

Linda van den Brink and Jantien Stoter on behalf of the 3D Pilot NL
group

Geonovum

Barchman Wuytierslaan 10

3818 LH Amersfoort

The Netherlands

 

2. Submission: [OpenGIS Project Document Number, Name]

OGC 08-007r2 - OpenGIS City Geography Markup Language (CityGML) Encoding
Standard

 

 

PART B

 

1. Requirement: [General, #] 

Use GML 3.2

2. Implementation Specification Section number: [General, #]

4.3

3. Criticality: [Major, Minor, Editorial, etc.]

Major

4. Comments/justifications for changes: [Comments]

In the Netherlands GML 3.2 is a national standard. It is also the basis
for the standard for large scale topography (IMGeo) which we have just
implemented as a CityGML extension. However, this means we are forced to
go back to GML 3.1.1, which is a deprecated version of the standard.

 

1. Requirement: [General, #] 

Further clarification is needed for the CityGML accuracy requirements.

2. Implementation Specification Section number: [General, #]

6.2

3. Criticality: [Major, Minor, Editorial, etc.]

Major

4. Comments/justifications for changes: [Comments]

For an implementation of CityGML further clarification is needed for the
CityGML accuracy requirements: are these rules or guidelines? Page 10 of
the CityGML standard states that "accuracy requirements in this standard
are debatable and should be considered as discussion proposals". Further
on the requirements are formulated as formal requirements ("The
positional and height accuracy of LOD2 must be 2m or better"...).  This
issue is also addressed in change request CR09-039.

 

1. Requirement: [General, #] 

Roof overhanging parts do have LOD0

2. Implementation Specification Section number: [General, #]

Table 3, 6.2

3. Criticality: [Major, Minor, Editorial, etc.]

Editorial

4. Comments/justifications for changes: [Comments]

The table states that Roof overhanging parts don't have LOD0 or LOD1
representations. But as of version 1.1 of CityGML, they do.

 

1. Requirement: [General, #] 

Clearer definitions of semantics

2. Implementation Specification Section number: [General, #]

10.x

3. Criticality: [Major, Minor, Editorial, etc.]

Major

4. Comments/justifications for changes: [Comments]

Using CityGML as implementation for a national standard requires clearer
definitions. The advantage of not having definitions for classes,
properties and code list values is that the model can be applied in
different contexts with greater flexibility. However lack of definitions
makes it difficult to understand what is meant by a concept in CityGML.
This issue confirms the CityGML change request CR09-039, 2010.

 

1. Requirement: [General, #] 

LOD0 representation for tunnels

2. Implementation Specification Section number: [General, #]

10.4

3. Criticality: [Major, Minor, Editorial, etc.]

Major

4. Comments/justifications for changes: [Comments]

LOD0 footprints for all CityGML classes are required in order to
integrate the full range of possible geometries of semantic objects in
one model, i.e. 2D, 2.5D and volumetric geometries. This enables to use
2D topographic data with a DTM and to upgrade 2D data to 3D. Essentially
the requirement is to do the same as was done for buildings in v1.1.
(See also CityGML 1.0 request ID 167.) 

 

1. Requirement: [General, #] 

LOD0 representation for Bridge, BridgePart and BridgeConstructionElement

2. Implementation Specification Section number: [General, #]

10.5

3. Criticality: [Major, Minor, Editorial, etc.]

Major

4. Comments/justifications for changes: [Comments]

LOD0 footprints for all CityGML classes are required in order to
integrate the full range of possible geometries of semantic objects in
one model, i.e. 2D, 2.5D and volumetric geometries. This enables to use
2D topographic data with a DTM and to upgrade 2D data to 3D. Essentially
the requirement is to do the same as was done for buildings in v1.1.
(See also CityGML 1.0 request ID 167.) 

 

1. Requirement: [General, #] 

LOD0 Surface representation for Waterbody

2. Implementation Specification Section number: [General, #]

10.6

3. Criticality: [Major, Minor, Editorial, etc.]

Major

4. Comments/justifications for changes: [Comments]

The requirement is to allow (Multi)Surface geometry for all water bodies
at LOD0. While the model permits this, the text of 10.6 allows this only
for large water surfaces and not for rivers, canals etc. 

LOD0 footprints for all CityGML classes are required in order to
integrate the full range of possible geometries of semantic objects in
one model, i.e. 2D, 2.5D and volumetric geometries. This enables to use
2D topographic data with a DTM and to upgrade 2D data to 3D. Essentially
the requirement is to do the same as was done for buildings in v1.1.
(See also CityGML 1.0 request ID 167.) 

 

1. Requirement: [General, #] 

LOD0 Surface representation for TrafficArea and AuxiliaryTrafficArea

2. Implementation Specification Section number: [General, #]

10.7

3. Criticality: [Major, Minor, Editorial, etc.]

Major

4. Comments/justifications for changes: [Comments]

LOD0 footprints for all CityGML classes are required in order to
integrate the full range of possible geometries of semantic objects in
one model, i.e. 2D, 2.5D and volumetric geometries. This enables to use
2D topographic data with a DTM and to upgrade 2D data to 3D. Essentially
the requirement is to do the same as was done for buildings in v1.1.
(See also CityGML 1.0 request ID 167.) 

 

1. Requirement: [General, #] 

LOD0 Surface representation for vegetation objects

2. Implementation Specification Section number: [General, #]

10.8

3. Criticality: [Major, Minor, Editorial, etc.]

Major

4. Comments/justifications for changes: [Comments]

LOD0 footprints for all CityGML classes are required in order to
integrate the full range of possible geometries of semantic objects in
one model, i.e. 2D, 2.5D and volumetric geometries. This enables to use
2D topographic data with a DTM and to upgrade 2D data to 3D. Essentially
the requirement is to do the same as was done for buildings in v1.1.
(See also CityGML 1.0 request ID 167.) 

 

1. Requirement: [General, #] 

LOD0 Surface representation for City furniture objects

2. Implementation Specification Section number: [General, #]

10.9

3. Criticality: [Major, Minor, Editorial, etc.]

Major

4. Comments/justifications for changes: [Comments]

LOD0 footprints for all CityGML classes are required in order to
integrate the full range of possible geometries of semantic objects in
one model, i.e. 2D, 2.5D and volumetric geometries. This enables to use
2D topographic data with a DTM and to upgrade 2D data to 3D. Essentially
the requirement is to do the same as was done for buildings in v1.1.
(See also CityGML 1.0 request ID 167.) 

 

1. Requirement: [General, #] 

Clearer guidelines for extending CityGML

2. Implementation Specification Section number: [General, #]

10.13

3. Criticality: [Major, Minor, Editorial, etc.]

Major

4. Comments/justifications for changes: [Comments]

The guidelines (or rules) for extending CityGML should be described more
fully and clearly so that a working extension of CityGML (i.e. working
in CityGML software) can be created by relying on these rules and/or
guidelines. 

 One of the results of the 3D pilot NL was the implementation of the
Dutch national standard for large scale topography as an extension of
CityGML. During the work it became clear that more detailed guidelines
for extending CityGML are needed for CityGML implementation profiles
that support a specific context. Currently it is not clear whether the
extension mechanisms of CityGML (generic objects and attributes and the
ADE mechanism) are guidelines or rules, nor is it clear when to use
which method for extension, although some guidelines are given. Also,
the ADE mechanism is only described in the context of GML application
schemas. How to use the method in UML modelling is not described. 

Consequently, when creating a CityGML extension, one cannot rely on the
description of the extension method to make sure the extension is
correct and software will support it.

 

 

 

Met vriendelijke groet,

 

Linda van den Brink

Geonovum

Adviseur standaardisatie geo-informatie

a:Barchman Wuytierslaan 10, 3818 LH Amersfoort 

p:Postbus 508, 3800 AM Amersfoort 

t:+ 31 (0)33 4604117

m:+ 31 (0)6 13555792 

e: l.vandenbrink at geonovum.nl <mailto:l.vandenbrink at geonovum.nl> 

i:www.geonovum.nl <http://www.geonovum.nl> 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/requests/attachments/20110912/5d1c6ba9/attachment-0001.htm>


More information about the Requests mailing list