CityGML
CityGML is an international open standard developed and maintained by the Open Geospatial Consortium (OGC) for the representation, storage, and exchange of virtual three-dimensional (3D) city and landscape models, enabling the semantic modeling of urban objects with geometric, topological, and thematic attributes.[1] It defines a conceptual model based on Unified Modeling Language (UML) and aligned with ISO/TC 211 geographic information standards, supporting multiple Levels of Detail (LOD) from LOD0 (two-dimensional footprints) to LOD3 (highly detailed models including interiors) for scalable representations of features like buildings, transportation networks, vegetation, and water bodies.[2] The standard originated in 2008. The latest iteration, CityGML 3.0, had its conceptual model approved as an official OGC standard in September 2021, with the GML encoding part adopted in July 2023; this version introduces enhanced support for Building Information Modeling (BIM) integration, dynamic data like sensor observations, indoor navigation, point clouds, and flexible encodings beyond GML, including JSON and relational databases.[3][4] CityGML's modular structure consists of a core module for basic city model elements and 11 thematic extension modules (e.g., Building, Transportation, Land Use), allowing customization through Application Domain Extensions (ADEs) for domain-specific needs.[2] It facilitates interoperability across platforms for diverse applications, including smart city initiatives, disaster management, energy efficiency simulations, autonomous vehicle navigation, and telecommunications planning, thereby promoting cost-effective maintenance and reuse of 3D geospatial data.[1]Introduction
Definition and Scope
CityGML is an international open standard developed by the Open Geospatial Consortium (OGC) that defines a conceptual data model using Unified Modeling Language (UML) and an exchange format primarily based on Geography Markup Language (GML), which is XML-based, for storing and representing virtual 3D models of cities, buildings, landscapes, and regional environments.[2] It provides a conceptual framework through a Unified Modeling Language (UML) object model, independent of specific implementation technologies, to ensure interoperability in geospatial data handling.[2] The scope of CityGML encompasses the modeling of semantic, geometric, topological, and thematic information for various city objects, including buildings, roads, vegetation, terrain, water bodies, and city furniture.[2] Semantic aspects classify objects and their attributes, such as building usage or vegetation species; geometric representations support multi-dimensional primitives from points to solids; topological structures enable explicit relationships like adjacency; and thematic details allow for application-specific properties, such as energy consumption or traffic functions.[2] This comprehensive coverage facilitates the integration of 3D urban data for diverse analyses. The primary objectives of CityGML are to enable consistent, interoperable representations of 3D urban features that support analysis, simulation, visualization, urban planning, and disaster management across heterogeneous applications and systems.[2] By standardizing data exchange, it promotes cost-effective maintenance of semantic 3D city models and fosters reuse in fields like environmental simulation and infrastructure management.[2] CityGML is built upon the Geography Markup Language (GML 3.1.1 or later) for its foundational encoding and the ISO 19100 series standards, including ISO 19107 for spatial schema and ISO 19109 for rules for application schema, to handle geometry, features, and spatiotemporal aspects.[2][5] It incorporates mechanisms such as Levels of Detail (LODs) for varying model complexity and Application Domain Extensions (ADEs) for domain-specific customizations.[2]Key Features
CityGML enables rich 3D urban modeling through its semantic modeling capabilities, which employ a hierarchical class structure for city objects. For instance, the abstract class AbstractCityObject serves as the superclass for specific subclasses like Building, allowing the representation of thematic attributes such as function, usage, and relationships between objects.[2] This structure supports the attachment of complex attributes, including qualified values, code lists, and tuples, to capture detailed semantic information about urban features.[6] In version 3.0, the standard supports flexible encodings beyond GML, including JSON and relational databases, and refines the LOD concept to LOD0-3 with integrated support for interior features.[4] The standard's geometric primitives provide robust support for 3D vector data, drawing directly from ISO 19107 to include points, curves, surfaces, solids, and composite geometries like MultiSurface and CompositeSolid.[2] These primitives use 3D coordinates within a specified coordinate reference system (CRS), enabling precise spatial representations of city objects such as buildings and terrain.[6] Aggregations and implicit geometries further allow for efficient modeling of prototypical shapes without redundant data.[2] Topological relationships in CityGML facilitate explicit connections between adjacent objects, such as boundary surfaces linking rooms within a building or shared geometries between solids and surfaces.[2] This feature promotes data consistency by enabling geometry sharing, which expresses adjacency and other spatial interdependencies while reducing redundancy.[6] Optional topological constraints can be enforced in encodings to maintain relational integrity across urban models.[2] Appearance modeling enhances visual rendering by supporting textures, materials, and colors applied to surfaces, often organized by themes like infrared or noise pollution.[6] These attributes are defined per level of detail (LOD) through the Appearance module, integrating standards such as X3D and COLLADA for realistic depictions.[2] Multi-representation allows CityGML to store multiple instances of the same object at varying scales or details, supporting scalability via levels of detail (LODs).[6] This capability, combined with encoding in Geography Markup Language (GML) for interoperable data exchange, ensures flexible urban modeling adaptable to diverse applications.[2]Development and Standardization
Historical Background
The development of CityGML originated in Germany in 2002, initiated by the Special Interest Group 3D (SIG3D) within the Geodata Infrastructure North-Rhine Westphalia (GDI NRW) initiative, aiming to create a standardized model for representing 3D city and landscape features.[5] By 2005, this effort had garnered consensus from over 70 institutions, companies, municipalities, and national mapping agencies, primarily German research entities such as the Karlsruhe Institute of Technology and the University of Bonn, focusing on semantic and geometric modeling building on the Geography Markup Language (GML).[7] The need for interoperable 3D city models arose from demands in urban planning, environmental simulations, and disaster management, where existing formats lacked sufficient semantic depth for multi-scale analysis.[8] A pivotal European harmonization effort began in December 2005 through the EuroSDR CityGML project, which sought to align the German prototype with broader INSPIRE directive goals for geospatial data interoperability across Europe.[9] This led to the release of prototype version 0.4 in May 2007, which introduced the Application Domain Extension (ADE) mechanism to allow domain-specific customizations while maintaining core compatibility.[10] The standardization process culminated in August 2008 when CityGML version 1.0 was adopted as an Open Geospatial Consortium (OGC) standard, marking its transition from a national prototype to an international encoding format. Concurrently, the formation of the CityGML working group within OGC fostered community growth, enabling widespread adoption in global spatial data infrastructures.[11] Subsequent versions, such as 2.0 and 3.0, have extended the standard under OGC's ongoing maintenance.[2]Governing Organizations and Standards Process
The Open Geospatial Consortium (OGC) acts as the primary governing organization for CityGML, serving as its steward by defining the conceptual model and exchange format for virtual 3D city models while ensuring interoperability through open standards. The CityGML Standards Working Group (SWG), comprising OGC members, oversees the standard's revisions and advancements, including the development of new encodings and modules to address evolving requirements in urban modeling.[12] Collaborative contributions come from key partners such as the Technical University of Munich (TU Munich), where researchers like Prof. Thomas H. Kolbe have driven core developments, and virtualcitySYSTEMS, whose experts, including co-chair Claus Nagel, have shaped SWG activities.[13][14] International alignment is facilitated through bodies like ISO Technical Committee 211 (ISO/TC 211), which integrates CityGML's UML model with foundational geospatial standards for spatial and temporal data.[2] The OGC standardization process follows a consensus-driven cycle that includes requests for technology, formation of SWGs for drafting, interoperability experiments to test implementations, public reviews for feedback, and final adoption via voting by the OGC Technical Committee and Planning Committee.[15] For example, CityGML 1.0 was approved as an official standard through this Technical Committee process in 2008.[16] This structured approach ensures broad stakeholder input and technical rigor, with SWGs resolving issues through discussions and iterative refinements.[17] Maintenance of CityGML involves ongoing submission and processing of change requests by the SWG, allowing for targeted updates to address gaps or enhancements identified by the community.[18] Conformance to the standard is verified through the OGC Compliance Program, which provides executable test suites—such as those for CityGML 3.0 GML encoding—to certify implementations and promote reliable data exchange.[19][20] CityGML's governance emphasizes global harmonization, including compatibility with the European INSPIRE directive for 3D building representations in spatial data infrastructures.[21] It also aligns with United Nations Global Geospatial Information Management (UN GGIM) initiatives, where it is recommended for core themes like buildings to support standardized 3D geospatial data worldwide.[22]Conceptual Model
Core Components
CityGML's conceptual model is formalized using the Unified Modeling Language (UML) to define an abstract structure of classes, associations, and attributes, drawing on the ISO 19100 series standards for geographic information modeling.[2] This UML-based approach establishes a standardized framework for representing 3D urban and landscape features, ensuring interoperability across applications while allowing for semantic enrichment.[2] At the heart of the model is the abstract superclass AbstractCityObject, which serves as the base for all city features and inherits properties from GML's AbstractFeature.[2] This superclass provides essential generic attributes, including a unique identifier (gml:id), human-readable names (gml:name), bitemporal timestamps for versioning, including transaction time attributes (creationDate and terminationDate) for database changes and valid time attributes (validFrom and validTo) for real-world validity, and classification codes (class). It also supports dynamic data through the dynamizer association to AbstractDynamizer elements for integrating time-varying information like sensor readings.[2] It also supports functional and usage descriptors (function and usage) to categorize objects semantically, enabling flexible representation of urban elements without prescribing specific geometries.[2] The core model includes key thematic classes that inherit from AbstractCityObject, each tailored to represent fundamental urban components. For instance, the Building class models architectural structures, featuring subclasses such as BuildingPart for modular components and boundary surface types like GroundSurface and RoofSurface to delineate external interfaces.[2] The LandUse class captures areas defined by their utilization, such as residential or commercial zones, with attributes for thematic classification.[2] Similarly, the Relief class, through subclasses like ReliefFeature, represents terrain and elevation data, supporting components such as triangulated irregular networks (TIN) for accurate topographic modeling.[2] These classes emphasize semantic relationships over geometric detail, allowing integration with broader environmental contexts. Relationships among core classes are articulated through UML associations, promoting a hierarchical and compositional structure. Generalization hierarchies enable inheritance, where specific classes like Building derive properties from more abstract ones such as AbstractSpace.[2] Aggregation links wholes to parts, as seen in a Building aggregating multiple BuildingPart instances via associations like consistsOfBuildingPart.[2] Composition defines tighter bindings, such as a Building being delimited by BoundarySurface elements through the boundedBy association, ensuring spatial coherence.[2] These mechanisms facilitate complex urban assemblies while maintaining data integrity. Metadata support in the core model enhances interoperability and extensibility through dedicated elements. The ExternalReference class allows city objects to link to external datasets or systems via URIs or identifiers, such as referencing cadastral records.[2] Generic attributes, including string, integer, and double value types under classes like _GenericApplicationPropertyOfAbstractCityObject, permit the addition of custom properties without altering the base schema.[2] This design accommodates evolving requirements, such as provenance tracking or domain-specific annotations, while preserving the model's foundational semantics.[2]Levels of Detail
CityGML employs a multi-level of detail (LOD) system to represent urban objects with varying degrees of geometric and semantic complexity, enabling efficient modeling for different scales and applications. This progressive LOD framework, defined in the standard's core conceptual model, allows a single feature—such as a building—to maintain multiple representations simultaneously, from coarse regional overviews to detailed architectural views, thereby optimizing data storage, processing, and visualization based on user needs.[2][23] In CityGML version 2.0, five LODs (0 through 4) are specified, whereas version 3.0 refines this to four LODs (0 through 3), with interior modeling integrated across lower levels rather than isolated in a separate highest tier. LOD0 provides the most generalized representation, typically as a 2.5D footprint or multi-surface polygon depicting city blocks or building outlines projected onto a terrain model, suitable for large-scale regional planning.[6][23] For example, LOD0 might represent an entire urban district as simple polygons with an accuracy of up to 5 meters.[23] LOD1 advances to basic 3D block models formed by extruding LOD0 footprints to a uniform height, creating prismatic solids without detailed facades or roofs, ideal for city-wide simulations like solar potential analysis.[2] This level uses solid or multi-surface geometries with similar accuracy to LOD0 but adds volumetric representation, as seen in models of urban blocks with flat roofs.[23] At LOD2, models incorporate generalized 3D solids or multi-surfaces with differentiated roof structures and simplified wall facades, omitting fine details like balconies for efficiency in district-level applications such as visibility analysis.[6] Accuracy improves to about 2 meters, enabling textures on surfaces for enhanced rendering, exemplified by buildings with detailed eaves and gables but smoothed walls.[23] LOD3 offers high-fidelity modeling of both exteriors and interiors through multi-surfaces or solids that include architectural elements like windows, doors, ornaments, rooms, and furniture, supporting applications in urban design, heritage preservation, and indoor navigation with sub-meter accuracy (around 0.5 meters).[2] This level captures openings, thematic surfaces such as textured facades, and internal structures on individual buildings.[23] Exclusive to CityGML 2.0, LOD4 extends to interior spaces with detailed solids representing rooms, furniture, and installations, facilitating indoor navigation and facility management at an accuracy of 0.2 meters or better.[23] In version 3.0, such interior details are distributed across LOD0-3 to promote unified multi-scale representations.[6] The LOD system supports implicit geometry for reuse of prototypical shapes via transformation matrices, reducing redundancy in complex models, and allows selection of appropriate levels per application—e.g., LOD1 for broad simulations or LOD3 for detailed inspections—while core classes like Building instantiate these representations.[2][23]| LOD | Version | Geometric Representation | Typical Accuracy | Example Use Case |
|---|---|---|---|---|
| 0 | 2.0 & 3.0 | Footprint/multi-surface (2.5D) | ≤5 m | Regional planning |
| 1 | 2.0 & 3.0 | Extruded solid/block model | ≤5 m | City simulations |
| 2 | 2.0 & 3.0 | Multi-surface/solid with roofs/facades | ≤2 m | District analysis |
| 3 | 2.0 & 3.0 | Detailed multi-surface/solid with architectural and interior features | ≤0.5 m | Urban design, indoor navigation |
| 4 | 2.0 only | Interior solids (rooms/furniture) | ≤0.2 m | Indoor navigation |
Modules and Extensions
Thematic Modules
Thematic modules in CityGML represent optional extension packages that build upon the core model to incorporate domain-specific features for urban environments, enabling detailed representation of specialized city elements without modifying the foundational structure.[2] The 11 thematic modules are: Building, Bridge, Tunnel, Construction, CityFurniture, CityObjectGroup, LandUse, Relief, Transportation, Vegetation, and WaterBody.[2] These modules introduce dedicated classes and attributes tailored to particular themes, such as infrastructure or natural features, while maintaining interoperability through inheritance from the core's AbstractCityObject class.[6] By doing so, they facilitate advanced semantic modeling, where city objects can be queried and analyzed for specific applications like traffic simulation or environmental assessment.[2] The architecture of thematic modules emphasizes modularity, with each package defining classes that extend the core's concepts of geometry, topology, and semantics across multiple levels of detail (LOD 0 to 4).[6] For instance, the Building module decomposes structures into components like roofs, walls, and openings, allowing for precise geometric and functional descriptions.[2] Similarly, other modules add thematic surfaces, volumes, and relationships to capture real-world complexities, such as spatial adjacencies or functional classifications, all while adhering to the core's inheritance hierarchy.[6] Key thematic modules include Transportation, which models linear features like roads, railways, and waterways using graph-based structures and traffic elements such as lanes and markings, complete with attributes for direction and class.[2] The Vegetation module represents individual plants or area covers, incorporating attributes like species, height, and trunk diameter to support ecological analyses.[6] WaterBody addresses aquatic features, defining classes for surfaces, grounds, and volumes, including attributes such as water level classification via code lists, essential for hydrology modeling. Dynamic data, such as time-varying water levels, can be incorporated using the Dynamizer module.[2] Bridge and Tunnel modules focus on civil engineering elements, detailing structural components such as decks, abutments, and portals, with attributes for load-bearing functions and construction materials.[6] An illustrative example is the Relief module, which integrates digital elevation models through representations like Triangulated Irregular Networks (TINs), breaklines, and raster grids, providing terrain data that interacts with other modules for elevation-aware simulations.[2] Integration across modules occurs primarily through inheritance from the CityObject base class, which supplies common attributes like identifiers, classifications, and external references, while adding theme-specific properties such as function codes (e.g., road usage types) and relationships (e.g., adjacency between transportation segments).[6] This design ensures seamless composition of city models, where, for example, a bridge in the Bridge module can reference terrain from the Relief module or vegetation along a road.[2] The primary purpose of these modules is to support specialized queries and analyses—such as routing optimizations in transportation or biodiversity assessments in vegetation—while preserving the core model's generality for broad urban data exchange.[6]Application Domain Extensions
Application Domain Extensions (ADEs) in CityGML provide a standardized mechanism for customizing the core data model to accommodate domain-specific requirements, enabling the addition of new feature classes, attributes, properties, or relationships while ensuring compatibility with the existing semantic structure.[10] This extensibility allows users to tailor CityGML for specialized applications without altering the foundational modules, thereby maintaining interoperability across systems.[2] The ADE concept was first introduced in CityGML version 0.4, released in May 2007, and has since evolved to support enhanced flexibility in subsequent versions, including formalization in version 1.0 to promote broader adoption and data exchange.[24] The development process for an ADE begins with extending the Unified Modeling Language (UML) conceptual model of CityGML, where application-specific elements are integrated into existing classes or hierarchies.[25] These UML extensions are then used to generate corresponding Geography Markup Language (GML) schemas, which define the XML structure for encoding the additional data.[24] For instance, the Energy ADE extends building and city object classes with attributes related to thermal properties, energy consumption, and efficiency metrics to support urban energy simulations.[26] Notable examples of ADEs include the Indoor ADE, which adds navigation-relevant features like room connectivity and accessibility for indoor mapping applications, and the Noise ADE, which incorporates acoustic properties and simulation parameters for environmental noise modeling.[10] As of 2018, a survey identified 44 ADEs addressing diverse domains such as public safety, utilities, and cultural heritage. Additional ADEs have been developed since, with ongoing publications.[10][27] ADEs offer significant benefits by preserving the core semantics and validation capabilities of CityGML, facilitating seamless integration with thematic modules for applications like energy planning.[2] However, their implementation imposes constraints, as effective use requires software tools capable of parsing and validating the extended schemas, which may limit adoption without dedicated support.[24] To enhance discoverability and reuse, the CityGML community maintains a catalog of published ADEs on the CityGML Wiki, including schemas and documentation.[28]Encoding and Formats
Data Encoding Standards
CityGML 3.0 data is primarily encoded using the Geography Markup Language (GML) version 3.2.1, an XML-based standard developed by the Open Geospatial Consortium (OGC) for the transport and storage of geographic information.[29] This encoding adheres to ISO 19136 and utilizes XML Schema Definition (XSD) files to define and validate the structure of CityGML documents, ensuring consistency and interoperability across systems.[30] The GML format realizes the abstract conceptual model of CityGML through XML elements that represent core classes, such as CityObjects, with spatial aspects integrated via GML's geometry primitives.[30] In the GML encoding, the document is structured around a root element called CityModel, which serves as a container for feature members denoted as cityObjectMember.[30] These members encapsulate individual CityObjects, including their attributes, relationships, and geometries defined within the gml: namespace.[30] Geometries are typically encoded explicitly, for instance, using gml:LinearRing to specify boundaries of surfaces or solids, while implicit encoding is supported through XLink references to shared prototypes or reusable components within the same document.[30] Compliance with OGC standards is mandatory, promoting seamless data exchange, and the encoding supports coordinate reference systems such as EPSG:4326 for geospatial positioning.[29] Additionally, GML files can be compressed using GZIP to manage file sizes effectively in practical applications.[31] For CityGML version 3.0, an alternative encoding standard is CityJSON, a JSON-based format adopted by the OGC as a lighter and more web-friendly option for serializing and exchanging 3D city models.[32] CityJSON implements a subset of the CityGML 3.0 data model, featuring a top-level JSON object with required members like "type", "version", "CityObjects", and "vertices" for storing transformed coordinate data.[33] This structure enables explicit geometry encoding through arrays of vertex indices, while implicit reuse is facilitated via geometry templates that reference shared definitions, reducing redundancy in large datasets.[33] Compared to GML, CityJSON files are typically six times more compact, making them suitable for web services and rapid processing.[32] CityGML 3.0 also supports other encodings, such as relational database schemas, for direct storage and querying without XML or JSON serialization.[3]File Structure and Schemas
CityGML files in XML format follow a hierarchical structure rooted in the<CityModel> element, which serves as the top-level container for all city objects and metadata within a document. This root element, defined in the core schema, encapsulates one or more <cityObjectMember> elements, each representing an instance of a city object such as a building, bridge, or terrain feature. These city objects can nest additional components, including <boundarySurfaceMember> elements that define spatial boundaries like walls or roofs, ensuring a modular representation of complex urban geometries. For instance, a building object might include nested surfaces to delineate its exterior and interior partitions, with geometries encoded using GML primitives at specified levels of detail.[30]
The XML schemas for CityGML are organized into a core schema (core.xsd) and module-specific schemas, such as building.xsd for architectural features or transportation.xsd for infrastructure. The core schema provides foundational types like AbstractCityObjectType and imports GML schemas for geometric and topological elements, while module schemas extend these via XML namespaces (e.g., core: for core elements and bldg: for building-specific ones) to prevent conflicts and enable selective inclusion. Schemas are imported using <xs:import> declarations, allowing documents to reference only required modules, which promotes efficiency in large-scale urban models.[34][30]
Validation of CityGML files relies on XML Schema Definition (XSD) files to enforce structural integrity, including type checking for elements and attributes as well as cardinality constraints like minOccurs="1" for required components (e.g., ensuring each space boundary has at least one surface) and maxOccurs="unbounded" for repeatable features like multiple appearances. Tools such as XML validators can parse the document against the combined schemas to detect errors in hierarchy or data types, guaranteeing conformance to the standard.[30]
Application Domain Extensions (ADEs) are integrated through substitution groups in the schemas, such as ADEOfAbstractCityObject, which allow custom elements to replace standard ones without altering the core structure—for example, extending a building schema with energy-related properties via a dedicated ADE namespace. Best practices include using unique namespaces for all imported modules to avoid prefix collisions, explicitly declaring the coordinate reference system (CRS) in the root element, and incorporating <boundedBy> metadata with gml:Envelope to define the spatial extent of the entire model, facilitating efficient querying and rendering.[30]
[30]xml<CityModel xmlns="http://www.opengis.net/citygml/3.0" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:bldg="http://www.opengis.net/citygml/building/3.0"> <boundedBy> <Envelope srsName="EPSG:4326"> <lowerCorner>48.1 11.5</lowerCorner> <upperCorner>48.2 11.6</upperCorner> </Envelope> </boundedBy> <cityObjectMember> <bldg:Building gml:id="bldg_001"> <!-- Nested boundary surfaces and geometries --> <boundarySurfaceMember> <bldg:WallSurface gml:id="wall_001"> <!-- Geometry and attributes --> </bldg:WallSurface> </boundarySurfaceMember> </bldg:Building> </cityObjectMember> </CityModel><CityModel xmlns="http://www.opengis.net/citygml/3.0" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:bldg="http://www.opengis.net/citygml/building/3.0"> <boundedBy> <Envelope srsName="EPSG:4326"> <lowerCorner>48.1 11.5</lowerCorner> <upperCorner>48.2 11.6</upperCorner> </Envelope> </boundedBy> <cityObjectMember> <bldg:Building gml:id="bldg_001"> <!-- Nested boundary surfaces and geometries --> <boundarySurfaceMember> <bldg:WallSurface gml:id="wall_001"> <!-- Geometry and attributes --> </bldg:WallSurface> </boundarySurfaceMember> </bldg:Building> </cityObjectMember> </CityModel>