Open Geospatial Consortium |
Submission Date: 2023-01-25 |
Approval Date: 2023-05-10 |
Publication Date: 2023-06-20 |
External identifier of this OGC® document: http://www.opengis.net/doc/IS/CityGML-2/3.0 |
Internal reference number of this OGC® document: 21-006r2 |
Version: 3.0 |
Category: OGC® Implementation Standard |
Editors: Tatjana Kutzner, Carl Stephen Smyth, Claus Nagel, Volker Coors, Diego Vinasco-Alvarez, Nobuhiro Ishimaru, Zhihang Yao, Charles Heazel, Thomas H. Kolbe |
OGC City Geography Markup Language (CityGML) Part 2: GML Encoding Standard |
Copyright notice |
Copyright © 2023 Open Geospatial Consortium |
To obtain additional rights of use, visit http://www.opengeospatial.org/legal/ |
Warning |
This document is an OGC Member approved international standard. This document is available on a royalty free, non-discriminatory basis. Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.
Document type: OGC® Standard |
Document subtype: Encoding |
Document stage: Approved |
Document language: English |
License Agreement
Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.
If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.
THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD.
THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.
This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.
Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.
- 1. Scope
- 2. Conformance
- 3. References
- 4. Terms and Definitions
- 4.1. 2D data
- 4.2. 2.5D data
- 4.3. 3D data
- 4.4. application schema
- 4.5. city-object relation
- 4.6. codelist
- 4.7. conceptual model
- 4.8. conceptual schema
- 4.9. feature
- 4.10. geometry
- 4.11. Implementation Specification
- 4.12. levels of detail
- 4.13. life-cycle information
- 4.14. Platform (Model Driven Architecture)
- 4.15. Platform Independent Model
- 4.16. Platform Specific Model
- 4.17. space
- 4.18. space boundary
- 4.19. top-level feature
- 4.1. 2D data
- 5. Conventions
- 6. Requirements
- 7. Media Types
- Annex A: Conformance Class Abstract Test Suite (Normative)
- A.1. Conformance Class Global
- A.2. Conformance Class Core
- A.3. Conformance Class Appearance
- A.4. Conformance Class Bridge
- A.5. Conformance Class Building
- A.6. Conformance Class CityFurniture
- A.7. Conformance Class CityObjectGroup
- A.8. Conformance Class Construction
- A.9. Conformance Class Dynamizer
- A.10. Conformance Class Generics
- A.11. Conformance Class LandUse
- A.12. Conformance Class PointCloud
- A.13. Conformance Class Relief
- A.14. Conformance Class Transportation
- A.15. Conformance Class Tunnel
- A.16. Conformance Class Vegetation
- A.17. Conformance Class Versioning
- A.18. Conformance Class WaterBody
- Annex B: Examples (Informative)
- Annex C: XML Schema (Normative)
- Annex D: CityGML 3.0 Conceptual Model Conformance (Normative)
- Annex E: Codelists (Informative)
- Annex F: Use of GML 3.3 (Informative)
- Annex G: Implementation Decisions (Informative)
- Annex H: Revision History
- Annex I: Glossary
- Annex J: Bibliography
i. Abstract
The CityGML 3.0 Part 2: GML Encoding Standard presents the implementation-dependent GML encoding of the concepts defined by the CityGML 3.0 Part 1: Conceptual Model (CM) Standard (OGC 20-010). The GML Encoding is compliant to GML versions 3.2 and 3.3, which is specified by ISO 19136. This encoding can be used to store and exchange 3D city models in the GML format as data sets or via web services. The concepts include the most relevant topographic objects in cities and regional models with respect to their geometrical, topological, semantical, and appearance properties. “City” is broadly defined to comprise not just built structures, but also elevation, vegetation, water bodies, city furniture, and more. Included are generalization hierarchies between thematic classes, aggregations, relations between objects, and spatial properties.
This Part 2 of the Standard defines how the concepts developed in Part 1 are realized using XML and GML technologies. The GML Encoding represents a full mapping of the Conceptual Model and is derived fully automatically from the UML model following the UML-to-GML encoding rules as defined by ISO 19136. Table 1 maps requirements classes from the CityGML 3.0 Conceptual Model into the implementation details documented in this standard.
Conceptual Model | Section | GML Schema |
---|---|---|
Appearance |
||
Bridge |
||
Building |
||
CityFurniture |
||
CityObjectGroup |
||
Construction |
||
Core |
||
Dynamizer |
||
Generics |
||
LandUse |
||
PointCloud |
||
Relief |
||
Transportation |
||
Tunnel |
||
Vegetation |
||
Versioning |
||
WaterBody |
ii. Keywords
The following are keywords to be used by search engines and document catalogues.
ogcdoc, OGC document, CityGML, 3D city models, GML, XML
iii. Preface
In order to achieve consensus on the basic entities, attributes, and relations of a 3D city model, a UML Conceptual Model, CityGML 3.0 Part 1, was approved as an OGC standard (OGC 20-010) in March, 2021. This model provides a unifying conceptual basis for city model encoding standards. This CityGML 3.0 Part 2: GML Encoding Standard defines how those concepts should be realized using XML and GML technologies.
CityGML 3.0 applies the Model-Driven Architecture approach. The CityGML 3.0 Conceptual Model was defined as a Platform Independent Model (PIM). From this PIM, various platform-specific implementations can be derived. This standard defines the platform-specific implementation for the GML standards version 3.2 and 3.3 which are based on XML. The GML schemas have been derived fully automatically from the UML Conceptual Model using the software tool ShapeChange.
The CityGML 3.0 Part 1: Conceptual Model standard is available under https://docs.ogc.org/is/20-010/20-010.html. An additional Users Guide providing extended explanations and examples for the individual concepts defined in the CityGML 3.0 Part 1: Conceptual Model Standard is available under https://docs.ogc.org/guides/20-066.html.
As an OGC standard, CityGML follows the OGC Modular Specification , OGC 08-131r3. It includes requirements that can checked in a formalized way to verify the correctness of a CityGML implementation. Because of the breadth of CityGML, its conceptual model was divided into separate Requirements Classes, one for each subject area such as Building, Tunnel, Transportation, Vegetation, and City Furniture. This CityGML encoding similarly is divided into Requirements Classes which are then grouped into Parts. A Part may address multiple CityGML Requirements Classes but each Requirements Class is addressed in a single part. Because Requirements Classes may depend on other Requirements Classes the reader of this CityGML Part may need to conform to Requirements Classes in other Parts as well.
Note that this GML Encoding Standard is a standardization target of the CityGML 3.0 Part 1: Conceptual Model Standard. Therefore, this standard conforms to the Conformance Classes in that standard. Evidence of that conformance is provided in Appendix D. On the other hand, an application claiming conformance to this CityGML Encoding Standard must conform to the Requirements Classes contained in this standard.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.
iv. Submitting organizations
The following organizations submitted this document to the Open Geospatial Consortium (OGC):
-
Heazeltech LLC
-
HFT Stuttgart
-
OpenSitePlan
-
Ordnance Survey
-
Technical University of Munich
-
Virtual City Systems
v. Submitters
All questions regarding this submission should be directed to the editors or the submitters:
Name | Affiliation |
---|---|
Volker Coors |
HFT Stuttgart, Germany |
Charles Heazel |
Heazeltech LLC, USA |
Thomas H. Kolbe |
Chair of Geoinformatics, Technical University of Munich, Germany |
Tatjana Kutzner |
Chair of Geoinformatics, Technical University of Munich, Germany |
Claus Nagel |
Virtual City Systems, Germany |
Carl Stephen Smyth |
OpenSitePlan, USA |
vi. Participants in development
In addition to the Editors of the specification the following individuals contributed to this document:
Name | Institution |
---|---|
Christof Beil |
Chair of Geoinformatics, Technical University of Munich, Germany |
Kanishk Chaturvedi |
Chair of Geoinformatics, Technical University of Munich, Germany |
Dean Hintz |
Safe Software, Canada |
Peter Parslow |
Ordnance Survey, Great Britain |
1. Scope
This Standard documents the OGC GML Implementation Specification (IS) for the CityGML 3.0 Conceptual Model. The CityGML 3.0 conceptual model is a Platform Independent Model (PIM). It defines concepts in a manner which is independent of any implementing technology. As such, the CityGML Conceptual Model cannot be implemented directly. Rather, it serves as the base for Platform Specific Models (PSM). A PSM adds to the PIM the technology-specific details needed to fully define the CityGML model for use with a specific technology. The PSM can then be used to generate the schema and other artifacts needed to build CityGML 3.0 implementations.
This standard defines the PSMs and schemas for the CityGML 3.0 Implementation Specification (IS) for Geography Markup Language (GML) implementations. The GML schemas are explained in an overview and design decisions that have been made are documented as well.
2. Conformance
This standard defines an Implementation Specification which specifies how the CityGML 3.0 Conceptual Model should be implemented using Geography Markup Language (GML). The Standardization Target for this standard is:
-
Implementations of the CityGML 3.0 Conceptual Model using GML encodings.
2.1. Implementation Specifications
Implementation Specifications define how a Conceptual Model should be implemented using a specific technology. Conformant Implementation Specifications provide evidence that they are an accurate representation of the Conceptual Model. This evidence includes data demonstrating that the applicable criteria documented in the CityGML 3.0 CM Abstract Test Suite have been satisfied. That evidence is provided in Appendix D.
2.2. Conformance Classes
This standard identifies seventeen (17) conformance classes. One conformance class is defined for each GML schema. Each conformance class is defined by one requirements class. The tests in Annex A are organized by requirements class. So an implementation of the Core conformance class must pass all tests specified in Annex A for the Core requirements class.
Of these seventeen conformance classes, only the Core conformance class is mandatory. All other conformance classes are optional. In the case where a conformance class has a dependency on another conformance class, that conformance class should also be implemented.
3. References
The following normative documents contain provisions that, through reference in this text, constitute provisions of OGC. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. However, users are encouraged to investigate the possibility of applying the most recent editions of the normative documents indicated below. For undated references, the latest edition of the normative document referred to applies.
-
IETF: RFC 2045 & 2046, Multipurpose Internet Mail Extensions (MIME). (November 1996),
-
IETF: RFC 3986, Uniform Resource Identifier (URI): Generic Syntax. (January 2005)
-
ISO: ISO 19109:2015, Geographic Information – Rules for Application Schemas
-
ISO: ISO 19111:2019, Geographic information – Referencing by coordinates
-
Khronos Group Inc.: COLLADA – Digital Asset Schema Release 1.5.0
-
OASIS: Customer Information Quality Specifications - extensible Address Language (xAL), Version v3.0
-
OGC: The OpenGIS® Abstract Specification Topic 5: Features, OGC document 08-126
-
OGC: The OpenGIS™ Abstract Specification Topic 8: Relationships Between Features, OGC document 99-108r2
-
OGC: The OpenGIS™ Abstract Specification Topic 10: Feature Collections, OGC document 99-110
-
OGC: OGC 20-010, OGC City Geography Markup Language (CityGML) Part 1: Conceptual Model Standard, v3.0, 2021.
-
OGC: OGC 07-036r1, OpenGIS® Geography Markup Language (GML) Encoding Standard, v3.2.2, 2007.
4. Terms and Definitions
This document uses the terms defined in Sub-clause 5.3 of [OGC 06-121r8], which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this Standard.
For the purposes of this document, the following additional terms and definitions apply.
4.1. 2D data
geometry of features is represented in a two-dimensional space
NOTE In other words, the geometry of 2D data is given using (X,Y) coordinates.
[INSPIRE D2.8.III.2, definition 1]
4.2. 2.5D data
geometry of features is represented in a three-dimensional space with the constraint that, for each (X,Y) position, there is only one Z
[INSPIRE D2.8.III.2, definition 2]
4.3. 3D data
Geometry of features is represented in a three-dimensional space.
NOTE In other words, the geometry of 2D data is given using (X,Y,Z) coordinates without any constraints.
[INSPIRE D2.8.III.2, definition 3]
4.4. application schema
A set of conceptual schema for data required by one or more applications. An application schema contains selected parts of the base schemas presented in the ORM Information Viewpoint. Designers of application schemas may extend or restrict the types defined in the base schemas to define appropriate types for an application domain. Application schemas are information models for a specific information community.
OGC Definitions Register at http://www.opengis.net/def/glossary/term/ApplicationSchema
4.5. city-object relation
a specific relation from the city object in which the relation is included to another city object
[CityGML Conceptual Model]
4.7. conceptual model
model that defines concepts of a universe of discourse
[ISO 19101-1:2014, 4.1.5]
4.8. conceptual schema
-
formal description of a conceptual model
[ISO 19101-1:2014, 4.1.6] -
base schema. Formal description of the model of any geospatial information. Application schemas are built from conceptual schemas.
OGC Definitions Register at http://www.opengis.net/def/glossary/term/ConceptualSchema
4.9. feature
abstraction of real world phenomena
NOTE Features are objects that have an identity that allows for distinguishing features from each other. Features can have spatial and non-spatial properties that describe the features in more detail. Spatial properties are properties that have a geometry from ISO 19107 as data type.
NOTE Features are denoted by the stereotype «FeatureType» in the CityGML 3.0 Conceptual Model.
[ISO 19101‑1:2014, 4.1.11]
4.10. geometry
an ordered set of n-dimensional points in a given coordinate reference system; can be used to model the spatial extent or shape of a feature
NOTE Geometries are objects that can have an identity that allows for distinguishing geometries from each other. Geometries define the data types of spatial properties of features.
[OGC 15-107, modified]
4.11. Implementation Specification
Specified on the OGC Document Types Register at http://www.opengis.net/def/doc-type/is
4.12. levels of detail
quantity of information that portrays the real world
NOTE The concept comprises data capturing rules of spatial object types, the accuracy and the types of geometries, and other aspects of a data specification. In particular, it is related to the notions of scale and resolution.
[INSPIRE Glossary]
4.13. life-cycle information
set of properties of a spatial object that describe the temporal characteristics of a version of a spatial object or the changes between versions
[INSPIRE Glossary]
4.14. Platform (Model Driven Architecture)
the set of resources on which a system is realized.
[Object Management Group, Model Driven Architecture Guide rev. 2.0]
4.15. Platform Independent Model
a model that is independent of a specific platform
[Object Management Group, Model Driven Architecture Guide rev. 2.0]
4.16. Platform Specific Model
a model of a system that is defined in terms of a specific platform
[Object Management Group, Model Driven Architecture Guide rev. 2.0]
4.17. space
an entity of volumetric extent in the real world
NOTE Spaces can be spatially represented in different LODs and by different types of geometric objects.
NOTE Spaces are represented in the CityGML 3.0 Conceptual Model by those classes that are derived from the class AbstractSpace.
[CityGML Conceptual Model]
4.18. space boundary
an entity with areal extent in the real world. Space boundaries are objects that bound a Space. They also realize the contact between adjacent spaces.
NOTE Space boundaries can be spatially represented in different LODs and by different types of geometric objects.
NOTE Space boundaries are represented in the CityGML 3.0 Conceptual Model by those classes that are derived from the class AbstractSpaceBoundary.
[CityGML Conceptual Model]
4.19. top-level feature
a feature that represents one of the main components of 3D city models; can be further semantically and spatially decomposed and substructured into parts
NOTE Top-level features are denoted by the stereotype «TopLevelFeatureType» in the CityGML 3.0 Conceptual Model.
[CityGML Conceptual Model]
5. Conventions
5.1. Identifiers
The normative provisions in this document are denoted by the URI
All requirements and conformance tests that appear in this document are denoted by partial URIs relative to this base.
5.2. UML Notation
This standard is an implementation of the CityGML Conceptual Model (CM) Standard. The CityGML conceptual model was constructed using the Unified Modeling Language (UML). The UML diagrams defined in the CityGML CM standard are not repeated here; instead, the reader is directed to Chapter 7 of the CityGML CM standard.
This standard provides several UML class diagrams for illustration purposes. The UML notations used are described in the CityGML CM standard in Chapter 5.2.
In addition, this standard provides several UML object diagrams as illustrations for CityGML instance documents. In order to enhance the readability of the UML object diagrams, objects are depicted in different colors. Objects painted in orange and yellow represent features as defined in the CityGML CM standard. The orange-colored objects represent the top-most features in the feature hierarchy of the CityGML instance document, the yellow-colored objects their subordinate features. Objects painted in green represent geometries as defined in ISO 19107:2003.
5.3. XML Notation
The CityGML XML schemas derived from the CityGML CM follow the rules in OGC 07-036r1, GML, Annex E, UML-to-GML application schema encoding rules.
6. Requirements
6.1. Global Requirements
This chapter defines general requirements which are valid for all Conformance Classes and cannot be derived from the GML schemas.
Requirements Class |
|
Target type |
Implementations of the CityGML 3.0 Conceptual Model using GML encodings |
Dependency |
- |
6.1.1. Use of GML 3.2
Requirement 1 |
/req/global/gml |
XML instance documents claiming conformance to this specification shall validate against the XML schema files provided in Appendix C. |
|
Note: This means that they have to be valid GML 3.2 documents. They may use certain aspects of GML 3.3; see Appendix F for further information. |
The CityGML 3.0 GML schemas have been derived based on the OGC GML 3.2 standard. This means that CityGML GML instance documents must be created and exchanged in the GML version 3.2.
If for certain reasons the use of GML 3.3 is preferred, Appendix F provides an example for how to make use of GML 3.3 in CityGML instance documents. Please note, however, that software compliant to this standard might not be able to read the additional GML 3.3 content.
6.1.2. Object identifiers for features and geometries
In the GML encoding of the CityGML 3.0 Conceptual Model, different types of objects exist: features, top-level features, and geometries. All these objects have a unique identity, thus, they can be distinguished from each other and can also be referenced from other objects.
The CityGML 3.0 Conceptual Model introduces two attributes to provide all features and top-level features with a unique identity: 1) the mandatory featureID attribute to distinguish all (top-level) features and possible multiple versions of the same real-world object and 2) an optional identifier attribute to reference specific (top-level) features independent from their actual feature version. The featureID attribute value is unique within the same CityGML dataset and also for a specific version of a feature, whereas the identifier attribute has an identical value for all versions of the same real-world object. It is recommended to use globally unique identifiers like UUID values or identifiers maintained by an organization such as a mapping agency for both attributes: for the identifier attribute, as these identifiers should remain stable over the lifetime of the real-world object, and for the featureID attribute, as this ensures that 3D city models which are integrated from different sources into e.g., one GIS or database will not have colliding featureID values and also to be able to uniquely identify a specific version of a feature using these identifiers together with a timestamp and a version number.
The two attributes are defined in the UML class AbstractFeature as part of the Core module of the CityGML 3.0 Conceptual Model. They are mapped to the predefined GML concepts gml:id and gml:identifier in the GML encoding. Table 3 lists the two identity attributes together with their definition and GML encoding, and the GML code in Listing 1 illustrates the use of the identity attributes to represent the object identity in GML instance documents. Please note that the values of the gml:id and the gml:identifier might also be identical, for example, when only a first version of the object exists. Please also note that, although the featureID attribute is defined mandatory in the CityGML 3.0 Conceptual Model, the gml:id attribute is optional according to the GML standard.
UML attributes to provide (top-level) features with identity |
Mapping to corresponding GML concepts |
Definition |
featureID |
XML attribute gml:id |
Specifies the unique identifier of the feature that is valid in the instance document within which it occurs. |
identifier |
XML element gml:identifier |
Specifies the global identifier of the feature. The identifier must be globally valid, unique and identical over different feature versions. |
<bldg:Building gml:id="B1020_t1">
<gml:identifier codeSpace="www.xyz.org">B1020</gml:identifier>
<core:creationDate>2012-08-02T00:00:00</core:creationDate>
<core:terminationDate>2013-10-09T00:00:00</core:terminationDate>
<bldg:function>Office</bldg:function>
</bldg:Building>
The GML encoding implements the geometry model defined in ISO 19107. This means that all geometries are derived from the class AbstractGML as well and, thus, also geometries exhibit the same unique identity as features do. The fact that geometries also have an identity is of particular importance for CityGML, since CityGML requires defining references to geometries. For these references, only the gml:id attribute is of interest. One example is the application of textures to surfaces. The textures reference the gml:ids of those LinearRings that describe the boundaries of the surface geometries (e.g., Triangle, Polygon, or a MultiSurface consisting of Polygons) to which the textures are applied. Another example is that the CityGML GML encoding allows for realizing topological relationships amongst others through referencing of shared geometries.
6.1.3. Referencing features and geometries
There are two XML concepts that are used to reference objects in GML instance documents: the XML Linking Language (XLink) and the XML Pointer Language (XPointer).
XLink allows for creating links (referred to as XLinks in this document) by providing specific attributes to XML elements for referencing other resources. The most commonly used attribute is xlink:href, the value of the attribute is the URI of the referenced document. In CityGML, however, we are mainly interested in referencing specific objects (features and geometries) within the same or an external GML instance document. To be able to reference specific objects, XPointer needs to be used in addition to XLink. For references to objects in external documents the URI value provided in the xlink:href attribute is complemented by a number sign (#) followed by the gml:id of the object to be referenced. For references to objects within the same document it is enough to provide the number sign (#) and the gml:id of the referenced object (this is also called a relative URI). This is exemplified in Listing 2, where the element <versionMember> references a <Building> feature. Since the feature is part of the same GML instance document, a relative URI is specified by simply providing the number sign and the gml:id of the building as value of the attribute xlink:href. In the context of version management, referencing features by their gml:id means that a specific feature version of a real-world object is referenced.
<core:CityModel gml:id="CM_1">
<core:versionMember>
<vers:Version gml:id="V_1">
<vers:versionMember xlink:href="#BU_234"/>
</vers:Version>
</core:versionMember>
<core:cityObjectMember>
<bldg:Building gml:id="BU_234"> ... </bldg:Building>
</core:cityObjectMember>
<core:CityModel>
When using references, it is important to keep in mind that many (top-level) features in CityGML have a complex structure. This is shown in Listing 3. In general, features can have spatial and non-spatial properties that describe the features in more detail. Spatial properties are properties that have a geometry from ISO 19107 as data type (<lod2Solid> in the example). Non-spatial properties can either have a simple data type (<function> with Integer value or <creationDate> with Date value), but they can also be further specified by additional attributes, such as the height of the building that is described by further properties (<height> with the additional properties <highReference>, <lowReference>, <status>, and <value>). In addition, they can also be composed of subfeatures that contain spatial and non-spatial properties themselves (<WallSurface> with <lod2MultiSurface> geometry).
The subfeatures can be provided inline or by reference. Inline means that the subfeatures are provided directly as content of the (top-level) feature as is shown below, where the subfeature <BuildingRoom> is provided as content of the <Building> feature. In contrast, by reference means that the subfeatures are provided elsewhere in the CityGML document and are referenced from the (top-level) feature using an XLink as is described above and illustrated in Listing 2.
<bldg:Building gml:id="BU_234">
<core:creationDate>2019-09-24T00:00:00</core:creationDate>
<core:boundary>
<con:WallSurface gml:id="WS_21">
<core:lod2MultiSurface>
<gml:MultiSurface gml:id="MS_21_1">
...
</gml:MultiSurface>
</core:lod2MultiSurface>
</con:WallSurface>
</core:boundary>
<core:lod2Solid>
<gml:Solid gml:id="S_1"> ... </gml:Solid>
</core:lod2Solid>
<con:height>
<con:Height>
<con:highReference>topOfConstruction</con:highReference>
<con:lowReference>lowestGroundPoint</con:lowReference>
<con:status>measured</con:status>
<con:value uom="urn:adv:uom:m">24.709</con:value>
</con:Height>
</con:height>
<bldg:function>1000</bldg:function>
<bldg:buildingRoom>
<bldg:BuildingRoom gml:id="BR_3">
...
</bldg:BuildingRoom>
<bldg:buildingRoom>
</bldg:Building>
6.1.4. Rules for linking features and geometries that are shared by multiple features
When modeling cities, geometries and features can be integral parts of multiple city objects. To avoid redundant modeling of these geometries and features, CityGML offers the possibility to represent geometries and features only once and to reference them from any other city object to which they belong as well. This non-redundant representation guarantees that no integrity problems occur, i.e., several differing instances of the same geometry or feature will not exist.
Three different cases for non-redundant representation need to be differentiated.
-
Geometries are represented in different parts within the same top-level feature. An example is the roof surface of a building. The polygon representing the geometry of the RoofSurface feature is at the same time part of the RoofSurface feature and of the Solid geometry of the Building feature.
-
One geometry can be part of the representation of different features. An example is a road across a bridge, the road surface sharing the geometry with the roof surface of the bridge.
-
One and the same feature can belong to different aggregations. Examples are an intersection that belongs to two roads, the intersection being one and the same feature for both roads, or features that belong to a CityObjectGroup and that are already integral part of the city model.
For these cases, different requirements are provided for how to encode the references in CityGML. Although these requirements impose restrictions, they facilitate at the same time reading, storing, processing, and generating of CityGML documents, because they reduce the multiple possibilities of how to represent and link features and geometries in CityGML documents to the most appropriate ones. Furthermore, top-level features can now completely be loaded in the main memory, because links to shared geometries that are part of different top-level features represented further down in the GML document do not need to be resolved any more. This also facilitates querying features and geometries using web services, as up to now queries cannot address specific parts of a geometry. Maintenance at the level of the top-level features becomes easier as well, because links between feature geometries do not need to be maintained and updated any more when a feature changes its geometry or when the feature does not exist anymore.
Requirement 2 |
/req/global/referencinggeometries1 |
XLinks SHALL NOT be used to reference geometries, except for geometries of ImplicitGeometry elements, from another top-level feature. |
|
Note 1: XLinks MAY be used to reference geometries within the same top-level feature in accordance with /req/global/referencinggeometries2 and /req/global/referencinggeometries3. |
Requirement 3 |
/req/global/referencinggeometries2 |
Referencing geometries of spaces and space boundaries is subject to the following restrictions: |
|
A |
Geometries stored inline a space boundary SHALL NOT be redundantly stored as geometry of a space. If the geometry shall be stored with the space in addition, it SHALL reference the geometry from the space boundary using XLinks. |
B |
Space boundaries SHALL NOT reference geometries of a space using XLinks. |
C |
Rules A and B apply for all spaces and space boundaries that are children of the same top-level feature. |
Note 1: The rationale of requirement A is to avoid duplicate geometries. It does NOT imply that a space has to reference all geometries of its space boundaries using XLinks. For example, the geometry can also be stored only with the space boundaries. |
Requirement 4 |
/req/global/referencinggeometries3 |
LoDs SHALL be self-contained: Geometries SHALL NOT be shared between different LoDs using XLinks. |
In these requirements, XLink represents a link at the geometry level (“geometry link”), i.e., a reference to the ID of the geometry to be reused. The link direction is always from the geometry of the space to the geometries of the space boundaries (example 1).
Requirement 5 |
/req/global/referencinggeometries4 |
Referencing shared geometries between top-level features using CityObjectRelations is subject to the following restrictions: |
|
A |
If two top-level features share a common geometry, the shared geometry SHALL be stored for each top-level feature separately (follows from /req/global/referencinggeometries1). |
B |
If CityObjectRelations are used to denote that a geometry is shared between two top-level features, then a CityObjectRelation SHALL be stored for each feature (might be the top-level feature itself or one of its nested features), and each CityObjectRelation SHALL be assigned the relation type “shared” and SHALL reference the other feature using an XLink. Thus, the reference SHALL be bi-directional. |
Note: Using CityObjectRelations to link the features that share a common geometry is optional. Thus, requirement B only applies if CityObjectRelations are used. |
CityObjectRelation represents a link at the feature level (“feature link”) referencing the ID of another feature that contains a shared geometry. The explicit representation of the relation between the features facilitates spatial analyses.
Requirement 6 |
/req/global/alternativeaggregations |
For referencing features from alternative aggregations: |
|
A |
Each feature belongs to a natural aggregation hierarchy and SHALL be stored inline this hierarchy. |
B |
Alternative aggregations SHALL NOT contain the feature inline but SHALL use an XLink to reference the feature. |
In this requirement, XLink represents a link at the feature level (“feature link”), i.e., a reference to the ID of the feature being part of the natural aggregation. All features are part of a natural aggregation, i.e., features are typically represented in a data set once in physical form, either directly as part of the city model when they are top-level features (e.g., a Building), or inline as part of other (top-level) features (e.g., a BuildingRoom represented inline as part of the top-level feature Building). At the same time, the features can also occur in alternative aggregations.
Example 1: Building with Solid geometry and boundary surfaces
The building (=space) in Figure 1 is modeled in LOD2 as Solid geometry and is bounded by four WallSurfaces, one RoofSurface, and one GroundSurface (=space boundaries). All space boundaries are modeled as Polygon geometries. The Solid geometry of the building references the Polygon geometries using XLink. This example refers to Requirement /req/global/referencinggeometries2.
The GML file is available on the CityGML 3.0 GML Encoding GitHub.
The Building from the GML file is illustrated in the object diagram in Figure 2. The XLink references between the Solid geometry and the Polygon geometries are highlighted in red.
Example 2: Building with roof overhangs
The building (=space) in Figure 3 is modeled in LOD2 as Solid geometry and is bounded by four WallSurfaces, one RoofSurface, and one GroundSurface (=space boundaries). All space boundaries are modeled as Polygon geometries. The Solid geometry of the building references the Polygon geometries using XLink. This example refers to Requirement /req/global/referencinggeometries2.
The RoofSurface contains four Polygon geometries. Two of these Polygons are roof overhangs (i.e., dangling surfaces), and, thus, are not referenced by the Solid geometry of the building, as they would render the solid invalid if referenced. For this reason, an additional MultiSurface geometry is added to the building that references the dangling surfaces. In accordance with Requirement /req/global/referencinggeometries2 this MultiSurface geometry is optional. It is added to the building to provide additional information, but it is not mandatory to add this geometry.
The GML file is available on the CityGML 3.0 GML Encoding GitHub.
The Building from the GML file is illustrated in the object diagram in Figure 4. The XLink references between the Solid geometry and the Polygon geometries are highlighted in red, the XLink references between the MultiSurface geometry and the dangling surfaces in blue.
Example 3: Building with BuildingInstallation
The building (=space) in Figure 5 is modeled in LOD2 as Solid geometry and is bounded by eight WallSurfaces, four RoofSurfaces, and one GroundSurface (=space boundaries). In addition, the building has a dormer that is modeled as BuildingInstallation (=space). The building installation is modeled as MultiSurface geometry and is bounded by one RoofSurface and three WallSurfaces (=space boundaries). This example refers to Requirement /req/global/referencinggeometries2.
The space boundaries of the building and of the building installation are all modeled as Polygon geometries. The Solid geometry of the building references those Polygon geometries that represent the space boundaries of the building space using XLink. The MultiSurface geometry of the building installation references those Polygon geometries that represent the space boundaries of the building installation using XLink. Moreover, in this example, the Solid geometry of the building has to additionally reference the Polygon geometries that represent the space boundaries of the building installation using XLink to ensure a closed and watertight volume geometry. In general, however, references to the geometries of a nested space are optional, and it is allowed to not reference them in accordance with Requirement /req/global/referencinggeometries2.
The GML file is available on the CityGML 3.0 GML Encoding GitHub.
The Building from the GML file is illustrated in the object diagram in Figure 6. The XLink references from the building to the space boundaries of the building are highlighted in red, whereas those to the space boundaries of the building installation are highlighted in blue.
Example 4: Two buildings with shared boundary surface
The two buildings (=top-level features) in Figure 7 are modeled in LOD2 as Solid geometry and are bounded by Wall-, Roof-, and GroundSurfaces that are modeled as Polygon geometries. One of the WallSurfaces of the first Building shares the Polygon geometry with one of the WallSurfaces of the second Building. Both WallSurfaces might appear identical, however, the surface normals of the Polygon geometries of the WallSurfaces are pointing in opposite directions. This example refers to Requirements /req/global/referencinggeometries1 and /req/global/referencinggeometries4.
To express that the WallSurfaces of the two buildings share the Polygon geometry, the WallSurfaces reference each other using a CityObjectRelation with the relation type “shared.” Both WallSurfaces contain the Polygon geometry themselves, the second WallSurface, however, in reverse order.
The GML file is available on the CityGML 3.0 GML Encoding GitHub.
The Buildings from the GML file are illustrated in the object diagram in Figure 8. The CityObjectRelation is highlighted in red.
Example 5: Road crossing a Bridge
A Road and a Bridge (=top-level features) are modeled in LOD2, as is shown in Figure 9. The Bridge is bounded by Ground-, Roof-, and WallSurfaces that are modeled as MultiSurface geometries. The Road consists of three sections; each section is bounded by two TrafficAreas that are modeled as MultiSurface geometries as well. The RoofSurfaces of the Bridge share MultiSurface geometries with two TrafficAreas of the Road. The RoofSurfaces and the TrafficAreas are geometrically identical, but they differ semantically. This example refers to Requirements /req/global/referencinggeometries1 and /req/global/referencinggeometries4.
To express that the RoofSurfaces share MultiSurface geometries with two TrafficAreas, they reference each other using CityObjectRelations with the relation type “shared.”
The GML file is available on the CityGML 3.0 GML Encoding GitHub.
The Road and Bridge from the GML file are illustrated in the object diagram in Figure 10. The CityObjectRelations are highlighted in red.
Example 6: Parking garage
The parking garage in Figure 11 is modeled in LOD2 as a building (=top-level feature) with Floor-, Roof-, and WallSurfaces that are modeled as MultiSurface geometries. The parking garage contains a Road with Sections and TrafficAreas that are modeled as MultiSurface geometries as well. The Floor- and RoofSurface of the Building share MultiSurface geometries with the Sections and TrafficAreas of the Road. This example refers to Requirements /req/global/referencinggeometries1 and /req/global/referencinggeometries4.
To express the sharing of MultiSurface geometries between the Roof-/WallSurfaces and the Sections/TrafficAreas, they reference each other using CityObjectRelations with the relation type “shared.”
The GML file is available on the CityGML 3.0 GML Encoding GitHub.
Example 7: A specific version of a city model
A Version feature groups, for instance, different versions of city objects that are valid within a specific time period. The city model represents the natural aggregation of these versioned city objects, whereas the Version feature represents the alternative aggregation. Thus, the versioned city objects are represented inline as part of the city model, whereas they are referenced by the Version feature using XLink references. This example refers to Requirement /req/global/alternativeaggregations.
Example 8: CityObjectGroups
A CityObjectGroup groups existing city objects that are usually represented inline somewhere else in the data set. Thus, CityObjectGroups represent alternative aggregations and have to use XLink to reference the city objects they are grouping. This example refers to Requirement /req/global/alternativeaggregations.
Referencing features from multiple and different contexts
The same feature can also be used in multiple and different contexts without being able to distinguish between a natural and alternative aggregations. Nevertheless, also in such scenarios it is recommended to store the feature only once and to reference it from every other context using XLinks in order to avoid duplication and to ensure a non-redundant representation. For this reason, referencing features using XLinks is allowed beyond the scope of Requirement /req/global/alternativeaggregations even between top-level features. The following examples illustrate some of these scenarios.
Example 9: Building rooms belonging to a Storey
BuildingRooms are usually represented inline as part of the Building they belong to. In addition, Storeys can group BuildingRooms to indicate which BuildingRoom belongs to which Storey. In this case, when the BuildingRooms are already represented inline the Building, the Storeys would reference the BuildingRooms using XLinks to avoid duplication. However, since there is no clear distinction between a natural and alternative aggregations in this example, the BuildingRooms could also be contained inline the corresponding Storey and be referenced from the Building feature.
Example 10: A Building installation spanning across several Building Parts
Installations that are spanning across several building parts are to be physically modeled as part of one building part. All other building parts reference the installation using XLinks, expressing in this way that the installation does not exclusively belong to one building part only. Since there is no natural or alternative aggregation in this example either, one can choose which building part should contain the installation and which building parts should rather use XLink references.
Example 11: Intersection as part of two Roads
In Figure 12, two Roads (=top-level features) are shown both of which have two Sections and one Intersection. The two Roads cross each other at the Intersection. Although the Intersection and, thus, also its geometry is shared by both Roads, it exists in reality only once; i.e., the Intersection is an integral part of both Roads. In contrast to Requirement /req/global/referencinggeometries4, this should not be expressed by duplicating the Intersection to represent it inline of both Roads and link the duplicates using CityObjectRelations. Instead, the Intersection should be represented inline as part of one Road (here: Road 2) and be referenced by the other Road (here: Road 3) using an XLink that references the ID of the Intersection feature. Also in this example, the roads cannot be semantically distinguished as natural or alternative aggregation of the Intersection.
The GML file is available on the CityGML 3.0 GML Encoding GitHub.
The two Roads and the Intersection from the GML file are illustrated in the object diagram in Figure 13. The XLink reference is highlighted in red.
6.2. Core
The Core module defines the basic components of the CityGML conceptual model. This includes abstract base classes that define the core properties of more specialized thematic classes defined in other modules as well as concrete classes that are common to other modules, for example basic data types.
The concepts of the Core module are defined in the OGC CityGML 3.0 Conceptual Model standard. The UML diagram for the Core module is available under https://docs.ogc.org/is/20-010/20-010.html#core-uml, the Data Dictionary is available under https://docs.ogc.org/is/20-010/20-010.html#toc49. A detailed discussion of the Core module can also be found in the CityGML 3.0 Users Guide.
Requirements Class |
|