[Requests] CityGML 1.1 Candidate Specification - Comments

Kita, Daniel G (Danny) daniel.kita at intergraph.com
Tue Sep 6 15:38:41 EDT 2011


Danny Kita
Product Manager
P.O. Box 6695
Huntsville, AL 358
Email: daniel.kita at intergraph.com<mailto:daniel.kita at intergraph.com>

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


1. Requirement: [General, #]
Test Cases for Mandatory Conformance Requirements, Annex B

2. Implementation Specification Section number: [General, #]
Section B.1.4 Spatial Geometry Objects, page 206

3. Criticality: [Major, Minor, Editorial, etc.]
We consider this to be a major criticality.
Without the ability to geo reference CityGML objects, useful exchange of CityGML files with third parties is problematic.

4. Comments/justifications for changes: [Comments]

Intergraph's Comments on CityGML 1.1

We would like to make the following proposals:

1)    It is proposed that specifying the Coordinate Reference System be mandatory for CityGML files that are to be exchanged externally with third parties.

2)    It is proposed that providing world coordinates or the necessary information to extract world coordinates be mandatory for CityGML files that are to be exchanged externally with third parties.

Supporting arguments:

a)    Given the following excerpt from the CityGML 1.1 specification (section 1 Scope, page1 ) stating that CityGML is to be used for exchange and that it includes georeferenced data, we believe the current specification to be to problematic unless Coordinate Reference System (CRS) information is specified within the CityGML file.
This document is an OpenGIS(r) Encoding Standard for the representation, storage and exchange of virtual 3D city and landscape models. CityGML is implemented as an application schema of the Geography Markup Language version 3.1.1 (GML3).

CityGML models both complex and georeferenced 3D vector data along with the semantics associated with the data. In contrast to other 3D vector formats, CityGML is based on a rich, general purpose information model in addition to geometry and appearance information. For specific domain areas, CityGML also provides an extension mechanism to enrich the data with identifiable features under preservation of semantic interoperability.
==================================end excerpt=================================

b)    Supporting evidence:
CityGML examples F1, F2, F3, F4, F5,  and F6 utilized in the CityGML 1.1 candidate specification (Annex F pages 253-277) include the Coordinate Reference System information and world coordinates. The examples imply that a CityGML file should include an EPSG code and coordinates in the source reference system.

For example:
<gml:name>Simple 3D city model LOD0 without Appearance</gml:name>
<gml:Envelope srsDimension="3" srsName="urn:ogc:def:crs:EPSG:25832, crs:EPSG:5783">
<gml:lowerCorner srsDimension="3">458868.0 5438343.0 112.0 </gml:lowerCorner>
<gml:upperCorner srsDimension="3">458892.0 5438362.0 117.0 </gml:upperCorner>

c)    The attributes used in the CityGML 1.1 examples (srsName and srsDimension) to provide the coordinate reference system and coordinate information are not specifically called out in the CityGML specification. They are part of the GML specification but do not appear to be mandatory. Therefore, they would not be mandatory for CityGML. Without knowing the coordinate reference system and the world coordinates of CityGML objects, the objects are not georeferenceable and, therefore,  cannot be properly placed in their position on the earth nor can they be usefully exchanged.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/requests/attachments/20110906/21acc6ad/attachment.htm>

More information about the Requests mailing list