Approved

OGC Standard

•
OGC City Geography Markup Language (CityGML) Part 1: Conceptual Model Standard
Thomas H. Kolbe Editor Tatjana Kutzner Editor Carl Stephen Smyth Editor Claus Nagel Editor Carsten Roensdorf Editor Charles Heazel Editor
Submission Date: 2021-03-02 Approval Date: 2021-06-04 Publication Date: 2021-09-13 External identifier of this OGC® document: http://www.opengis.net/doc/IS/CityGML-1/3.0 Internal identifier of this OGC® document: 20-010
Version: 3.0.0
Additional Formats: XML PDF DOC
OGC Standard

Approved

Notice

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 number:20-010
Document type:OGC Standard
Document subtype:Conceptual Model
Document stage:Approved
Document language:English

Copyright notice

Copyright © 2021 Open Geospatial Consortium
To obtain additional rights of use, visit http://www.ogc.org/legal/

Note

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.


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.

None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.

Suggested additions, changes and comments on this standard are welcome and encouraged. Such suggestions may be submitted using the online change request form on OGC web site: http://portal.opengeospatial.org/public_ogc/change_request.php



I.  Abstract

This Standard defines the open CityGML Conceptual Model for the storage and exchange of virtual 3D city models. The CityGML Conceptual Model is defined by a Unified Modeling Language (UML) object model. This UML model builds on the ISO Technical Committee 211 (ISO/TC 211) conceptual model standards for spatial and temporal data. Building on the ISO foundation assures that the man-made features described in the city models share the same spatiotemporal universe as the surrounding countryside within which they reside.

A key goal for the development of the CityGML Conceptual Model is to provide a common definition of the basic entities, attributes, and relations of a 3D city model. This is especially important with respect to the cost-effective sustainable maintenance of 3D city models, allowing the reuse of the same data in different application fields.

The class models described in this standard are also available at https://github.com/opengeospatial/CityGML3-Workspace/tree/1.0/UML/CityGML

II.  Keywords

The following are keywords to be used by search engines and document catalogues.

ogcdoc, OGC document, CityGML, 3D city models

III.  Security considerations

No security considerations have been made for this standard.

IV.  Submitting Organizations

The following organizations submitted this Document to the Open Geospatial Consortium (OGC):

V.  Submitters

All questions regarding this submission should be directed to the editors or the submitters:

Name Affiliation
Emmanuel Devys Institut national de l’information géographique et forestière (IGN), France
Volker Coors HFT Stuttgart, Germany
Sylvester Hagler U.S. National Geospatial-Intelligence Agency
Charles (Chuck) Heazel HeazelTech LLC
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
Carsten Roensdorf Ordnance Survey, Great Britain
Carl Stephen Smyth OpenSitePlan, USA

VI.  Participants in development

In addition to the Editors of the specification the following individuals contributed to the CityGML 3.0 development:

Name Institution
Giorgio Agugiaro 3D Geoinformation Group, Delft University of Technology, the Netherlands
Christof Beil Chair of Geoinformatics, Technical University of Munich, Germany
Filip Biljecki Department of Architecture, National University of Singapore, Singapore
Kanishk Chaturvedi Chair of Geoinformatics, Technical University of Munich, Germany
Volker Coors HFT Stuttgart, Germany
Emmanuel Devys Institut national de l’information géographique et forestière (IGN), France
Jürgen Ebbinghaus AED-SICAD, Germany
Heinrich Geerling Architekturbüro Geerling, Germany
Gilles Gesquière LIRIS, University of Lyon, France
Gerhard Gröger CPA ReDev GmbH, Germany
Karl-Heinz Häfele Institute for Automation and Applied Informatics, Karlsruhe Institute of Technology, Germany
Nobuhiro Ishimaru Hitachi, Ltd., Japan
Marc-Oliver Löwner Institute for Geodesy and Photogrammetry, Technische Universität Braunschweig, Germany
Diana Moraru Ordnance Survey, Great Britain
Friso Penninga Geonovum, the Netherlands
Helga Tauscher Faculty of Spatial Information, HTW Dresden — University of Applied Sciences, Germany
Linda van den Brink Geonovum, the Netherlands
Heidi Vanparys Danish Agency for Data Supply and Efficiency, Denmark
Sisi Zlatanova Faculty of Built Environment, University of New South Wales, Australia

The table only lists persons that were involved in the development of CityGML 3.0. CityGML 3.0 is based on extensive previous work that was done for CityGML 2.0. For persons involved in the previous work, please refer to the CityGML 2.0 specification.

VII.  Introduction

An increasing number of cities and companies are building virtual 3D city models for different application areas like urban planning, mobile telecommunication, disaster management, 3D cadastre, tourism, vehicle and pedestrian navigation, facility management, and environmental simulations. Furthermore, in the implementation of the European Environmental Noise Directive (END, 2002/49/EC) 3D geoinformation and 3D city models play an important role.

In recent years, most virtual 3D city models were defined as purely graphical or geometrical models, neglecting the semantic and topological aspects. Thus, these models could almost only be used for visualization purposes but not for thematic queries, analysis tasks, or spatial data mining. Since the limited reusability of models inhibits the broader use of 3D city models and may not justify the costs associated with maintaining city models, a more general modeling approach had to be taken in order to satisfy the information needs of the various application fields.

The CityGML Conceptual Model Standard defines a common semantic information model for the representation of 3D urban objects that can be shared over different applications. The latter capability is especially important with respect to the cost-effective sustainable maintenance of 3D city models, allowing governments and companies to reap the benefits of their investment in 3D city models by being able to put the same models into play in different application fields. The targeted application areas explicitly include city planning, architectural design, tourist and leisure activities, environmental simulation, mobile telecommunication, disaster management, homeland security, real estate management, vehicle and pedestrian navigation, and training simulators.

The CityGML Conceptual Model defines the classes and relations for 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. CityGML is applicable for large areas and small regions, and can represent the terrain and 3D objects in different levels of detail simultaneously. Since both simple, single scale models without topology and few semantics as well as very complex multi-scale models with full topology and fine-grained semantical differentiations can be represented, CityGML enables the consistent representation of 3D urban objects across different geographic information systems and users.

VIII.  Acknowledgements

The editors wish to thank the Special Interest Group 3D (SIG 3D) of the initiative Geodata Infrastructure Germany (GDI-DE) which originally started the development of CityGML, the CityGML Standards Working Group and the 3D Information Management (3DIM) Working Group of the OGC as well as all contributors of change requests and comments.

CityGML official logo

This is the official CityGML logo. For current news on CityGML and information about ongoing projects and fields of research in the area of CityGML see http://www.citygml.org and http://www.citygmlwiki.org.

OGC City Geography Markup Language (CityGML) Part 1: Conceptual Model Standard

1.  Scope

This Standard documents an OGC Conceptual Model (CM) Standard for specifying the representation of virtual 3D city and landscape models. The CityGML 3.0 Conceptual Model is a Platform Independent Model (PIM) (Clause 4.1.12). It defines concepts in a manner which is independent of any implementing technology. As such, the CityGML CM cannot be implemented directly. Rather, it serves as the base for Platform Specific Models (PSM) (Clause 4.1.13). 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 does not define the PSMs nor schemas for CityGML 3.0. Future CityGML 3.0 Implementation Specifications (IS) (Clause 4.1.8) will be developed to address this need. At a minimum, support for a Geography Markup Language (GML) Implementation Specification is expected. Additional Implementation Specifications for JSON and database schemas are also highly desirable.

A discussion of current and planned efforts to build Implementation Specifications for the CityGML Conceptual Model can be found in the CityGML 3.0 Users Guide.

The target of the conformance classes specified in this document are:

CityGML models are comprised of 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 that allows for the integration of a variety of source data to come together in a City Model. To enable the use of CityGML in specific domain areas, CityGML has historically provided an extension mechanism to enrich the data with identifiable features and properties, preserving semantic interoperability. Recognizing that an implementable expansion mechanism might have dependencies based on the encoding language, the CityGML 3.0 Conceptual Model specifies high level requirements rather than a full extension model.

Targeted application areas explicitly include:

The future CityGML 3.0 Implementation Specifications will be implementable source formats for 3D portraying or transformation into dedicated portrayal formats such as the OGC I3S (OGC 17-014r7) or the OGC 3D Tiles Community Standards (OGC 18-053r2), OGC KML (OGC 12-007r2), Khronos COLLADA or Khronos gLTF. The OGC 3D Portrayal Service (3DPS) (OGC 15-001r4) may be used for content delivery.

Features of the CityGML 3.0 Conceptual Model include the following.

2.  Conformance

This Standard defines a Conceptual Model (Clause 4.1.6) which is independent of any encoding or formatting techniques. The Standardization Targets (Annex C.1.14) for this Standard are:

  1. Conceptual Models (Clause 4.1.6) (extended versions of this conceptual model)

  2. Implementation Specifications (Clause 4.1.8) (encodings of this conceptual model)

2.1.  Conceptual Models

A Conceptual Model standardization target is a version of the CityGML 3.0 Conceptual Model (CM) tailored for a specific user community. This tailoring can include:

  1. Omission of one or more of the optional UML packages;

  2. Reduction of the multiplicity for an attribute or association;

  3. Restriction on the valid values for an attribute; and

  4. Additional concepts documented through ADEs.

Of these options, actions #1, #2, and #3 can be performed when creating an implementation specification. Only action #4 requires an extension of the CityGML conceptual model. These extensions are accomplished using the ADE mechanism described in Application Domain Extensions (ADE) (Clause 9).

Extensions of the CityGML Conceptual Model conform with the ADE Conformance Class.

2.2.  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 should include implementations of the abstract tests specified in Annex A of this document.

Since this Standard is agnostic to the implementing technologies, the specific techniques to be used for conformance testing cannot be specified. Implementation Specifications need to provide evidence of conformance which is appropriate for the implementing technologies. This evidence should be provided as an annex to the Implementation Specification document.

2.3.  Conformance Classes

This Standard identifies seventeen (17) conformance classes. One conformance class is defined for each package in the UML model. 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.

The CityGML Conceptual Model is defined by the CityGML UML model. This Standard is a representation of that UML model in document form. In the case of a discrepancy between the UML model and this document, the UML model takes precedence.

3.  Normative references

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

Cliff Kottman and Carl Reed: OGC 08-126, Topic 5 — Features. Open Geospatial Consortium (2009). https://portal.ogc.org/files/?artifact_id=29536

Cliff Kottman: OGC 99-108r2, Topic 8 — Relationships Between Features. Open Geospatial Consortium (1999). https://portal.ogc.org/files/?artifact_id=894

Cliff Kottman: OGC 99-110, Topic 10 — Feature Collections. Open Geospatial Consortium (1999). https://portal.ogc.org/files/?artifact_id=897

Alexandre Robin: OGC 08-094r1, OGC® SWE Common Data Model Encoding Standard. Open Geospatial Consortium (2011). https://portal.ogc.org/files/?artifact_id=41157

James Tomkins , Dominic Lowe : OGC 15-043r3, Timeseries Profile of Observations and Measurements . Open Geospatial Consortium (2016). http://docs.opengeospatial.org/is/15-043r3/15-043r3.html

ISO: ISO 19101-1:2014, Geographic information — Reference model — Part 1: Fundamentals. International Organization for Standardization, Geneva (2014). https://www.iso.org/standard/59164.html

ISO: ISO 19101-2:2018, Geographic information — Reference model — Part 2: Imagery. International Organization for Standardization, Geneva (2018). https://www.iso.org/standard/69325.html

ISO: ISO 19103:2015, Geographic information — Conceptual schema language. International Organization for Standardization, Geneva (2015). https://www.iso.org/standard/56734.html

ISO: ISO 19105:2000, Geographic information — Conformance and testing. International Organization for Standardization, Geneva (2000). https://www.iso.org/standard/26010.html

ISO: ISO 19107:2003, Geographic information — Spatial schema. International Organization for Standardization, Geneva (2003). https://www.iso.org/standard/26012.html

ISO: ISO 19108:2006, ISO: ISO 19108:2002/Cor 1:2006, Geographic information – Temporal schema — Technical Corrigendum 1 (2006). ISO (2006).

ISO: ISO 19109:2015, Geographic information — Rules for application schema. International Organization for Standardization, Geneva (2015). https://www.iso.org/standard/59193.html

ISO: ISO 19111:2019, Geographic information — Referencing by coordinates. International Organization for Standardization, Geneva (2019). https://www.iso.org/standard/74039.html

ISO: ISO 19123:2005, Geographic information — Schema for coverage geometry and functions. International Organization for Standardization, Geneva (2005). https://www.iso.org/standard/40121.html

ISO: ISO 19143:2010, Geographic information — Filter encoding. International Organization for Standardization, Geneva (2010). https://www.iso.org/standard/42137.html

ISO: ISO 19156:2011, Geographic information — Observations and measurements. International Organization for Standardization, Geneva (2011). https://www.iso.org/standard/32574.html

ISO/IEC: ISO/IEC 19505-2:2012, Information technology — Object Management Group Unified Modeling Language (OMG UML) — Part 2: Superstructure. International Organization for Standardization and International Electrotechnical Commission, Geneva (2012). https://www.iso.org/standard/52854.html

ISO/IEC: ISO/IEC 19507:2012, Information technology — Object Management Group Object Constraint Language (OCL). International Organization for Standardization and International Electrotechnical Commission, Geneva (2012). https://www.iso.org/standard/57306.html

ISO/IEC: ISO/IEC 19775-1:2013, Information technology — Computer graphics, image processing and environmental data representation — Extensible 3D (X3D) — Part 1: Architecture and base components. International Organization for Standardization and International Electrotechnical Commission, Geneva (2013). https://www.iso.org/standard/60760.html

N. Freed, N. Borenstein: IETF RFC 2045, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. Internet Engineering Task Force, Fremont, CA (1996). https://raw.githubusercontent.com/relaton/relaton-data-ietf/master/data/reference.RFC.2045.xml

N. Freed, N. Borenstein: IETF RFC 2046, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. Internet Engineering Task Force, Fremont, CA (1996). https://raw.githubusercontent.com/relaton/relaton-data-ietf/master/data/reference.RFC.2046.xml

T. Berners-Lee, R. Fielding, L. Masinter: IETF RFC 3986, Uniform Resource Identifier (URI): Generic Syntax. Internet Engineering Task Force, Fremont, CA (2005). https://raw.githubusercontent.com/relaton/relaton-data-ietf/master/data/reference.RFC.3986.xml

INSPIRE: D2.8.III.2 Data Specification on Buildings – Technical Guidelines. European Commission Joint Research Centre. (2013)

Khronos Group Inc.: COLLADA – Digital Asset Schema Release 1.5.0 (2008)

OASIS: Customer Information Quality Specifications — extensible Address Language (xAL), Version v3.0 (2008)

4.  Terms, definitions and abbreviated terms

This document uses the terms defined in OGC Policy Directive 49, 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 and OGC documents do not use the equivalent phrases in the ISO/IEC Directives, Part 2.

This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the ‘ModSpec’. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.

For the purposes of this document, the following additional terms and definitions apply.

4.1.  Terms and definitions

4.1.1. 2D data

geometry of features is represented in a two-dimensional space

Note 1 to entry: In other words, the geometry of 2D data is given using (X,Y) coordinates.

[SOURCE: INSPIRE: D2.8.III.2, Definition 1]

4.1.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

[SOURCE: INSPIRE: D2.8.III.2, Definition 2]

4.1.3. 3D data

Geometry of features is represented in a three-dimensional space.

[SOURCE: INSPIRE: D2.8.III.2, Definition 3]

4.1.4. application schema

A set of conceptual schema (Clause 4.1.7) 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.

[SOURCE: OGC Definitions Register, URI http://www.opengis.net/def/glossary/term/ApplicationSchema]

4.1.5. codelist

A value domain including a code for each permissible value.

4.1.6. conceptual model

model that defines concepts of a universe of discourse

[SOURCE: ISO 19101-1:2014, Clause 4.1.5]

4.1.7. conceptual schema

  1. formal description of a conceptual model (Clause 4.1.6)

    [SOURCE: ISO 19101-1:2014, Clause 4.1.6]

  2. base schema. Formal description of the model of any geospatial information. Application schemas (Clause 4.1.4) are built from conceptual schemas.

    [SOURCE: OGC Definitions Register, URI http://www.opengis.net/def/glossary/term/ConceptualSchema]

4.1.8. Implementation Specification

Specified on the OGC Document Types Register

[SOURCE: OGC Document Types Register, URI http://www.opengis.net/def/doc-type/is]

4.1.9. levels of detail

quantity of information that portrays the real world

Note 1 to entry: 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.

[SOURCE: INSPIRE Glossary]

4.1.10. 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

[SOURCE: INSPIRE Glossary]

4.1.11. Platform (Model Driven Architecture)

the set of resources on which a system is realized.

[SOURCE: OMG MDA]

4.1.12. Platform Independent Model

a model that is independent of a specific platform

[SOURCE: OMG MDA]

4.1.13. Platform Specific Model

a model of a system that is defined in terms of a specific platform

[SOURCE: OMG MDA]

4.2.  Abbreviated terms

AEC

Architecture, Engineering, Construction

ALKIS

German National Standard for Cadastral Information

ATKIS

German National Standard for Topographic and Cartographic Information

B-Rep

Boundary Representation

BIM

Building Information Modeling

bSI

buildingSMART International

CAD

Computer Aided Design

COLLADA

Collaborative Design Activity

CSG

Constructive Solid Geometry

DTM

Digital Terrain Model

DXF

Drawing Exchange Format

ESRI

Environmental Systems Research Institute

EuroSDR

European Spatial Data Research Organisation

FM

Facility Management

GDF

Geographic Data Files

GDI

NRW Geodata Infrastructure North-Rhine Westphalia

GDI-DE

Spatial Data Infrastructure Germany (Geodateninfrastruktur Deutschland)

GML

Geography Markup Language

IAI

International Alliance for Interoperability (now buildingSMART International (bSI))

IETF

Internet Engineering Task Force

IFC

Industry Foundation Classes

IoT

Internet of Things

ISO

International Organization for Standardisation

ISO/TC211

ISO Technical Committee 211

LOD

Levels of Detail

MQTT

Message Queuing Telemetry Transport

NBIMS

National Building Information Model Standard

OASIS

Organisation for the Advancement of Structured Information Standards

OGC

Open Geospatial Consortium

OSCRE

Open Standards Consortium for Real Estate

SIG

Special Interest Group 3D of the GDI-DE

TIC

Terrain Intersection Curve

TIN

Triangulated Irregular Network

UML

Unified Modeling Language

URI

Uniform Resource Identifier

VRML

Virtual Reality Modeling Language

WFS

OGC Web Feature Service

W3C

World Wide Web Consortium

W3DS

OGC Web 3D Service

xAL

OASIS extensible Address Language

XML

Extensible Markup Language

X3D

Open Standards XML-enabled 3D file format of the Web 3D Consortium

2D

Two Dimensional

3D

Three Dimensional

5.  Conventions

5.1.  Identifiers

The normative provisions in this document are denoted by the URI

http://www.opengis.net/spec/CityGML-1/3.0

All requirements and conformance tests that appear in this document are denoted by partial URIs relative to this base.

5.2.  UML Notation

The CityGML Conceptual Model (CM) Standard is presented in this document through diagrams using the Unified Modeling Language (UML) static structure diagram (see Booch, et al. 1997). The UML notations used in this Standard are described in the diagram in Figure 1.

Figure 1 — UML notation (see ISO TS 19103, Geographic information — Conceptual schema language).

All associations between model elements in the CityGML Conceptual Model are uni-directional. Thus, associations in the model are navigable in only one direction. The direction of navigation is depicted by an arrowhead. In general, the context an element takes within the association is indicated by its role. The role is displayed near the target of the association. If the graphical representation is ambiguous though, the position of the role has to be drawn to the element the association points to.

The following stereotypes are used in this model.

  • «ApplicationSchema» denotes a conceptual schema for data required by one or more applications. In the CityGML Conceptual Model, every module is defined as a separate application schema to allow for modularization.

  • «FeatureType» represents features that are similar and exhibit common characteristics. Features are abstractions of real-world phenomena and have an identity.

  • «TopLevelFeatureType» denotes features that represent the main components of the conceptual model. Top-level features may be further semantically and spatially decomposed and substructured into parts.

  • «Type» denotes classes that are not directly instantiable, but are used as an abstract collection of operation, attribute and relation signatures. The stereotype is used in the CityGML Conceptual Model only for classes that are imported from the ISO standards 19107, 19109, 19111, and 19123.

  • «ObjectType» represents objects that have an identity, but are not features.

  • «DataType» defines a set of properties that lack identity. A data type is a classifier with no operations, whose primary purpose is to hold information.

  • «Enumeration» enumerates the valid attribute values in a fixed list of named literal values. Enumerations are specified in the CityGML Conceptual Model.

  • «BasicType» defines a basic data type.

  • «CodeList» enumerates the valid attribute values. In contrast to Enumeration, the list of values is open and, thus, not given inline in the CityGML UML Model. The allowed values can be provided within an external code list.

  • «Union» is a list of attributes. The semantics are that only one of the attributes can be present at any time.

  • «Property» denotes attributes and association roles. This stereotype does not add further semantics to the conceptual model, but is required to be able to add tagged values to the attributes and association roles that are relevant for the encoding.

  • «Version» denotes that the value of an association role that ends at a feature type is a specific version of the feature, not the feature in general.

In order to enhance the readability of the CityGML UML diagrams, classes are depicted in different colors. The following coloring scheme is applied.

Figure 2 — Notation for class belonging to the Requirements Class which is subject of discussion in that clause

Classes painted in yellow belong to the Requirements Class which is subject of discussion in that clause of the standard in which the UML diagram is given. For example, in the context of Clause 7.2, which introduces the CityGML Core module, the yellow color is used to denote classes that are defined in the CityGML Core Requirements Class. Likewise, the yellow classes shown in the UML diagram in Clause 7.17 are associated with the Building Requirements Class that is subject of discussion in that chapter.

Figure 3 — Notation for class belonging to a Requirements Class different to that associated with the yellow color

Classes painted in blue belong to a Requirements Class different to that associated with the yellow color. In order to explicitly denote to which Requirements Class these classes belong, their class names are preceded by the UML package name of that Requirements Class. For example, in the context of the Building Requirements Class, classes from the CityGML Core and the Construction Requirements Classes are painted in blue and their class names are preceded by Core and Construction, respectively.

Figure 4 — Notation for class defined in ISO 19107:2003, ISO 19111:2019, or ISO 19123:2005

Classes painted in green are defined in the ISO standards ISO 19107:2003, ISO 19111:2019, or ISO 19123:2005. Their class names are preceded by the UML package name, in which the classes are defined.

Figure 5 — Notation for class defined in ISO 19109:2015

Classes painted in grey are defined in the ISO standard ISO 19109:2015. In the context of this Standard, this only applies to the class AnyFeature. AnyFeature is an instance of the metaclass FeatureType and acts as super class of all classes in the CityGML UML model with the stereotype «FeatureType». A metaclass is a class whose instances are classes.

Figure 6 — Notation for UML notes and OCL constraints

The color white is used for notes and Object Constraint Language (OCL) (ISO/IEC 19507:2012) constraints that are provided in the UML diagrams.

The example UML diagram in Figure 7 demonstrates the UML notation and coloring scheme used throughout this Standard. In this example, the yellow classes are associated with the CityGML Building module, the blue classes are from the CityGML Core and Construction modules, and the green class depicts a geometry element defined by ISO 19107:2003.

Figure 7 — Example UML diagram demonstrating the UML notation and coloring scheme used throughout the CityGML Standard.

The UML diagrams presented in this standard can also be found in XML Metadata Interchange (XMI) format at https://github.com/opengeospatial/CityGML3-Workspace/tree/1.0/UML/CityGML

6.  Overview of CityGML

This Standard defines an open CityGML Conceptual Model (CM) for the storage and exchange of virtual 3D city and landscape models. These models include the most relevant entities of the urban space like buildings, roads, railways, tunnels, bridges, city furniture, water bodies, vegetation, and the terrain. The conceptual schema specifies how and into which parts and pieces physical objects of the real world should be decomposed and classified. All objects can be represented with respect to their semantics, 3D geometry, 3D topology, appearances, and their changes over time. Different spatial representations can be provided for each object (outdoor and indoor) in four predefined Levels of Detail (LOD 0-3). The CityGML 3.0 Conceptual Model (Clause 7) is formally specified using UML class diagrams, complemented by a data dictionary (Clause 8) providing the definitions and explanations of the object classes and attributes. This Conceptual Model is the basis for multiple encoding standards, which map the concepts (or subsets thereof) onto exchange formats or database structures for data exchange and storage.

While the CityGML Conceptual Model can be used for 3D visualization purposes, its special merits lie in applications that go beyond visualization such as decision support, urban and landscape planning, urban facility management, Smart Cities, navigation (both indoor and outdoor), Building Information Modeling (especially for as-built documentation), integration of city and BIM models, assisted and autonomous driving, and simulations in general (cf. Kolbe 2009). A comprehensive overview on the many different applications of virtual 3D city models is given in [Biljecki et al. 2015]. Many of the applications already use and some even require using CityGML.

In the CityGML CM, all 3D city objects can easily be enriched with thematic data. For example, street objects can be enriched with information about traffic density, speed limit, number of lanes etc., or buildings can be enriched by information on the heating and electrical energy demand, numbers of households and inhabitants, the appraised building value etc. Even building parts such as individual roof or wall surfaces can be enriched with information e.g., about solar irradiation and thermal insulation parameters. For many application domains specific extensions of the CityGML CM have already been created (cf. Biljecki et al. 2018).

6.1.  Modularization

The CityGML Conceptual Model provides models for the most important types of objects within virtual 3D city and landscape models. These feature types have been identified to be either required or important in many different application areas. However, implementations are not required to support the complete CityGML model in order to be conformant to the standard. Implementations may employ a subset of constructs according to their specific information needs. For this purpose, modularization is applied to the CityGML CM.

Figure 8 — CityGML 3.0 module overview. The vertical boxes show the different thematic modules. Horizontal modules specify concepts that are applicable to all thematic modules.

The CityGML conceptual model is thematically decomposed into a Core module and different kinds of extension modules as shown in Figure 8. The Core module (shown in green) comprises the basic concepts and components of the CityGML CM and, thus, must be implemented by any conformant system. Each red colored module covers a specific thematic field of virtual 3D city models.

The CityGML CM introduces the following eleven thematic extension modules: Building, Bridge, Tunnel, Construction, CityFurniture, CityObjectGroup, LandUse, Relief, Transportation, Vegetation, and WaterBody. All three modules Building, Bridge, and Tunnel model civil structures and share common concepts that are grouped within the Construction module. The five blue colored extension modules add specific modeling aspects that can be used in conjunction with all thematic modules.

  • The Appearance module contains the concepts to represent appearances (like textures and colors) of city objects.

  • The PointCloud module provides concepts to represent the geometry of city objects by 3D point clouds.

  • The Generics module defines the concepts for generic objects, attributes, and relationships.

  • Versioning adds concepts for the representation of concurrent versions, real world object histories and feature histories.

  • The Dynamizer module contains the concepts to represent city object properties by time series data and to link them with sensors, sensor data services or external files.

Each CityGML encoding can specify support for a subset of the CityGML modules only. If a module is supported by an encoding, then all concepts should be mapped. However, the encoding specification can define so-called null mappings to restrict the use of specific elements of the conceptual model in an encoding. Null mappings can be expressed in an encoding specification for individual feature types, properties, and associations defined within a CityGML module. This means that the corresponding element will not be included in the respective encoding.

Note that also CityGML applications do not have to support all modules. Applications can also decide to only support a specific subset of CityGML modules. For example, when an application only has to work with building data, only the modules Core, Construction, and Building would have to be supported.

6.2.  General Modeling Principles

6.2.1.  Semantic Modeling of Real-World Objects

Real-world objects are represented by geographic features according to the definition in ISO 19109. Geographic features of the same type (e.g., buildings, roads) are modeled by corresponding feature types that are represented as classes in the Conceptual Model (CM). The objects within a 3D city model are instances of the different feature types.

In order to distinguish and reference individual objects, each object has unique identifiers. In the CityGML 3.0 CM, each geographic feature has the mandatory featureID and an optional identifier property. The featureID is used to distinguish all objects and possible multiple versions of the same real-world object. The identifier is identical for all versions of the same real-world object and can be used to reference specific objects independent from their actual object version. The featureID is unique within the same CityGML dataset, but it is generally recommended to use globally unique identifiers like UUID values or identifiers maintained by an organization such as a mapping agency. Providing globally unique and stable identifiers for the identifier attribute is recommended. This means these identifiers should remain stable over the lifetime of the real-world object.

CityGML feature types typically have a number of spatial and non-spatial properties (also called attributes) as well as relationships with other feature or object types. Note that a single CityGML object can have different spatial representations at the same time. For example, different geometry objects representing the feature’s geometry in different levels of detail or as different spatial abstractions.

Many attributes have simple, scalar values like a number or a character string. However, some attributes are complex. They do not just have a single property value. In CityGML the following types of complex attributes occur.

  • Qualified attribute values: For example, a measure consists of the value and a reference to the unit of measure, or e.g., for relative and absolute height levels the reference level has to also be named.

  • Code list values: A code list is a form of enumeration where the valid values are defined in a separate register. The code list values consist of a link or identifier for the register as well as the value from that register which is being used.

  • Attributes consisting of a tuple of different fields and values: For example, addresses, space occupancy, and others.

  • Attribute value consisting of a list of numbers: For example, representing coordinate lists or matrices.

In order to support feature history, CityGML 3.0 introduces bitemporal timestamps for all objects. In CityGML 2.0, the attributes creationDate and terminationDate are supported. These refer to the time period in which a specific version of an object is an integral part of the 3D city model. In 3.0, all features can now additionally have the attributes validFrom and validTo. These represent the lifespan a specific version of an object has in the real-world. Using these two time intervals a CityGML dataset could be queried both for how did the city look alike at a specific point in time as well as how did the city model look at that time.

The combination of the two types of feature identifiers and bitemporal timestamps enables encoding not only the current version of a 3D city model, but also the model’s entire history can be represented in CityGML and possibly exchanged within a single file.

6.2.2.  Class Hierarchy and Inheritance of Properties and Relations

In CityGML, the specific feature types like Building, Tunnel, or WaterBody are defined as subclasses of more general higher-level classes. Hence, feature types build a hierarchy along specialization / generalization relationships where more specialized feature types inherit the properties and relationships of all their superclasses along the entire generalization path to the topmost feature type AnyFeature.

NOTE  A superclass is the class from which subclasses can be created.

6.2.3.  Relationships between CityGML objects

In CityGML, objects can be related to each other and different types of relations are distinguished. First of all, complex objects like buildings or transportation objects typically consist of parts. These parts are individual features of their own, and can even be further decomposed. Therefore, CityGML objects can form aggregation hierarchies. Some feature types are marked in the conceptual model with the stereotype «TopLevelFeatureType». These constitute the main objects of a city model and are typically the root of an aggregation hierarchy. Only top-level features are allowed as direct members of a city model. The information about which feature types belong to the top level is required for software packages that want to filter imports, exports, and visualizations according to the general type of a city object (e.g., only show buildings, solitary vegetation objects, and roads). CityGML Application Domain Extensions should also make use of this concept, such that software tools can learn from inspecting their conceptual schema what are the main, i.e., the top-level, feature types of the extension.

Some relations in CityGML are qualified by additional parameters, typically to further specify the type of relationship. For example, a relationship can be qualified with a URI pointing to a definition of the respective relation type in an Ontology. Qualified relationships are used in CityGML, among others, for:

  • General relationships between features – association relatedTo between city objects,

  • User-defined aggregations using CityObjectGroup. This relation allows also for recursive aggregations,

  • External references – linking of city objects with corresponding entities from external resources like objects in a cadastre or within a BIM dataset.

The CityGML CM contains many relationships that are specifically defined between certain feature types. For example, there is the boundary relationship from 3D volumetric objects to its thematically differentiated 3D boundary surfaces. Another example is the generalizesTo relation between feature instances that represent objects on different generalization levels.

In the CityGML 3.0 CM there are new associations to express topologic, geometric, and semantic relations between all kinds of city objects. For example, information that two rooms are adjacent or that one interior building installation (like a curtain rail) is overlapping with the spaces of two connected rooms can be expressed. The CM also enables documenting that two wall surfaces are parallel and two others are orthogonal. Also distances between objects can be represented explicitly using geometric relations. In addition to spatial relations logical relations can be expressed.

6.2.4.  Definition of the Semantics for all Classes, Properties, and Relations

The meanings of all elements defined in the CityGML conceptual model are normatively specified in the data dictionary in Clause 8.

6.3.  Representation of Spatial Properties

6.3.1.  Geometry and Topology

Spatial properties of all CityGML feature types are represented using the geometry classes defined in ISO 19107. Spatial representations can have 0-, 1-, 2-, or 3-dimensional extents depending on the respective feature type and Levels of Detail (LOD; the LOD concept is discussed in Clause 6.4.4 and Clause 7.2.5). With only a few exceptions, all geometries must use 3D coordinate values. Besides primitive geometries like single points, curves, surfaces, and solids, CityGML makes use of different kinds of aggregations of geometries like spatial aggregates (MultiPoint, MultiCurve, MultiSurface, MultiSolid) and composites (CompositeCurve, CompositeSurface, CompositeSolid). Volumetric shapes are represented in ISO 19107 according to the so-called Boundary Representation (B-Rep, for explanation see Foley et al. 2002) only.

The CityGML Conceptual Model does not put any restriction on the usage of specific geometry types as defined in ISO 19107. For example, 3D surfaces could be represented in a dataset using 3D polygons or 3D meshes such as triangulated irregular networks (TINS) or by non-uniform rational B-spline surfaces (NURBS). However, an encoding may restrict the usage of geometry types. For example, curved lines like B-splines or clothoids, or curved surfaces like NURBS could be disallowed by explicitly defining null encodings for these concepts in the encoding specification (c.f. Clause 6.1 above).

Note that the conceptual schema of ISO 19107 allows composite geometries to be defined by a recursive aggregation for every primitive type of the corresponding dimension. This aggregation schema allows the definition of nested aggregations (hierarchy of components). For example, a building geometry (CompositeSolid) can be composed of the house geometry (CompositeSolid) and the garage geometry (Solid), while the house’s geometry is further decomposed into the roof geometry (Solid) and the geometry of the house body (Solid). This is illustrated in Figure 9.