The CityGML standard is presented in this document in 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 below ().

UML notation (see ISO TS 19103, Geographic information - Conceptual schema language).

According to GML3 all associations between model elements in CityGML are uni-directional. Thus, associations in CityGML 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:

<<Geometry>> represents the geometry of an object. The geometry is an identifiable and distinguishable object that is derived from the abstract GML type AbstractGeometryType.

<<Feature>> represents a thematic feature according to the definition in ISO 19109. A feature is an identifiable and distinguishable object that is derived from the abstract GML type AbstractFeatureType.

<<Object>> represents an identifiable and distinguishable object that is derived from the abstract GML type AbstractGMLType.

<<Enumeration>> enumerates the valid attribute values in a fixed list of named literal values. Enumerations are specified inline the CityGML schema.

<<CodeList>> enumerates the valid attribute values. In contrast to Enumeration, the list of values is open and, thus, not given inline the CityGML schema. The allowed values can be provided within an external code list. It is recommended that code lists are implemented as simple dictionaries following the GML 3.1.1 Simple Dictionary Profile (cf. and ).

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

<<PrimitiveType>> is used for representations supported by a primitive type in the implementation.

<<DataType>> is used as a descriptor of a set of values that lack identity. Data types include primitive predefined types and user-definable types. A DataType is thus a class with few or no operations whose primary purpose is to hold the abstract state of another class for transmittal, storage, encoding or persistent storage.

<<Leaf>> is used within UML package diagrams to indicate model elements that can have no further subtypes.

<<XSDSchema>> is used within UML package diagrams to denote the root element of an XSD Schema containing all the definitions for a particular namespace. All the package contents or component classes are placed within the one schema.

<<ApplicationSchema>> is used within UML package diagrams to denote an XML Schema definition fundamentally dependent on the concepts of another independent Standard within the XML Schema metalanguage. For example, ApplicationSchema indicates extensions of GML consistent with the GML “rules for application schemas”.

In order to enhance the readability of the CityGML UML diagrams, classes are depicted in different colors if they belong to different UML packages (see for an overview of UML packages). The following coloring scheme is applied:

• Classes painted in yellow belong to the UML package which is subject of discussion in that clause of the specification in which the UML diagram is given. For example, in the context of which introduces the CityGML Core module, the yellow color is used to denote classes which are defined in the CityGML Core UML package. Likewise, the yellow classes shown in UML diagrams in are associated with the Building module which is subject of discussion in that chapter.

• Classes painted in blue belong to a CityGML UML package different to that associated with the yellow color. In order to explicitly denote the UML package of such classes, their class names carry a namespace prefix which is uniquely associated with a CityGML module throughout this specification (cf. section 4.3 for a list of namespaces and prefixes). For example, in the context of the Building module, classes from the CityGML Core module are painted in blue and their class names are preceded by the prefix core. * Classes painted in green are defined in GML3 and their class names are preceded by the prefix gml.

The following example UML diagram demonstrates the UML notation and coloring scheme used throughout this specification. In this example, the yellow classes are associated with the CityGML Building module, the blue classes are from the CityGML Core module, and the green class depicts a geometry element defined by GML3.

Example UML diagram demonstrating the UML notation and coloring scheme used throughout the CityGML specification.

The CityGML data model is thematically decomposed into a core module and thematic extension modules. All modules including the core are specified by their own XML schema file, each defining a globally unique XML namespace. The extension modules are based on the core module and, thus, contain (by reference) the CityGML core schema.

Within this document the module namespaces are associated with recommended prefixes. These prefixes are consistently used within the normative parts of this specification, for all UML diagrams and example CityGML instance documents. The CityGML core and extension modules along with their XML namespace identifiers and recommended namespace prefixes are listed in .

Further XML Schema definitions relevant to this standard are shown in along with the corresponding XML namespace identifiers and namespace prefixes consistently used within this document.

The normative parts of the standard use the W3C XML schema language to describe the grammar of conformant CityGML data instances. XML schema is a rich language with many capabilities. While a reader who is unfamiliar with an XML schema may be able to follow the description in a general fashion, this standard is not intended to serve as an introduction to XML schema. In order to have a full understanding of this candidate standard, it is necessary for the reader to have a reasonable knowledge of XML schema.

The CityGML data model consists of class definitions for the most important types of objects within virtual 3D city models. These classes have been identified to be either required or important in many different application areas. However, implementations are not required to support the overall CityGML data model in order to be conformant to the standard, but may employ a subset of constructs according to their specific information needs. For this purpose, modularisation is applied to the CityGML data model (cf. ).

The CityGML data model is thematically decomposed into a core module and thematic extension modules. The core module comprises the basic concepts and components of the CityGML data model and, thus, must be implemented by any conformant system. Based on the core module, each extension covers a specific thematic field of virtual 3D city models. CityGML introduces the following thirteen thematic extension modules: Appearance, Bridge, Building, CityFurniture, CityObjectGroup, Generics, LandUse, Relief, Transportation, Tunnel, Vegetation, WaterBody, and TexturedSurface [deprecated].

CityGML compliant implementations may support any combination of extension modules in conjunction with the core module. Such combinations of modules are called CityGML profiles. Therefore, CityGML profiles allow for valid partial implementations of the overall CityGML data model.

CityGML supports different Levels of Detail (LOD). LODs are required to reflect independent data collection processes with differing application requirements. Further, LODs facilitate efficient visualisation and data analysis (see ). In a CityGML dataset, the same object may be represented in different LOD simultaneously, enabling the analysis and visualisation of the same object with regard to different degrees of resolution. Furthermore, two CityGML data sets containing the same object in different LOD may be combined and integrated. However, it will be within the responsibility of the user or application to make sure objects in different LODs refer to the same real-world object.

The coarsest level LOD0 is essentially a two and a half dimensional Digital Terrain Model over which an aerial image or a map may be draped. Buildings may be represented in LOD0 by footprint or roof edge polygons. LOD1 is the well-known blocks model comprising prismatic buildings with flat roof structures. In contrast, a building in LOD2 has differentiated roof structures and thematically differentiated boundary surfaces. LOD3 denotes architectural models with detailed wall and roof structures potentially including doors and windows. LOD4 completes a LOD3 model by adding interior structures for buildings. For example, buildings in LOD4 are composed of rooms, interior doors, stairs, and furniture. In all LODs appearance information such as high-resolution textures can be mapped onto the structures (cf. ).

The five levels of detail (LOD) defined by CityGML (source: IGG Uni Bonn)

LODs are also characterised by differing accuracies and minimal dimensions of objects (cf. ). The accuracy requirements given in this standard are debatable and are to be considered as discussion proposals. Accuracy is described as standard deviation $\sigma$sigma of the absolute 3D point coordinates. Relative 3D point accuracy will be added in a future version of CityGML and it is typically much higher than the absolute accuracy. In LOD1, the positional and height accuracy of points should be 5m or less, while all objects with a footprint of at least 6m by 6m should be considered. The positional and height accuracy of LOD2 is proposed to be 2m or better. In this LOD, all objects with a footprint of at least 4m × 4m should be considered. Both types of accuracies in LOD3 should be 0.5m, and the minimal footprint is suggested to be 2m × 2m. Finally, the positional and height accuracy of LOD4 should be 0.2m or less. By means of these figures, the classification in five LOD may be used to assess the quality of 3D city model datasets. The LOD categorisation makes datasets comparable and provides support for their integration.

Whereas in CityGML each object can have a different representation for every LOD, often different objects from the same LOD will be generalised to be represented by an aggregate object in a lower LOD. CityGML supports the aggregation / decomposition by providing an explicit generalisation association between city objects(further details see UML diagram in ).

One of the most important design principles for CityGML is the coherent modelling of semantics and geometrical/topological properties. At the semantic level, real-world entities are represented by features, such as buildings, walls, windows, or rooms. The description also includes attributes, relations and aggregation hierarchies (part-whole-relations) between features. Thus the part-of-relationship between features can be derived at the semantic level only, without considering geometry. However, at the spatial level, geometry objects are assigned to features representing their spatial location and extent. So the model consists of two hierarchies: the semantic and the geometrical in which the corresponding objects are linked by relationships (cf. Stadler & Kolbe 2007). The advantage of this approach is that it can be navigated in both hierarchies and between both hierarchies arbitrarily, for answering thematic and/or geometrical queries or performing analyses.

If both hierarchies exist for a specific object, they must be coherent (i.e. it must be ensured that they match and fit together). For example, if a wall of a building has two windows and a door on the semantic level, then the geometry representing the wall must contain also the geometry parts of both windows and the door.

Objects, which are not modelled by a volumetric geometry, must be virtually closed in order to compute their volume (e.g. pedestrian underpasses or airplane hangars). They can be sealed using a ClosureSurface. These are special surfaces, which are taken into account, when needed to compute volumes and are neglected, when they are irrelevant or not appropriate, for example in visualisations.

The concept of ClosureSurface is also employed to model the entrances of subsurfaceobjects. Those objects like tunnels or pedestrian underpasses have to be modelled as closed solids in order to compute their volume, for example in flood simulations. The entrances to subsurface objects also have to be sealed to avoid holes in the digital terrain model (see ). However, in close-range visualisations the entrance must be treated as open. Thus, closure surfaces are an adequate way to model those entrances.

Closure surfaces to seal open structures. (graphic: IGG Uni Bonn).

Passages are subsurface objects

The entrance is sealed by a virtual ClosureSurface, which is both part of the DTM and the subsurface object

A crucial issue in city modelling is the integration of 3D objects and the terrain. Problems arise if 3D objects float over or sink into the terrain. This is particularly the case if terrains and 3D objects in different LOD are combined, or if they come from different providers (Kolbe and Gröger 2003). To overcome this problem, the TerrainIntersectionCurve (TIC) of a 3D object is introduced. These curves denote the exact position, where the terrain touches the 3D object (see ). TICs can be applied to buildings and building parts (cf. ), bridge, bridge parts and bridge construction elements (cf. ), tunnel and tunnel parts (cf. ), city furniture objects (cf. ), and generic city objects (cf. ). If, for example, a building has a courtyard, the TIC consists of two closed rings: one ring representing the courtyard boundary, and one which describes the building’s outer boundary. This information can be used to integrate the building and a terrain by ‘pulling up’ or ‘pulling down’ the surrounding terrain to fit the TerrainIntersectionCurve. The DTM may be locally warped to fit the TIC. By this means, the TIC also ensures the correct positioning of textures or the matching of object textures with the DTM. Since the intersection with the terrain may differ depending on the LOD, a 3D object may have different TerrainIntersectionCurves for all LOD.

TerrainIntersectionCurve (graphic: IGG Uni Bonn).

TerrainIntersectionCurve for a building

TerrainIntersectionCurve for a tunnel object. The tunnel’s hollow space is sealed by a triangulated ClosureSurface

CityGML feature types often include attributes whose values can be enumerated in a list of discrete values. An example is the attribute roof type of a building, whose attribute values typically are saddle back roof, hip roof, semi-hip roof, flat roof, pent roof, or tent roof. If such an attribute is typed as string, misspellings or different names for the same notion obstruct interoperability. Moreover, the list of possible attribute values often is not fixed and may substantially vary for different countries (e.g., due to national law and regulations) and for different information communities.

In CityGML, such enumerative attributes are of type gml:CodeType and their allowed attribute values can be provided in a code list which is specified outside the CityGML schema. A code list contains coded attribute values and ensures that the same code is used for the same notion or concept. If a code list is provided for an enumerative attribute, the attribute may only take values from this list. This allows applications to validate the attribute value and thus facilitates semantic and syntactic interoperability. It is recommended that code lists are implemented as simple dictionaries following the GML 3.1.1 Simple Dictionary Profile (cf. Whiteside 2005).

The governance of code lists is decoupled from the governance of the CityGML schema and specification. Thus, code lists may be specified by any organisation or information community according to their information needs. There shall be one authority per code list who is in charge of the code list values and the maintenance of the code list. Further information on the CityGML code list mechanism is provided in .

Code lists can have references to existing models. For example, room codes defined by the Open Standards Consortium for Real Estate (OSCRE) can be referenced or classifications of buildings and building parts introduced by the National Building Information Model Standard (NBIMS) can be used. contains non-normative code lists proposed by the SIG 3D for almost all enumerative attributes in CityGML. They can be directly referenced in CityGML instance documents and serve as an example for the definition of code lists.

3D objects are often derived from or have relations to objects in other databases or data sets. For example, a 3D building model may have been constructed from a two-dimensional footprint in a cadastre data set, or may be derived from an architectural model (). The reference of a 3D object to its corresponding object in an external data set is essential, if an update must be propagated or if additional data is required, for example the name and address of a building’s owner in a cadastral information system or information on antennas and doors in a facility management system. In order to supply such information, each _CityObject may refer to external data sets (for the UML diagram see ; and for XML schema definition see ) using the concept of ExternalReference. Such a reference denotes the external information system and the unique identifier of the object in this system. Both are specified as a Uniform Resource Identifier (URI), which is a generic format for references to any kind of resources on the internet. The generic concept of external references allows for any _CityObject an arbitrary number of links to corresponding objects in external information systems (e.g. ALKIS, ATKIS, OS MasterMap^®, GDF, etc.).

External references (graphic: IGG Uni Bonn).

The grouping concept of CityGML allows for the aggregation of arbitrary city objects according to user-defined criteria, and to represent and transfer these aggregations as part of a city model (for the UML diagram see ; XML schema definition see ). A group may be assigned one or more names and may be further classified by specific attributes, for example, “escape route from room no. 43 in house no. 1212 in a fire scenario” as a name and ”escape route” as type. Each member of the group can optionally be assigned a role name, which specifies the role this particular member plays in the group. This role name may, for example, describe the sequence number of this object in an escape route, or in the case of a building complex, denote the main building.

A group may contain other groups as members, allowing nested grouping of arbitrary depth. The grouping concept is delivered by the thematic extension module CityObjectGroup of CityGML (cf. ).

Information about a surface’s appearance, i.e. observable properties of the surface, is considered an integral part of virtual 3D city models in addition to semantics and geometry. Appearance relates to any surface-based theme, e.g. infrared radiation or noise pollution, not just visual properties. Consequently, data provided by appearances can be used as input for both presentation of and analysis in virtual 3D city models.

CityGML supports feature appearances for an arbitrary number of themes per city model. Each LOD of a feature can have an individual appearance. Appearances can represent — among others — textures and georeferenced textures. CityGML’s appearance model is packaged within its own extension module Appearance (cf. ).

In CityGML, objects of equal shape like trees and other vegetation objects, traffic lights and traffic signs can be represented as prototypes which are instantiated multiple times at different locations (). The geometry of prototypes is defined in local coordinate systems. Every instance is represented by a reference to the prototype, a base point in the world coordinate reference system and a transformation matrix that facilitates scaling, rotation, and translation of the prototype. The principle is adopted from the concept of scene graphs used in computer graphics standards like VRML and X3D. As the GML3 geometry model does not provide support for scene graph concepts, it is implemented as an extension to the GML3 geometry model (for further description cf. ).

Examples of prototypic shapes (source: Rheinmetall Defence Electronics).

CityGML is being designed as a universal topographic information model that defines object types and attributes which are useful for a broad range of applications. In practical applications the objects within specific 3D city models will most likely contain attributes which are not explicitly modelled in CityGML. Moreover, there might be 3D objects which are not covered by the thematic classes of CityGML. CityGML provides two different concepts to support the exchange of such data: 1) generic objects and attributes, and 2) Application Domain Extensions (cf. ).

The concept of generic objects and attributes allows for the extension of CityGML applications during runtime, i.e. any _CityObject may be augmented by additional attributes, whose names, data types, and values can be provided by a running application without any change of the CityGML XML schema. Similarly, features not represented by the predefined thematic classes of the CityGML data model may be modelled and exchanged using generic objects. The generic extensions of CityGML are provided by the thematic extension module Generics (cf. ).

The current version of CityGML does not include, for example, explicit thematic models for embankments, excavations and city walls. These objects may be stored or exchanged using generic objects and attributes.

Application Domain Extensions (ADE) specify additions to the CityGML data model. Such additions comprise the introduction of new properties to existing CityGML classes like e.g. the number of habitants of a building or the definition of new object types. The difference between ADEs and generic objects and attributes is, that an ADE has to be defined in an extra XML schema definition file with its own namespace. This file has to explicitly import the XML Schema definition of the extended CityGML modules.

The advantage of this approach is that the extension is formally specified. Extended CityGML instance documents can be validated against the CityGML and the respective ADE schema. ADEs can be defined (and even standardised) by information communities which are interested in specific application fields. More than one ADE can be actively used in the same dataset (further description cf. ).

ADEs may be defined for one or even several CityGML modules providing a high flexibility in adding additional information to the CityGML data model. Thus, the ADE mechanism is orthogonally aligned with the modularisation approach of CityGML. Consequently, there is no separate extension module for ADEs.

In this specification, two examples for ADEs are included:

• An ADE for Noise Immission Simulation () which is employed in the simulation of environmental noise dispersion according to the Environmental Noise Directive of the European Commission (2002/49/EC);

• An ADE for Ubiquitous Network Robots Services () which demonstrates the usage of CityGML for the navigation of robots in indoor environments.

Further examples for ADEs are the CAFM ADE (Bleifuß et al., 2009) for facility management, the UtilityNetworkADE (Becker et al., 2011) for the integrated 3D modeling of multi-utility networks and their interdependencies, the HydroADE (Schulte and Coors, 2008) for hydrographical applications and the GeoBIM (IFC) ADE (van Berlo et al., 2011) which combines BIM information from IFC (from bSI) with CityGML and is implemented in the open source modelserver BIMserver.org.

Each CityGML module is specified by its own XML Schema definition file and is defined within an individual and globally unique XML target namespace. According to dependency relations between modules, each module may, in addition, import namespaces associated to such related CityGML modules. However, a single namespace shall not be directly included in two modules. Thus, all elements belonging to one module are associated to the module’s namespace only. By this means, module elements are guaranteed to be properly separated and distinguishable in CityGML instance documents.

Compared to CityGML versions before 1.0, the aforementioned namespace conventions introduce an extra level of complexity to data files as there is no single CityGML namespace any more. In contrast, components of different CityGML modules and, thus, of different namespaces may be arbitrarily mixed within the same CityGML instance document. Furthermore, an application might have to parse instance documents containing elements of modules which are not employed by the application itself. These parsing problems though can easily be overcome by non-”schema-aware” applications, i.e. applications that do not parse and interpret GML application schemas in a generic way. Elements from different namespaces than those declared by the application’s employed CityGML profile could be skipped. Comparable observations have to be made when using CityGML’s Application Domain Extension mechanism (cf. ).

As for version 2.0 of the CityGML standard, there are no two thematic extension modules related by dependency. Thus, all extension modules are truly independent from each other and may be separately supported by implementations. However, the CityGML core module is a dependency for any extension module. This means that the XML schema file of the core module is imported by each XML schema file defining an extension.

The dependency relations between CityGML’s modules are illustrated in using an UML package diagram. Each module is represented by a package. The package names correspond to the module names. A dashed arrow in the figure indicates that the schema at the tail of the arrow depends upon the schema at the head of the arrow. For CityGML modules, a dependency occurs where one schema <import>s another schema and accordingly the corresponding XML namespace. For example, the extension module Building imports the schema of the CityGML Core module. A short description of each module is given in .

UML package diagram illustrating the separate modules of CityGML and their schema dependencies. Each extension module (indicated by the leaf packages) further imports the GML 3.1.1 schema definition in order to represent spatial properties of its thematic classes. For readability reasons, the corresponding dependencies have been omitted.

A CityGML profile is a combination of thematic extension modules in conjunction with the core module of CityGML. Each CityGML instance document shall employ the CityGML profile appropriate to the provided data. In general, two approaches to employ a CityGML profile within an instance document can be differentiated:

1. CityGML profile definition embedded inline the CityGML instance document

   A CityGML profile can be bound to an instance document using the schemaLocation attribute defined in the XML Schema instance namespace, (commonly associated with the prefix xsi). The xsi:schemaLocation attribute provides a way to locate the XML Schema definition for namespaces defined in an XML instance document. Its value is a whitespace-delimited list of pairs of Uniform Resource Identifiers (URIs) where each pair consists of a namespace followed by the location of that namespace’s XML Schema definition, which is typically a .xsd file.

   By this means, the namespaces of the respective CityGML modules shall be defined within a CityGML instance document. The xsi:schemaLocation attribute then shall be used to provide the location to the respective XML Schema definition of each module. All example instance documents given in follow this first approach.

2. CityGML profile definition provided by a separate XML Schema definition file

   The CityGML profile may also be specified by its own XML Schema file. This schema file shall combine the appropriate CityGML modules by importing the corresponding XML Schema definitions. For this purpose, the import element defined in the XML Schema namespace shall be used, (commonly associated with the prefix xs). For the xs:import element, the namespace of the imported CityGML module along with the location of the namespace’s XML Schema definition have to be declared. In order to apply a CityGML profile to an instance document, the profile’s schema has to be bound to the instance document using the xsi:schemaLocation attribute. The XML Schema file of the CityGML profile shall not contain any further content.

   The targetNamespace of the profile’s schema shall differ from the namespaces of the imported CityGML modules. The namespace associated with the profile should be in control of the originator of the instance document and must be given as a previously unused and globally unique URI. The profile’s XML Schema file must be available (or accessible on the internet) to everybody parsing the associated CityGML instance document.

The second approach is illustrated by the following example XML Schema definition for the base profile of CityGML. Since the base profile is the union of all CityGML modules, the corresponding XML Schema definition imports each and every CityGML module. By this means, all components of the CityGML data model are available in and may be exchanged by instance documents referencing this example base profile. The schema definition file of the base profile is shipped with the CityGML schema package, and is accessible at http://schemas.opengis.net/citygml/profiles/base/2.0/CityGML.xsd.

The following excerpt of a CityGML dataset exemplifies how to apply the base profile schema CityGML.xsd to a CityGML instance document. The dataset contains two building objects and a city object group. The base profile defined by CityGML.xsd is referenced using the xsi:schemaLocation attribute of the root element. Thus, all CityGML modules are employed by the instance document and no further references to the XML Schema documents of the CityGML modules are necessary.

The geometry model of GML3 consists of primitives, which may be combined to form complexes, composite geometries or aggregates. For each dimension, there is a geometrical primitive: a zero-dimensional object is a Point, a one-dimensional a _Curve, a two-dimensional a _Surface, and a three-dimensional a _Solid (). Each geometry can have its own coordinate reference system. A solid is bounded by surfaces and a surface by curves. In CityGML, a curve is restricted to be a straight line, thus only the GML3 class LineString is used. Surfaces in CityGML are represented by Polygons, which define a planar geometry, i.e. the boundary and all interior points are required to be located in one single plane.

UML diagram of CityGML’s geometry model (subset and profile of GML3): Primitives and Composites.

Combined geometries can be aggregates, complexes or composites of primitives (see illustration in ). For an aggregate, the spatial relationship between components is not restricted. They may be disjoint, overlapping, touching, or disconnected. GML3 provides a special aggregate for each dimension, a MultiPoint, a MultiCurve, a MultiSurface,and a MultiSolid (see ). In contrast to aggregates, a complex is topologically structured: its parts must be disjoint, must not overlap and are allowed to touch, at most, at their boundaries or share parts of their boundaries. A composite is a special complex provided by GML3. It can only contain elements of the same dimension. Its elements must be disjoint as well, but they must be topologically connected along their boundaries. A composite can be a CompositeSolid, a CompositeSurface, or CompositeCurve. (cf. ).

UML diagram of CityGML’s geometry model: Complexes and Aggregates

An OrientableSurface is a surface with an explicit orientation, i.e. two sides, front and back, can be distinguished. This may be used to assign textures to specific sides of a surface, or to distinguish the exterior and the interior side of a surface when bounding a solid. Please note, that curves and surfaces have a default orientation in GML which results from the order of the defining points. Thus, an OrientableSurface only has to be used, if the orientation of a given GML geometry has to be reversed.

TriangulatedSurfaces are special surfaces, which specify triangulated irregular networks often used to represent the terrain. While a TriangulatedSurface is a composition of explicit Triangles, the subclass TIN is used to represent a triangulation in an implicit way by a set of control points, defining the nodes of the triangles. The triangulation may be reconstructed using standard triangulation methods (Delaunay triangulation). In addition, break lines and stop lines define contour characteristics of the terrain.

Combined geometries.

The GML3 composite model realises a recursive aggregation schema 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).

CityGML provides the explicit modelling of topology, for example the sharing of geometry objects between features or other geometries. One part of space is represented only once by a geometry object and is referenced by all features or more complex geometries which are defined or bounded by this geometry object. Thus redundancy is avoided and explicit topological relations between parts are maintained. Basically, there are three cases. First, two features may be defined spatially by the same geometry. For example, if a path is both a transportation feature and a vegetation feature, the surface geometry defining the path is referenced both by the transportation object and by the vegetation object. Second, geometry may be shared between a feature and another geometry. A geometry defining a wall of a building may be referenced twice: by the solid geometry defining the geometry of the building, and by the wall feature. Third, two geometries may reference the same geometry, which is in the boundary of both. For example, a building and an adjacent garage may be represented by two solids. The surface describing the area where both solids touch may be represented only once and it is referenced by both solids. As it can be seen from , this requires partitioning of the respective surfaces. In general, Boundary Representation only considers visible surfaces. However, to make topological adjacency explicit and to allow the possibility of deletion of one part of a composed object without leaving holes in the remaining aggregate touching elements are included. Whereas touching is allowed, permeation of objects is not in order to avoid the multiple representation of the same space. However, the use of topology in CityGML is optional.

In order to implement topology, CityGML uses the XML concept of XLinks provided by GML. Each geometry object that should be shared by different geometric aggregates or different thematic features is assigned an unique identifier, which may be referenced by a GML geometry property using a href attribute. CityGML does not deploy the built-in topology package of GML3, which provides separate topology objects accompanying the geometry. This kind of topology is very complex and elaborate. Nevertheless, it lacks flexibility when data sets, which might include or neglect topology, should be covered by the same data model. The XLink topology is simple and flexible and nearly as powerful as the explicit GML3 topology model. However, a disadvantage of the XLink topology is that navigation between topologically connected objects can only be performed in one direction (from an aggregate to its components), not (immediately) bidirectional as it is the case for GML’s built-in topology. An example for CityGML’s topology representation is given in the dataset listed in .

Recursive aggregation of objects and geometries in CityGML (graphic: IGG Uni Bonn).

The following excerpt of a CityGML example file defines a gml:Polygon with a gml:id wallSurface4711, which is part of the geometry property lod2Solid of a building. Another building being adjacent to the first building references this shared polygon in its geometry representation.

When dealing with geoinformation and virtual 3D city models in particular, the exact spatial reference is of utmost importance and a key requirement for the integration of different spatial datasets in a single 3D city model. CityGML inherits GML3’s spatial capabilities of handling Coordinate Reference Systems (CRS) which is the usual way of denoting the spatial reference in GML 3.1.1. As CityGML is a true 3D standard, geometry elements are associated with a 3D CRS. There are only few exceptions to this rule where CityGML allows a 2D geometry element (for example, the referencePoint of a GeoreferencedTexture defined in CityGML’s Appearance module must be given with 2D coordinate values, cf. ).

In general, a geometry may point to the CRS definition used by this geometry through the attribute srsName which is inherited from the abstract GML superclass gml:_Geometry. This may be a reference to a well-known CRS definition provided by an authority organization such as the European Petroleum Survey Group (EPSG), but may also be a pointer to a CRS that is locally defined within the same CityGML instance document. The OGC document “Definition identifier URNs in OGC namespace” (cf. Whiteside 2009; OGC Doc. No. 07-092r3) provides best practices for the URN encoding of CRS references. Amongst others, it describes how to reference a single well-known 3D CRS definition (such as a 3D geographic CRS) as well as a compound CRS which combines two or more well-known CRS definitions (e.g., a projected CRS for the planimetry with a vertical CRS for the height reference). Examples for denoting a compound CRS for a CityGML instance document are given in .

GML3 also supports the definition of engineering CRSs which are used in a contextually local sense. For example, this might be a local 3D Cartesian coordinate system that is essentially based on a flat-earth approximation of the earth’s surface, and thus ignores the effect of earth curvature on feature geometry (cf. chapter 12.1.4.4 of the GML 3.1.1 specification document). Local engineering CRSs are commonly applied in the AEC/FM domain and thus are useful when integrating CAD data or BIM models into a 3D city model. provides an example demonstrating the definition of an engineering CRS within a CityGML instance document and the use of local coordinate values for the feature geometry. The definition of an engineering CRS requires an anchor point which relates the origin of the local coordinate system to a point on the earth’s surface in order to facilitate the transformation of coordinates from the local engineering CRS.

According to GML 3.1.1, if no srsName attribute is given on a geometry element, then the CRS shall be specified as part of the larger context this geometry element is part of, e.g. a geometric aggregate. For convenience in constructing feature and feature collection instances, the value of the srsName attribute on the gml:Envelope (or gml:Box) which is the value of the gml:boundedBy property of the feature shall be inherited by all directly expressed geometries in all properties of the feature or members of the collection, unless overruled by the presence of a local srsName. Thus it is not necessary for a geometry to carry an srsName attribute if it uses the same CRS as given on the gml:boundedBy property of its parent feature. Inheritance of the CRS continues to any depth of nesting, but if overruled by a local srsName declaration, then the new CRS is inherited by all its children in turn (cf. of the GML 3.1.1 specification document).

It is strongly recommended that any CityGML instance document explicitly specifies the CRS for all contained geometry elements. This is especially important if the instance document is to be exchanged externally with third parties or is to be integrated with other spatial datasets. A mixed usage of different CRSs within the same dataset is possible and conformant with GML 3.1.1, whereas a single CRS reference given on the embracing CityModel feature collection (cf. ) simplifies the processing of the dataset by software systems. As for CityGML 2.0, this recommendation is non-normative and thus not accompanied by a conformance class. The main reason for this is to maintain backwards compatibility with CityGML 1.0.

The concept of implicit geometries is an enhancement of the geometry model of GML3. It is, for example, used in CityGML’s building, bridge, tunnel, and vegetation model as well as for city furniture and generic objects. Implicit geometries may be applied to features from different thematic fields of CityGML in order to geometrically represent the features within a specific level of detail (LOD). Thus, each extension module may define spatial properties providing implicit geometries for its thematic classes. For this reason, the concept of implicit geometries is defined within the CityGML core module (cf. ). However, its description is drawn here since implicit geometries are part of CityGML’s spatial model. The UML diagram is depicted in . The corresponding XML schema definition is provided in .

An implicit geometry is a geometric object, where the shape is stored only once as a prototypical geometry, for example a tree or other vegetation objects, a traffic light or a traffic sign. This prototypic geometry object is re-used or referenced many times, wherever the corresponding feature occurs in the 3D city model. Each occurrence is represented by a link to the prototypic shape geometry (in a local cartesian coordinate system), by a transformation matrix that is multiplied with each 3D coordinate of the prototype, and by an anchor point denoting the base point of the object in the world coordinate reference system. This reference point also defines the CRS to which the world coordinates belong after the application of the transformation. In order to determine the absolute coordinates of an implicit geometry, the anchor point coordinates have to be added to the matrix multiplication results. The transformation matrix accounts for the intended rotation, scaling, and local translation of the prototype. It is a 4×4 matrix that is multiplied with the prototype coordinates using homogeneous coordinates, i.e. (x,y,z,1). This way even a projection might be modelled by the transformation matrix.

UML diagram of ImplicitGeometries. Prefixes are used to indicate XML namespaces associated with model elements. Element names without a prefix are defined within the CityGML Core module.

The reason for using the concept of implicit geometries in CityGML is space efficiency. Since the shape of, for example, trees of the same species can be treated as identical, it would be inefficient to model the detailed geometry of each of the large number of trees explicitly. The concept of implicit geometries is similar to the well known concept of primitive instancing used for the representation of scene graphs in the field of computer graphics (Foley et al. 1995).

The term implicit geometry refers to the principle that a geometry object with a complex shape can be simply represented by a base point and a transformation, implicitly unfolding the object’s shape at a specific location in the world coordinate system.

The shape of an ImplicitGeometry can be represented in an external file with a proprietary format, e.g. a VRML file, a DXF file, or a 3D Studio MAX file. The reference to the implicit geometry can be specified by an URI pointing to a local or remote file, or even to an appropriate web service. Alternatively, the shape can be defined by a GML3 geometry object. This has the advantage that it can be stored or exchanged inline within the CityGML dataset. Typically, the shape of the geometry is defined in a local coordinate system where the origin lies within or near to the object’s extent. If the shape is referenced by an URI, also the MIME type of the denoted object has to be specified (e.g. “model/vrml” for VRML models or “model/x3d+xml” for X3D models).

The implicit representation of 3D object geometry has some advantages compared to the explicit modelling, which represents the objects using absolute world coordinates. It is more space-efficient, and thus more extensive scenes can be stored or handled by a system. The visualisation is accelerated since 3D graphics cards support the scene graph concept. Furthermore, the usage of different shape versions of objects is facilitated, e.g. different seasons, since only the library objects have to be exchanged (see example in ).

XML namespace

The XML namespace of the CityGML Core module defining the concept of implicit geometries is identified by the Uniform Resource Identifier (URI) . Within the XML Schema definition of the core module, this URI is also used to identify the default namespace.

Despite the close relation between surface data and surface, surface data is stored separately in the feature to preserve the original GML geometry model. Instead of surface data being an attribute of the respective target surface geometry object, each surface data object maintains a set of URIs specifying the gml:ids of the target surface geometry objects (of type gml:AbstractSurfaceType or gml:MultiSurface). In case of a composite or aggregate target surface, the surface data object is assigned to all contained surfaces. Other target types such as features, solids, or gml:AbstractSurfacePatchType (which includes gml:Triangle) are invalid, even though the XML schema language cannot formally express constrains on URI target types. For the exact mapping function of surface data values to a surface patch refer to the respective surface data type description.

The limitation of valid target types to gml:AbstractSurfaceType and gml:MultiSurface excluding gml:Abstract­Surface­Patch­Type is based on the GML geometry model and its use in CityGML. In general, GML surfaces are represented using subclasses of gml:AbstractSurfaceType. Such surfaces are required to be continuous. A gml:Multi­Surface does not need to fulfill this requirement and consequently is no gml:AbstractSurfaceType (cf. 8.1). Since captured real-world surfaces often cannot be guaranteed to be continuous, CityGML allows for gml:Multi­Surface to represent a feature’s boundary in various places as an alternative to a continuous surface. To treat such surfaces similarly to a gml:CompositeSurface, surface data objects are allowed to link to gml:Multi­Surface objects. gml:AbstractSurfacePatchType is no valid target type since it is not derived from gml:AbstractGMLType. Thus, a gml:AbstractSurface­PatchType (which includes gml:Triangle and gml:Rectangle) cannot receive a gml:id and cannot be referenced.

Each surface geometry object can have per theme at most one active front-facing material, one active back-facing material, one active front-facing texture, and one active back-facing texture. If multiple surface data objects of the same category and theme are assigned to a surface geometry object, one is chosen to become active. Multiple indirect assignments due to nested surface definitions are resolved by overwriting, e.g. the front-facing material of a gml:Polygon becomes active by overwriting the front-facing material of the parental gml:CompositeSurface. Multiple direct assignments, i.e. a surface geometry object’s gml:id is referenced multiple times within a theme, are not allowed and are resolved implementation-dependently by choosing exactly one of the conflicting surface data objects. Thus, multiple direct assignments within a theme need to be avoided.

Each _CityObject feature can store surface data. Thus, surface data is arranged in the feature hierarchy of a CityGML dataset. Surface data then links to its target surface using URIs. Even though the linking mechanism permits arbitrary links across the feature hierarchy to another feature’s surface, it is recommended to follow the principle of locality: Surface data should be stored such that the linked surfaces only belong to the containing _CityObject feature and its children. “Global” surface data should be stored with the city model. Adhering to the locality principle also ensures that CityObjects retrieved from a WFS will contain the respective appearance information.

The locality principle allows for the following algorithm to find all relevant _SurfaceData objects referring to a given surface geometry object (of type gml:AbstractSurfaceType or gml:MultiSurface) in a given _CityObject:

The evaluation of the isFront property of a _SurfaceData object needs to take gml:OrientableSurfaces into account, as those can flip the orientation of a surface. Assume a gml:OrientableSurface os, which flips its base surface bs. A front side texture $t$t targeting bs will appear on the actual front side of bs. If $t$t targets os, it will appear on the back side of bs. If $t$t targets both os and bs, it appears on both sides of bs since it becomes the front and back side texture.

XLinks influence the hierarchy traversal in the pseudocode. In general, the separation of surface data and geometry objects requires the reevaluation of the surface data assignment for each occurrence of a geometry object in the context of the respective _CityObject. Stepping up the (geometry or _CityObject) hierarchy in the algorithm takes XLinks into account, i.e., for the purpose of this algorithm, referenced objects are conceptually copied to the location of the referring XLink. In particular, this applies to ImplicitGeometry objects. If an ImplicitGeometry object contains GML geometry (in the relativeGMLGeometry property), the surface data assignment needs to be reevaluated in the context of each referring _CityObject. Thus, the appearance (but not the relative geometry) of a given ImplicitGeometry can differ between its occurrences. A consistent appearance results if all required surface data objects are placed in Appearance objects and the latter are stored either

1. in the _CityObject containing the original ImplicitGeometry with XLinks referencing the same Appearance objects in all _CityObjects that refer to the ImplicitGeometry or

2. in the global CityModel.

The feature class Appearance defines a container for surface data objects. It provides the theme that all contained surface data objects are related to. All appearance objects with the same theme in a CityGML file are considered a group. Surface data objects are stored in the surfaceDataMember property. They can be used in multiple themes simultaneously as remote properties.

The feature class _SurfaceData is the base class for materials and textures. Its only element is the boolean flag isFront, which determines the side a surface data object applies to. Please note, that all classes of the appearance model support CityGML’s ADE mechanism (cf. and ). The hooks for application specific extensions are realized by the elements “_GenericApplicationPropertyOf…​”‌.

The definition of appearanceMember allows for an arbitrary or even mixed sequence of _CityObject features and Appearance features within a CityModel feature collection (cf. ).

In order to store appearance information within a single _CityObject feature, the corresponding abstract class _CityObject of the core module is augmented by the property element appearance. The additional property appearance is injected into _CityObject using CityGML’s Application Domain Extension mechanism (cf. ). By this means, each thematic subclass of _CityObject inherits this property. Thus, the Appearance module has a deliberate impact on each extension module defining thematic subclasses of _CityObject.

Materials define light reflection properties being constant for a whole surface geometry object. The definition of the class X3DMaterial is adopted from the X3D and COLLADA specification (cf. X3D, COLLADA specification). diffuseColor defines the color of diffusely reflected light. specularColor defines the color of a directed reflection. emissiveColor is the color of light generated by the surface. All colors use RGB values with red, green, and blue between 0 and 1. Transparency is defined separately using the transparency element where 0 stands for fully opaque and 1 for fully transparent. ambientIntensity defines the minimum percentage of diffuseColor that is visible regardless of light sources. shininess controls the sharpness of the specular highlight. 0 produces a soft glow while 1 results in a sharp highlight. isSmooth gives a hint for normal interpolation. If this boolean flag is set to true, vertex normals should be used for shading (Gouraud shading). Otherwise, normals should be constant for a surface patch (flat shading).

Target surfaces are specified using target elements. Each element contains the URI of one target surface geometry object (of type gml:AbstractSurfaceType or gml:MultiSurface).

The abstract base class for textures is remote _Texture. Textures in CityGML are always raster-based 2D textures. The raster image is specified by imageURI using a URI and can be an arbitrary image data resource, even a preformatted request for a web service. The image data format can be defined using standard MIME types in the mimeType element.

Textures can be qualified by the attribute textureType. The textureType differentiates between textures, which are specific for a certain object (specific) and prototypic textures being typical for that object surface (typical). Textures may also be classified as unknown.

The specification of texture wrapping is adopted from the COLLADA standard. Texture wrapping is required when accessing a texture outside the underlying image raster. wrapMode can have one of five values ( illustrates the effect of these wrap modes):

1. none — the resulting color is fully transparent

2. wrap — the texture is repeated

3. mirror — the texture is repeated and mirrored

4. clamp — the texture is clamped to its edges

5. border — the resulting color is specified by the borderColor element (RGBA)

In wrap mode mirror, the texture image is repeated both in horizontal and in vertical direction to fill the texture space similar to wrap mode wrap. Unlike wrap, each repetition results from flipping the previous texture part along the repetition direction. This behaviour removes the edge correspondence constraint for wrapped textures and always results in a seamless texture.

A texture (a) applied to a facade using different wrap modes: (b) none, (c) wrap, (d) mirror, (e) clamp and (f) border. The border color is red. The numbers denote texture coordinates (image: Hasso-Plattner-Institute).

remote _Texture is further specialised according to the texture parameterisation, i.e. the mapping function from a location on the surface to a location in the texture image. CityGML uses the notion of texture space, where the texture image always occupies the region [0,1]² regardless of the actual image size or aspect ratio. The lower left image corner is located at the origin (some graphics APIs may use other conventions and require texture coordinate conversion). The mapping function must be known for each surface geometry object to receive texture.

A georeferenced texture applied to ground and roof surfaces (source: Senate of Berlin, Hasso-Plattner-Institute).

The class GeoreferencedTexture describes a texture that uses a planimetric projection. Consequently, it does not make sense to texture vertical surfaces using a GeoreferencedTexture. Such a texture has a unique mapping function which is usually provided with the image file (e.g. georeferenced TIFF) or as a separate ESRI world file

Further information about the ESRI world file format is provided at .

Alternatively, CityGML allows for inline specification of a georeference similar to a world file. This internal georeference specification always takes precedence over any external georeference. referencePoint defines the location of the center of the upper left image pixel in world space and corresponds to values 5 and 6 in an ESRI world file. Since GeoreferencedTexture uses a planimetric projection, referencePoint is two-dimensional. orientation defines the rotation and scaling of the image in form of a 2×2 matrix (a list of 4 doubles in row-major order corresponding to values 1, 3, 2, and 4 in an ESRI world file). The CRS of this transformation is identical to the referencePoint‘s CRS. A planimetric point ${(x,y)}^T$(x,y)^T in that CRS is transformed to a point ${(s,t)}^T$(s,t)^T in texture space using the formula:

with $M$M denoting orientation, $P_R$P_R denoting referencePoint, $w$w the image’s width in pixels, and $h$h the image’s height in pixels. This transformation compensates for the difference between the image coordinate system used in ESRI world files (origin in upper left corner, positive x-axis rightwards, and positive y-axis downwards) and texture space in CityGML (origin in lower left corner, positive x-axis rightwards, and positive y-axis upwards).

If neither an internal nor an external georeference is given the GeoreferencedTexture is invalid. Each target surface geometry object is specified by an URI in a target element. All target surface geometry objects share the mapping function defined by the georeference. No other mapping function is allowed. Please note, that the gml:boundedBy property inherited from gml:AbstractFeatureType could be set to the bounding box of valid image data to allow for spatial queries. shows a georeferenced texture applied to the ground and all roof surfaces.

The class ParameterizedTexture describes a texture with target-dependent mapping function. The mapping is defined by subclasses of class remote _TextureParameterization as a property of the link to the target surface geometry object. Each target surface geometry object is specified as URI in the uri attribute of a separate target element. Since target implements gml:AssociationAttributeGroup, it allows referencing to a remote _TextureParameterization object (using the xlink:href attribute), e.g. for sharing a mapping function between targets or textures in different themes. The mapping function can either use the concept of texture coordinates (through class TexCoordList) or a transformation matrix from world space to texture space (through class TexCoordGen).

Positioning of textures using texture coordinates (image: IGG Uni Bonn).

Texture coordinates are applicable only to polygonal surfaces, whose boundaries are described by gml:LinearRing (e.g., gml:Triangle, gml:Polygon, or a gml:MultiSurface consisting of gml:Polygons). They define an explicit mapping of a surface’s vertices to points in texture space, i.e. each vertex including interior ring vertices must receive a corresponding coordinate pair in texture space (for the notion of coordinates, refer to ISO 19111). These coordinates are not restricted to the [0,1] interval. Texture coordinates for interior surface points are planarly interpolated from the vertices’ texture coordinates. shows an example.

Texture coordinates for a target surface geometry object are specified using class TexCoordList as a texture parameterization object in the texture’s target property. Each exterior and interior gml:LinearRing composing the boundary of the target surface geometry object (which also might be a gml:CompositeSurface, gml:MultiSurface, or gml:TriangulatedSurface) requires its own set of texture coordinates. A set of texture coordinates is specified using the textureCoordinates element of class TexCoordList. Thus, a TexCoordList contains as many textureCoordinate elements as the target surface geometry object contains gml:LinearRings. textureCoordinate‘s mandatory attribute ring provides the gml:id of the respective ring. The content is an ordered list of double values where each two values define a ${(s,t)}^T$(s,t)^T texture coordinate pair with $s$s denoting the horizontal and $t$t the vertical texture axis. The list contains one pair per ring point with the pairs’ order corresponding to the ring points’ order in the CityGML document (regardless of a possibly flipped surface orientation). If any ring point of a target surface geometry object has no texture coordinates assigned, the mapping is incomplete and the respective surface cannot be textured. In case of aggregated target geometry objects, mapping completeness is determined only for leaf geometry objects.

Projecting a photograph () onto multiple facades () using the worldToTexture transformation. The photograph does not cover the left facade completely. Thus, the texture appears to be clipped. Texture wrapping is set to "none" (source: Senate of Berlin, Hasso-Plattner-Institute).

Alternatively, the mapping function can comprise a 3×4 transformation matrix specified by class TexCoordGen. The transformation matrix, specified by the worldToTexture element, defines a linear transformation from a spatial location in homogeneous coordinates to texture space. The use of homogeneous coordinates facilitates perspective projections as transformation, e.g. for projecting a photograph into a city model (cf. ). Texture coordinates ${(s,t)}^T$(s,t)^T are calculated from a space location ${(x,y,z)}^T$(x,y,z)^T as ${(s,t)}^T={(s\prime /q,t\prime /q\prime )}^T$(s,t)^T = (s' // q, t' // q')^T with ${(s\prime ,t\prime ,q\prime )}^T=M\cdot {(x,y,z,1)}^T$(s',t',q')^T = M cdot (x,y,z,1)^T. $M$M denotes the $3\times 4$3 xx 4 transformation matrix. Compared to a general 4×4 transformation, the resulting $z$z component is ignored. Thus, the respective matrix row is omitted. Additionally, the worldToTexture element uses the gml:SRSReferenceGroup attributes to define its CRS. A location in world space has to be first transformed into this CRS before the transformation matrix can be applied.

The following construction results in a worldToTexture transformation that mimics the process of taking a photograph by projecting a location in world space (in the city model) to a location in texture space:

In this formula, $f$f denotes the focal length; $w$w and $h$h represent the image sensor’s physical dimensions; $\overrightarrow{r}$vec r, $\overrightarrow{u}$vec u, and $\overrightarrow{d}$vec d define the camera’s frame of reference as right, up and directional unit vectors expressed in world coordinates; and $P$P stands for the camera’s location in world space. sketches this setting.

Projective texture mapping. All points on a ray $R$R starting from the projection center $P$P are mapped to the same point $T$T in texture space (image: Hasso-Plattner-Institute, IGG TU Berlin).

Alternatively, if the $3\times 4$3 xx 4 camera matrix $M_P$M_P is known (e.g. through a calibration and registration process), it can easily be adopted for use in worldToTexture. $M_P$M_P is derived from intrinsic and extrinsic camera parameters (interior and exterior orientation) and transforms a location in world space to a pixel location in the image. Assuming the upper left image corner has pixel coordinates (0,0), the complete transformation to texture space coordinates can be written as (${\text{width}}_{\text{image}}$"width"_{"image"} and ${\text{height}}_{\text{image}}$"height"_{"image"} denote the image size in pixels):

Please note, that worldToTexture cannot compensate for radial or other non-linear distortions introduced by a real camera lens.

Another use of worldToTexture is texturing a facade with complex geometry without specifying texture coordinates for each gml:LinearRing. Instead, only the facade’s aggregated surface becomes the texture target using a TexCoordGen as parameterization. Then, worldToTexture effectively encodes an orthographic projection of world space into texture space. For the special case of a vertical facade this transformation is given by:

This equation assumes $\overrightarrow{n}$vec n denoting the facade’s overall normal vector (normalized, pointing outward, and being parallel to the ground), $F$F denoting the facade’s lower left point, and ${\text{width}}_f$"width"_f and ${\text{height}}_f$"height"_f specifying the facade’s dimensions in world units. For the general case of an arbitrary normal vector the facade orientation matrix assumes a form similar to the camera orientation matrix:

with

The notion of appearance clearly relates to the generic coverage approach (cf. ISO 19123 and OGC Abstract specification, Topic 6). Surface data can be described as discrete or continuous coverage over a surface as two-dimensional domain with a specific mapping function. Such an implementation requires the extension of GML coverages (as of version 3.1) by suitable mapping functions and specialisation for valid domain and range sets. For reasons of simplicity and comprehensibility both in implementation and usage, CityGML does not follow this approach, but relies on textures and materials as well-known surface property descriptions from the field of computer graphics (cf. X3D, COLLADA specification, Foley et al.). Textures and materials store data as color using an appropriate mapping. If such a mapping is impractical, data storage can be customised using ADEs. A review of coverages for appearance modelling is considered for CityGML beyond version 2.0.0.

Appearance is also related to portrayal. Portrayal describes the composition and symbolisation of a digital model’s image, i.e. presentation, while appearance encodes observations of the real object’s surface, i.e. data. Even though being based on graphical terms such as textures and materials, surface data is not limited to being input for portrayal, but similarly serves as input or output for analyses on a feature’s surface. Consequently, CityGML does not define mixing or composition of themes for portrayal purposes. Portrayal is left to viewer applications or styling specification languages such as OGC Styled Layer Descriptors (SLD) or OGC Symbology Encoding (SE).

The mimeType attribute of the feature remote _Texture is specified as gml:CodeType. The values of this property can be enumerated in a code list. A proposal for this code list can be found in .

Base requirements

1. A surface geometry object may be the target of at most two textures and two materials (one for front and back respectively) per theme.

2. The referencePoint property (type: gml:PointPropertyType) of the element GeoreferencedTexture may only contain or reference a point geometry object with 2D coordinate values.

3. Texture coordinates given by the textureCoordinates property of the element TexCoordList define an explicit mapping of a surface’s boundary points to points in texture space. Each boundary point of the surface must receive a corresponding coordinate pair in texture space. The coordinate pair in texture space shall be given as two doubles per boundary point. The order of the coordinate pairs must follow the order of the boundary points in the CityGML document (regardless of a possibly flipped surface orientation). Each gml:LinearRing composing the boundary of the target surface geometry object requires its own set of texture coordinates.

4. A GeoreferencedTexture element must provide either internal or external georeference, otherwise it is invalid. Internal georeference shall be declared by the referencePoint property (type: gml:PointPropertyType) and the orientation property (type: core:TransformationMatrix2x2Type) of the element GeoreferencedTexture. External georeference may be provided by the texture image file itself (e.g. GeoTIFF) or by an accompanying world file.

Referential integrity

5. The appearanceMember element (type: AppearancePropertyType) may contain an Appearance element inline or an XLink reference to a remote Appearance element using the XLink concept of GML 3.1.1. In the latter case, the xlink:href attribute of the appearanceMember element may only point to a remote Appearance element (where remote Appearance elements are located in another document or elsewhere in the same document). Either the contained element or the reference must be given, but neither both nor none.

6. The appearance property (type: AppearancePropertyType) of the element core:_CityObject may contain an Appearance element inline or an XLink reference to a remote Appearance element using the XLink concept of GML 3.1.1. In the latter case, the xlink:href attribute of the appearance property may only point to a remote Appearance element (where remote Appearance elements are located in another document or elsewhere in the same document). Either the contained element or the reference must be given, but neither both nor none.

7. The surfaceDataMember property (type: SurfaceDataPropertyType) of the element Appearance may contain a remote _SurfaceData element inline or an XLink reference to a remote _SurfaceData element using the XLink concept of GML 3.1.1. In the latter case, the xlink:href attribute of the surfaceDataMember property may only point to a remote _SurfaceData element (where remote _SurfaceData elements are located in another document or elsewhere in the same document). Either the contained element or the reference must be given, but neither both nor none.

8. The target property (type: TextureAssociationType) of the element ParameterizedTexture may contain a _TextureParameterization element inline or an XLink reference to a remote _TextureParameterization element using the XLink concept of GML 3.1.1. In the latter case, the xlink:href attribute of the target property may only point to a remote _TextureParameterization element (where remote _TextureParameterization elements are located in another document or elsewhere in the same document). Either the contained element or the reference must be given, but neither both nor none.

9. The target property (type xs:anyURI) of the element GeoreferencedTexture shall specify the gml:id of the target surface geometry object which may only be of type gml:AbstractSurfaceType or gml:MultiSurface.

10. The uri attribute of the complex type TextureAssociationType shall specify the gml:id of the target surface geometry object which may only be of type gml:AbstractSurfaceType or gml:MultiSurface.

11. The ring attribute of the textureCoordinates property of the element TexCoordList shall specify the gml:id of the target surface geometry object which may only be of type gml:LinearRing.

12. The target property (type xs:anyURI) of the element X3DMaterial shall specify the gml:id of the target surface geometry object which may only be of type gml:AbstractSurfaceType or gml:MultiSurface.

Since GML3 has no built-in concept for the representation of surface materials, previous versions of CityGML extend the GML3 geometry model by the class TexturedSurface, which allows for assigning appearance properties (colors, shininess, transparency) and textures to 3D surfaces. The definition of the appearance properties is adopted from the X3D specification. This approach for appearance modelling has been deprecated due to inherent limitations. However, in order to provide a certain degree of backwards compatibility for already existing CityGML implementations, the approach has been incorporated into CityGML version 1.0 and version 2.0 as a separate extension module called TexturedSurface. By this means, implementations may employ the old material model by supporting this module. Please note, that appearance information modelled according to the TexturedSurface module can be converted without information loss to the concepts provided by CityGML’s Appearance module that has been introduced in the previous clauses of this chapter. Thus, the use of the TexturedSurface module is strongly discouraged and implementations should only stick to the Appearance module instead. Moreover, the TexturedSurface module is expected to be removed in future versions of CityGML.

For the TexturedSurface module, each surface or composite surface can be specialized to a TexturedSurface, which can be assigned Materials (colors, shininess, transparency) or SimpleTextures. depicts the UML diagram, for XML schema definition see .

UML diagram of CityGML’s material model. Please note, that this approach for appearance modelling has been marked as deprecated and is expected to be removed in future CityGML versions. Prefixes are used to indicate XML namespaces associated with model elements. Element names without a prefix are defined within the CityGML TexturedSurface module.

The concept of positioning textures on surfaces complies with the 3D computer graphics standard X3D (web 3D 2004), a successor of VRML97. CityGML adds the class TexturedSurface to the geometry model of GML3 because there has been no appropriate texturing concept in ISO 19107 and in GML3.

A texture is specified as a raster image referenced by an URI (Uniform Resource Identifier) and can be an arbitrary resource, even on the internet. Textures are positioned by employing the concept of texture coordinates, i.e. each texture coordinate matches with exactly one 3D coordinate of the TexturedSurface (). The use of texture coordinates allows an exact positioning and trimming of the texture on the surface geometry.

The color of a surface is defined by RGB values. These have to be in the range of 0 to 1. The frontOpacity and the backOpacity define the level of transparency of each surface. Their values have also to be in the range of 0 to 1, where 1 means completely covering and 0 denotes a completely transparent surface. The colors can be differentiated in diffuseColor (color when illuminated by a source of light), emissiveColor (color when self-illuminating) and specularColor/shininess (color for shiny surfaces).

Textures can be qualified by the attribute textureType. The textureType differentiates between textures which are specific for a certain object (specific) and prototypic textures being typical for that object surface (typical). Textures may also be classified as unknown.

_Appearanceis derived from gml:AbstractGMLType to be referenced in an appearance property. The attribute gml:id is inherited, whose value may be referenced by a XLink. _Appearance is the parent class of Material and SimpleTexture.

XML namespace

The XML namespace of the CityGML TexturedSurface module is identified by the Uniform Resource Identifier (URI) . Within the XML Schema definition of the TexturedSurface module, this URI is also used to identify the default namespace.

The CityGML Core module defines the basic concepts and components of the overall CityGML data model. It forms the universal lower bound of the CityGML data model and, thus, is a dependency of all extension modules. Consequently, the core module has to be implemented by any conformant system. Primarily, the core module provides the abstract base classes from which thematic classes within extension modules are (transitively) derived. Besides abstract type definitions, the core also contains non-abstract content, for example basic data types and thematic classes that may be used by more than one extension module. The UML diagram in illustrates CityGML’s core module, for the XML Schema definition see below and .

UML diagram of CityGML’s core module. The bracketed numbers following the attribute names denote the attribute’s multiplicity: the minimal and maximal number of occurrences of the attribute per object. For example, a name is optional (0) in the class _Feature or may occur multiple times (star symbol), while a _CityObject has none or at most one creationDate. Prefixes are used to indicate XML namespaces associated with model elements. Element names without a prefix are defined within the CityGML Core module.

The base class of all thematic classes within CityGML’s data model is the abstract class _CityObject. _CityObject provides a creation and a termination date for the management of histories of features as well as the possibility to model external references to the same object in other data sets. Furthermore, two qualitative attributes relativeToTerrain and relativeToWater are provided which enable to specify the feature’s location with respect to the terrain and water surface. The possible topological relations are illustrated in . Both attributes facilitate simple and efficient queries like for the number of subsurface buildings (entirelyBelowTerrain) without the need for an additional digital terrain model or a model of the water body.

Topological relations of a CityGML object with respect to a) the terrain and b) the water surface.

a)

b)

_CityObject is a subclass of the GML class _Feature, thus it inherits the metadata property (which can be e.g. information about the lineage, quality aspects, accuracy, local CRS) and name property from the superclass _GML. A _CityObject may have multiple names, which are optionally qualified by a codeSpace.This enables the differentiation between, for example, an official name and a popular name or of names in different languages (cf. the name property of GML objects, Cox et al. 2004). The generalisation property generalizesTo of _CityObject may be used to relate features, which represent the same real-world object in different Levels-of-Detail, i.e. a feature and its generalised counterpart(s). The direction of this relation is from the feature to the corresponding generalised feature.

Thematic classes may have further subclasses with relations, attributes and geometry. Features of the specialized subclasses of _CityObject may be aggregated to a single CityModel, which is a feature collection with optional metadata. Generally, each feature has the attributes class, function, and usage, unless it is stated otherwise. The class attribute can occur only once, while the attributes usage and function can be used multiple times. The class attribute allows for the classification of features beyond the thematic class hierarchy of _CityObject. For example, a building feature is represented by the thematic subclass bldg:Building of _CityObject in the first place (this subclass is defined within CityGML’s Building module, cf. ). A further classification, e.g. as residential or administration building, may then be modelled using the class attribute of the class bldg:Building. The attribute function normally denotes the intended purpose or usage of the object, such as hotel or shopping centre for a building, while the attribute usage normally defines its real or actual usage. Possible values for the attributes class, function, and usage can be specified in code lists which are recommended to be implemented as simple dictionaries following the Simple Dictionary Profile of GML 3.1.1 (cf. and ). provides code lists proposed and maintained by the SIG 3D which contain feasible attribute values and which may be extended or redefined by users.

In addition to thematic content, the core module also provides the concept of implicit geometries as an enhancement of the geometry model of GML3. Since this concept is strongly related to the spatial model of CityGML it has already been introduced in .

The top level class hierarchy of the thematic model in CityGML is presented in . The subclasses of _CityObject comprise the different thematic fields of a city model covered by separate CityGML extension modules: the terrain, buildings, bridges, tunnels, the coverage by land use objects, water bodies, vegetation, generic city objects, city furniture objects, city object groups, and transportation. To indicate the extension module defining a respective subclass of _CityObject, the class names in are preceded by prefixes. Each prefix is associated with one CityGML extension module (see and for a list of CityGML’s extension modules and the corresponding prefixes).

CityGML’s top level class hierarchy. Prefixes are used to indicate XML namespaces associated with model elements. Element names without a prefix are defined within the CityGML Core module.

The classes GenericCityObject and _genericAttribute defined within CityGML’s Generics module (cf. and ) allow for modelling and exchanging of 3D objects which are not covered by any other thematic class or which require attributes not represented in CityGML. For example, in the future, sites derived from the abstract class _Site of the core module may be completed by further subclasses like excavation, city wall or embankment. At present, the class GenericCityObject should be used in order to represent and exchange these features. However, the concept of generic city objects and attributes may only be used if appropriate thematic classes or attributes are not provided by any other CityGML module.

If the Generics module is employed, each CityObject may be assigned an arbitrary number of generic attributes in order to represent additional properties of features. For this purpose, the Generics module augments the abstract base class _CityObject by the property element _genericAttribute. The additional property _genericAttribute is injected into _CityObject using CityGML’s Application Domain Extension mechanism (cf. ). By this means, each thematic subclass of _CityObject inherits this property and, thus, the possibility to contain generic attributes. Therefore, the Generics module has a deliberate impact on all CityGML extension modules defining thematic subclasses of _CityObject.

Appearance information about a feature’s surfaces can be represented by the class Appearance provided by CityGML’s Appearance module (cf. ). In contrast to the other thematic extensions to the core, Appearance is not derived from _CityObject but from the GML class _Feature. _CityObject features and Appearance features may be embraced within a single CityModel feature collection in an arbitrary or even mixed sequence using the cityObjectMember and appearanceMember elements, both being members of the substitution group gml:featureMember (cf. and ). Furthermore, feature appearances may be stored inline the _CityObject itself. In order to enable city objects to store appearance information, the Appearance module augments the abstract base class _CityObject by the property element appearance using CityGML’s Application Domain Extension mechanism (cf. ). Consequently, the appearance property is only available for _CityObject and its thematic subclasses if the Appearance module is supported. Therefore, like the Generics module, the Appearance module has a deliberate impact on any other extension module.

For sake of completeness, the class TexturedSurface is also illustrated in . This approach of appearance modelling of previous versions of CityGML has been deprecated and is expected to be removed in future CityGML versions. Since the information covered by TexturedSurface can be losslessly converted to the Appearance module, the use of TexturedSurface is strongly discouraged.

XML namespace

The XML namespace of the CityGML Core module is identified by the Uniform Resource Identifier (URI) . Within the XML Schema definition of the core module, this URI is also used to identify the default namespace.

An essential part of a city model is the terrain. The Digital Terrain Model (DTM) of CityGML is provided by the thematic extension module Relief (cf. ). In CityGML, the terrain is represented by the class ReliefFeature in LOD 0-4 ( depicts the UML diagram, for the XML schema definition see ). A ReliefFeature consists of one or more entities of the class ReliefComponent. Its validity may be restricted to a certain area defined by an optional validity extent polygon. As ReliefFeature and ReliefComponent are derivatives of _CityObject, the corresponding attributes and relations are inherited. The class ReliefFeature is associated with different concepts of terrain representations which can coexist. The terrain may be specified as a regular raster or grid (RasterRelief), as a TIN (Triangulated Irregular Network, TINReflief), by break lines (BreaklineRelief), or by mass points (MasspointRelief). The four types are implemented by the corresponding GML3 classes: grids by gml:RectifiedGridCoverage, break lines by gml:MultiCurve, mass points by gml:MultiPoint and TINs either by gml:TriangulatedSurface or by gml:Tin. In case of gml:, the triangles are given explicitly while in case of gml:Tin only 3D points are represented, where the triangulation can be reconstructed by standard methods (Delaunay triangulation, cf. Okabe et al. 1992). Break lines are represented by 3D curves. Mass points are simply a set of 3D points.

UML diagram of the Digital Terrain Model in CityGML. Prefixes are used to indicate XML namespaces associated with model elements. Element names without a prefix are defined within the CityGML Relief module.

In a CityGML dataset the four terrain types may be combined in different ways, yielding a high flexibility. First, each type may be represented in different levels of detail, reflecting different accuracies or resolutions. Second, a part of the terrain can be described by the combination of multiple types, for example by a raster and break lines, or by a TIN and break lines. In this case, the break lines must share the geometry with the triangles. Third, neighboring regions may be represented by different types of terrain models. To facilitate this combination, each terrain object is provided with a spatial attribute denoting its extent of validity (). In most cases, the extent of validity of a regular raster dataset corresponds to its bounding box. This validity extent is represented by a 2D footprint polygon, which may have holes. This concept enables, for example, the modelling of a terrain by a coarse grid, where some distinguished regions are represented by a detailed, high-accuracy TIN. The boundaries between both types are given by the extent attributes of the corresponding terrain objects.

Nested DTMs in CityGML using validity extent polygons (graphic: IGG Uni Bonn).

Accuracy and resolution of the DTM are not necessarily dependent on features of other CityGML extenstion modules such as building models. Hence, there is the possibility to integrate building models with higher LOD to a DTM with lower accuracy or resolution.

This approach interacts with the concept of TerrainIntersectionCurves TIC (cf. ). The TIC can be used like break lines to adjust the DTM to different features such as buildings, bridges, or city furnitures, and hence to ensure a consistent representation of the DTM. If necessary, a retriangulation may have to be processed. A TIC can also be derived by the individual intersection of the DTM and the corresponding feature.

ReliefFeature and its ReliefComponents both have an lod attribute denoting the corresponding level of detail. In most cases, the LOD of a ReliefFeature matches the LOD of its ReliefComponents. However, it is also allowed to specify a ReliefFeature with a high LOD which consists of ReliefComponents where some of them can have a LOD lower than that of the aggregating ReliefFeature. The idea is that, for example, for a LOD3 scene it might be sufficient to use a regular grid in LOD2 with certain higher precision areas defined by ReliefComponents in LOD3. The LOD2 grid and the LOD3 components can easily be integrated using the concept of the validity extent polygon. Therefore, although some of the ReliefComponents would have been classified to a lower LOD, the whole ReliefFeature would be appropriate to use with other LOD3 models which is indicated by setting its lod value to 3.

XML namespace

The XML namespace of the CityGML Relief module is identified by the Uniform Resource Identifier (URI) . Within the XML Schema definition of the Relief module, this URI is also used to identify the default namespace.

The building model is one of the most detailed thematic concepts of CityGML. It allows for the representation of thematic and spatial aspects of buildings and building parts in five levels of detail, LOD0 to LOD4. The building model of CityGML is defined by the thematic extension module Building (cf. ). provides examples of 3D city and building models in LOD1 — 4.

Examples for city or building models in LOD1 (upper left), LOD2 (upper right), LOD3 (lower left), and LOD4 (lower right) (source: District of Recklinghausen, m-g-h ingenieure+architekten GmbH).

The UML diagram of the building model is depicted in , for the XML schema definition see and below. The pivotal class of the model is _AbstractBuilding, which is a subclass of the thematic class _Site (and transitively of the root class _CityObject). _AbstractBuilding is specialised either to a Building or to a BuildingPart. Since an _AbstractBuilding consists of BuildingParts, which again are _AbstractBuildings, an aggregation hierarchy of arbitrary depth may be realised. As subclass of the root class _CityObject, an _AbstractBuilding inherits all properties from _CityObject like the GML3 standard feature properties (gml:name etc.) and the CityGML specific properties like ExternalReferences (cf. ). Further properties not explicitly covered by _AbstractBuilding may be modelled as generic attributes provided by the CityGML Generics module (cf. ) or using the CityGML Application Domain Extension mechanism (cf. ).

Building complexes, which consist of a number of distinct buildings like a factory site or hospital complex, should be aggregated using the concept of CityObjectGroups (cf. ). The main building of the complex can be denoted by providing “main building” as the role name of the corresponding group member.

Both classes Building and BuildingPart inherit the attributes of _AbstractBuilding: the class of the building, the function (e.g. residential, public, or industry), the usage, the year of construction, the year of demolition, the roof type, the measured height, and the number and individual heights of the storeys above and below ground. This set of parameters is suited for roughly reconstructing the three-dimensional shape of a building and can be provided by cadastral systems. Furthermore, Address features can be assigned to Buildings or BuildingParts.

UML diagram of CityGML’s building model. Prefixes are used to indicate XML namespaces associated with model elements. Element names without a prefix are defined within the CityGML Building module.

The geometric representation and semantic structure of an _AbstractBuilding is shown in . The model is successively refined from LOD0 to LOD4. Therefore, not all components of a building model are represented equally in each LOD and not all aggregation levels are allowed in each LOD. In CityGML, all object classes are associated to the LODs with respect to the proposed minimum acquisition criteria for each LOD (cf. ). An object can be represented simultaneously in different LODs by providing distinct geometries for the corresponding LODs.

In LOD0, the building can be represented by horizontal, 3-dimensional surfaces. These can represent the footprint of the building and, separately, the roof edge. This allows the easy integration of 2D data into the model. In many countries these 2D geometries readily exist, for example in cadastral or topographic data holdings. Cadastre data typically depicts the shape of the building on the ground (footprints) and topographic data is often a mixture between footprints and geometries at roof level (roof edges), which are often photogrametrically extracted from area/satellite images or derived from airborne laser data. The building model allows the inclusion of both. In this case large overhanging roofs can be modelled as a preliminary stage to more detailed LOD2 and LOD3 depictions. The surface geometries require 3D coordinates, though it is mandated that the height values of all vertices belonging to the same surface are identical. If 2D geometries are imported into any of these two LOD0 geometries, an appropriate height value for all vertices needs to be chosen. The footprint is typically located at the lowest elevation of the ground surface of the building whereas the roof edge representation should be placed at roof level (e.g., eaves height).

In LOD1, a building model consists of a generalized geometric representation of the outer shell. Optionally, a gml:MultiCurve representing the TerrainIntersectionCurve (cf. ) can be specified. This geometric representation is refined in LOD2 by additional gml:MultiSurface and gml:MultiCurve geometries, used for modelling architectural details like roof overhangs, columns, or antennas. In LOD2 and higher LODs the outer facade of a building can also be differentiated semantically by the classes _BoundarySurface and BuildingInstallation. A _BoundarySurface is a part of the building’s exterior shell with a special function like wall (WallSurface), roof (RoofSurface), ground plate (GroundSurface), outer floor (OuterFloorSurface), outer ceiling (OuterCeilingSurface) or ClosureSurface. The BuildingInstallation class is used for building elements like balconies, chimneys, dormers or outer stairs, strongly affecting the outer appearance of a building. A BuildingInstallation may have the attributes class, function, and usage (cf. ).

In LOD3, theopenings in _BoundarySurface objects (doors and windows) can be represented as thematic objects. In LOD4, the highest level of resolution, also the interior of a building, composed of several rooms, is represented in the building model by the class Room. This enlargement allows a virtual accessibility of buildings, e.g. for visitor information in a museum (“Location Based Services”), the examination of accommodation standards or the presentation of daylight illumination of a building. The aggregation of rooms according to arbitrary, user defined criteria (e.g. for defining the rooms corresponding to a certain storey) is achieved by employing the general grouping concept provided by CityGML (cf. ). Interior installations of a building, i.e. objects within a building which (in contrast to furniture) cannot be moved, are represented by the class IntBuildingInstallation. If an installation is attached to a specific room (e.g. radiators or lamps), they are associated with the Room class, otherwise (e.g. in case of rafters or pipes) with _AbstractBuilding. A Room may have the attributes class, function and usage whose value can be defined in code lists ( and ). The class attribute allows a classification of rooms with respect to the stated function, e.g. commercial or private rooms, and occurs only once. The function attribute is intended to express the main purpose of the room, e.g. living room, kitchen. The attribute usage can be used if the way the object is actually used differs from the function. Both attributes can occur multiple times.

The visible surface of a room is represented geometrically as a Solid or MultiSurface. Semantically, the surface can be structured into specialised _BoundarySurfaces, representing floor (FloorSurface), ceiling (CeilingSurface), and interior walls (InteriorWallSurface). Room furniture, like tables and chairs, can be represented in the CityGML building model with the class BuildingFurniture. A BuildingFurniture may have the attributes class, function and usage. Annexes G.1 to G.6 provide example CityGML documents containing a single building model which is subsequently refined from a coarse LOD0 representation up to a semantically rich and geometric-topologically sound LOD4 model including the building interior.

XML namespace

The XML namespace of the CityGML Building module is identified by the Uniform Resource Identifier (URI) . Within the XML Schema definition of the Building module, this URI is also used to identify the default namespace.

BuildingType, Building<xs:complexType name="BuildingType"> <xs:complexContent> <xs:extension base="AbstractBuildingType"> <xs:sequence> <xs:element ref="_GenericApplicationPropertyOfBuilding" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================= --> <xs:element name="Building" type="BuildingType" substitutionGroup="_AbstractBuilding"/> <!-- ========================================================================================= --> <xs:element name="_GenericApplicationPropertyOfBuilding" type="xs:anyType" abstract="true"/>

The Building class is one of the two subclasses of _AbstractBuilding. If a building only consists of one (homogeneous) part, this class shall be used. A building composed of structural segments differing in, for example the number of storeys or the roof type has to be separated into one Building having one or more additional BuildingPart (see ). The geometry and non-spatial properties of the central part of the building should be represented in the aggregating Building feature.

BuildingPartType, BuildingPart<xs:complexType name="BuildingPartType"> <xs:complexContent> <xs:extension base="AbstractBuildingType"> <xs:sequence> <xs:element ref="_GenericApplicationPropertyOfBuildingPart" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================= --> <xs:element name="BuildingPart" type="BuildingPartType" substitutionGroup="_AbstractBuilding"/> <!-- ========================================================================================= --> <xs:element name="_GenericApplicationPropertyOfBuildingPart" type="xs:anyType" abstract="true"/>

The class BuildingPart is derived from _AbstractBuilding. It is used to model a structural part of a building (see ). A BuildingPart object should be uniquely related to exactly one building or building part object.

Examples of buildings consisting of one and two building parts (source: City of Coburg).

AbstractBuildingType, _AbstractBuilding<xs:complexType name="AbstractBuildingType" abstract="true"> <xs:complexContent> <xs:extension base="core:AbstractSiteType"> <xs:sequence> <xs:element name="class" type="gml:CodeType" minOccurs="0"/> <xs:element name="function" type="gml:CodeType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="usage" type="gml:CodeType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="yearOfConstruction" type="xs:gYear" minOccurs="0"/> <xs:element name="yearOfDemolition" type="xs:gYear" minOccurs="0"/> <xs:element name="roofType" type="gml:CodeType" minOccurs="0"/> <xs:element name="measuredHeight" type="gml:LengthType" minOccurs="0"/> <xs:element name="storeysAboveGround" type="xs:nonNegativeInteger" minOccurs="0"/> <xs:element name="storeysBelowGround" type="xs:nonNegativeInteger" minOccurs="0"/> <xs:element name="storeyHeightsAboveGround" type="gml:MeasureOrNullListType" minOccurs="0"/> <xs:element name="storeyHeightsBelowGround" type="gml:MeasureOrNullListType" minOccurs="0"/> <xs:element name="lod0FootPrint" type="gml:MultiSurfacePropertyType" minOccurs="0"/> <xs:element name="lod0RoofEdge" type="gml:MultiSurfacePropertyType" minOccurs="0"/> <xs:element name="lod1Solid" type="gml:SolidPropertyType" minOccurs="0"/> <xs:element name="lod1MultiSurface" type="gml:MultiSurfacePropertyType" minOccurs="0"/> <xs:element name="lod1TerrainIntersection" type="gml:MultiCurvePropertyType" minOccurs="0"/> <xs:element name="lod2Solid" type="gml:SolidPropertyType" minOccurs="0"/> <xs:element name="lod2MultiSurface" type="gml:MultiSurfacePropertyType" minOccurs="0"/> <xs:element name="lod2MultiCurve" type="gml:MultiCurvePropertyType" minOccurs="0"/> <xs:element name="lod2TerrainIntersection" type="gml:MultiCurvePropertyType" minOccurs="0"/> <xs:element name="outerBuildingInstallation" type="BuildingInstallationPropertyType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="interiorBuildingInstallation" type="IntBuildingInstallationPropertyType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="boundedBy" type="BoundarySurfacePropertyType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="lod3Solid" type="gml:SolidPropertyType" minOccurs="0"/> <xs:element name="lod3MultiSurface" type="gml:MultiSurfacePropertyType" minOccurs="0"/> <xs:element name="lod3MultiCurve" type="gml:MultiCurvePropertyType" minOccurs="0"/> <xs:element name="lod3TerrainIntersection" type="gml:MultiCurvePropertyType" minOccurs="0"/> <xs:element name="lod4Solid" type="gml:SolidPropertyType" minOccurs="0"/> <xs:element name="lod4MultiSurface" type="gml:MultiSurfacePropertyType" minOccurs="0"/> <xs:element name="lod4MultiCurve" type="gml:MultiCurvePropertyType" minOccurs="0"/> <xs:element name="lod4TerrainIntersection" type="gml:MultiCurvePropertyType" minOccurs="0"/> <xs:element name="interiorRoom" type="InteriorRoomPropertyType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="consistsOfBuildingPart" type="BuildingPartPropertyType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="address" type="core:AddressPropertyType" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="_GenericApplicationPropertyOfAbstractBuilding" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================= --> <xs:element name="_AbstractBuilding" type="AbstractBuildingType" abstract="true" substitutionGroup="core:_Site"/> <!-- ========================================================================================= --> <xs:element name="_GenericApplicationPropertyOfAbstractBuilding" type="xs:anyType" abstract="true"/>

The abstract class _AbstractBuilding contains properties for building attributes, purely geometric representations, and geometric/semantic representations of the building or building part in different levels of detail. The attributes describe:

1. The classification of the building or building part (class), the different intended usages (function), and the different actual usages (usage). The permitted values for these attributes can be specified in code lists.

2. The year of construction (yearOfConstruction) and the year of demolition (yearOfDemolition) of the building or building part. These attributes can be used to describe the chronology of the building development within a city model. The points of time refer to real world time.

3. The roof type of the building or building part (roofType). The permitted values for this attribute can be specified in a code list.

4. The measured relative height (measuredHeight) of the building or building part.

5. The number of storeys above (storeyAboveGround) and below (storeyBelowGround) ground level.

6. The list of storey heights above (storeyHeightsAboveGround) and below (storeyHeightsBelowGround) ground level. The first value in a list denotes the height of the nearest storey wrt. to the ground level and last value the height of the farthest.

Spanning the different levels of detail, the building model differs in the complexity and granularity of the geometric representation and the thematic structuring of the model into components with a special semantic meaning. This is illustrated in and , showing the same building in five different LODs. The class _AbstractBuilding has a number of properties which are associated with certain LODs.

The two possibilities of modeling a building in LOD0 using horizontal 3D surfaces. On the left, the building footprint (lod0FootPrint) is shown (cyan)which denotes the shape of the building on the ground. The corresponding surface representation is located at ground level.On the right, the lod0RoofEgde representation is illustrated (cyan) which results from a horizontal projection of the building’s roof and which is located at the eaves height (source: Karlsruhe Institute of Technology (KIT), courtesy of Franz-Josef Kaiser).

Building model in LOD1 — LOD4 (source: Karlsruhe Institute of Technology (KIT), courtesy of Franz-Josef Kaiser).

shows the correspondence of the different geometric and semantic themes of the building model to LODs. In LOD1 — 4, the volume of a building can be expressed by a gml:Solid geometry and/or a gml:MultiSurface geometry. The definition of a 3D Terrain Intersection Curve (TIC), used to integrate buildings from different sources with the Digital Terrain Model, is also possible in LOD1 - 4. The TIC can — but does not have to — build closed rings around the building or building parts.

In LOD0 (cf. ) the building is represented by horizontal surfaces describing the footprint and the roof edge.

In LOD1 (cf. ), the different structural entities of a building are aggregated to a simple block and not differentiated in detail. The volumetric and surface parts of the exterior building shell are identical and only one of the corresponding properties (lod1Solid or lod1MultiSurface) must be used.

In LOD2 and higher levels of detail, the exterior shell of a building is not only represented geometrically as gml:Solid geometry and/or a gml:MultiSurface geometry, but it can also be composed of semantic objects. The base class for all objects semantically structuring the building shell is _BoundarySurface (cf. ), which is associated with a gml:MultiSurface geometry. If in a building model there is both a geometric representation of the exterior shell as volume or surface model and a semantic representation by means of thematic _BoundarySurfaces, the geometric representation must not explicitly define the geometry, but has to reference the corresponding geometry components of the gml:MultiSurface of the _BoundarySurface elements.

Semantic themes of the class _AbstractBuilding.

Geometric / semantic theme	Property type	LOD0	LOD1	LOD2	LOD3	LOD4
Building footprint and roof edge	gml:MultiSurfaceType	•
Volume part of the building shell	gml:SolidType		•	•	•	•
Surface part of the building shell	gml:MultiSurfaceType		•	•	•	•
Terrain intersection curve	gml:MultiCurveType		•	•	•	•
Curve part of the building shell	gml:MultiCurveType			•	•	•
Building parts	BuildingPartType		•	•	•	•
Boundary surfaces ()	AbstractBoundarySurfaceType			•	•	•
Outer building installations ()	BuildingInstallationType			•	•	•
Openings ()	AbstractOpeningType				•	•
Rooms ()	RoomType					•
Interior building installations ()	IntBuildingInstallationType					•

Apart from BuildingParts, smaller features of the building (“outer building installations”) can also strongly affect the building characteristic. These features are modelled by the class BuildingInstallation (cf. ). Typical candidates for this class are chimneys (see. ), dormers (see ), balconies, outer stairs, or antennas. BuildingInstallations may only be included in LOD2 models, if their extents exceed the proposed minimum dimensions as specified in . For the geometrical representation of the class BuildingInstallation, an arbitrary geometry object from the GML subset shown in can be used.

The class _AbstractBuilding has no additional properties for LOD3. Besides the higher requirements on geometric precision and smaller minimum dimensions, the main difference of LOD2 and LOD3 buildings concerns the class _BoundarySurface (cf. ). In LOD3, openings in a building corresponding with windows or doors (see ) are modelled by the abstract class _Opening and the derived subclasses Window and Door (cf. ).

With respect to the exterior building shell, the LOD4 data model is identical to that of LOD3. But LOD4 provides the possibility to model the interior structure of a building with the classes IntBuildingInstallation and Room (cf. ).

Each Building or BuildingPart feature may be assigned zero or more addresses using the address property. The corresponding AddressPropertyType is defined within the CityGML core module (cf. ).

AbstractBoundarySurfaceType, _BoundarySurface<xs:complexType name="AbstractBoundarySurfaceType" abstract="true"> <xs:complexContent> <xs:extension base="core:AbstractCityObjectType"> <xs:sequence> <xs:element name="lod2MultiSurface" type="gml:MultiSurfacePropertyType" minOccurs="0"/> <xs:element name="lod3MultiSurface" type="gml:MultiSurfacePropertyType" minOccurs="0"/> <xs:element name="lod4MultiSurface" type="gml:MultiSurfacePropertyType" minOccurs="0"/> <xs:element name="opening" type="OpeningPropertyType" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="_GenericApplicationPropertyOfBoundarySurface" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================== --> <xs:element name="_BoundarySurface" type="AbstractBoundarySurfaceType" abstract="true" substitutionGroup="core:_CityObject"/> <!-- ========================================================================================== --> <xs:element name="_GenericApplicationPropertyOfBoundarySurface" type="xs:anyType" abstract="true"/>

_BoundarySurface is the abstract base class for several thematic classes, structuring the exterior shell of a building as well as the visible surfaces of rooms and both outer and interior building installations. It is a subclass of _CityObject and thus inherits all properties like the GML3 standard feature properties (gml:name etc.) and the CityGML specific properties like ExternalReferences. From _BoundarySurface, the thematic classes RoofSurface, WallSurface, GroundSurface, OuterCeilingSurface, OuterFloorSurface, ClosureSurface, FloorSurface, InteriorWallSurface, and CeilingSurface are derived. The thematic classification of building surfaces is illustrated in (outer building shell) and (additional interior surfaces) and subsequently specified.

For each LOD between 2 and 4, the geometry of a _BoundarySurface may be defined by a different gml:MultiSurface geometry.

In LOD3 and LOD4, a _BoundarySurface may contain _Openings (cf. ) like doors and windows. If the geometric location of _Openings topologically lies within a surface component (e.g. gml:Polygon) of the gml:MultiSurface geometry, these _Openings must be represented as holes within that surface. A hole is represented by an interior ring within the corresponding surface geometry object. According to GML3, the points have to be specified in reverse order (exterior boundaries counter-clockwise and interior boundaries clockwise when looking in opposite direction of the surface’s normal vector). If such an opening is sealed by a Door, a Window, or a ClosureSurface, their outer boundary may consist of the same points as the inner ring (denoting the hole) of the surrounding surface. The embrasure surfaces of an Opening belong to the relevant adjacent _BoundarySurface. If, for example a door seals the Opening, the embrasure surface on the one side of the door belongs to the InteriorWallSurface and on the other side to the WallSurface ( on the right).

Examples of the classification of _BoundarySurfaces of the outer building shell (source: Karlsruhe Institute of Technology (KIT))

Classification of BoundarySurfaces (left), in particular for Openings (right) (graphic: IGG Uni Bonn).

GroundSurfaceType, GroundSurface<xs:complexType name="GroundSurfaceType"> <xs:complexContent> <xs:extension base="AbstractBoundarySurfaceType"> <xs:sequence> <xs:element ref="_GenericApplicationPropertyOfGroundSurface" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================= --> <xs:element name="GroundSurface" type="GroundSurfaceType" substitutionGroup="_BoundarySurface"/> <!-- ========================================================================================= --> <xs:element name="_GenericApplicationPropertyOfGroundSurface" type="xs:anyType" abstract="true"/>

The ground plate of a building or building part is modelled by the class GroundSurface. The polygon defining the ground plate is congruent with the building’s footprint. However, the surface normal of the ground plate is pointing downwards.

OuterCeilingSurfaceType, OuterCeilingSurface<xs:complexType name="OuterCeilingSurfaceType"> <xs:complexContent> <xs:extension base="AbstractBoundarySurfaceType"> <xs:sequence> <xs:element ref="_GenericApplicationPropertyOfOuterCeilingSurface" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================== --> <xs:element name="OuterCeilingSurface" type="OuterCeilingSurfaceType" substitutionGroup="_BoundarySurface"/> <!-- ========================================================================================== --> <xs:element name="_GenericApplicationPropertyOfOuterCeilingSurface" type="xs:anyType" abstract="true"/>

A mostly horizontal surface belonging to the outer building shell and having the orientation pointing downwards can be modeled as an OuterCeilingSurface. Examples are the visible part of the ceiling of a loggia or the ceiling of a passage.

WallSurfaceType, WallSurface<xs:complexType name="WallSurfaceType"> <xs:complexContent> <xs:extension base="AbstractBoundarySurfaceType"> <xs:sequence> <xs:element ref="_GenericApplicationPropertyOfWallSurface" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================= --> <xs:element name="WallSurface" type="WallSurfaceType" substitutionGroup="_BoundarySurface"/> <!-- ========================================================================================= --> <xs:element name="_GenericApplicationPropertyOfWallSurface" type="xs:anyType" abstract="true"/>

All parts of the building facade belonging to the outer building shell can be modelled by the class WallSurface.

OuterFloorSurfaceType, OuterFloorSurface<xs:complexType name="OuterFloorSurfaceType"> <xs:complexContent> <xs:extension base="AbstractBoundarySurfaceType"> <xs:sequence> <xs:element ref="_GenericApplicationPropertyOfOuterFloorSurface" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================== --> <xs:element name="OuterFloorSurface" type="OuterFloorSurfaceType" substitutionGroup="_BoundarySurface"/> <!-- ========================================================================================== --> <xs:element name="_GenericApplicationPropertyOfOuterFloorSurface" type="xs:anyType" abstract="true"/>

A mostly horizontal surface belonging to the outer building shell and with the orientation pointing upwards can be modeled as an OuterFloorSurface. An example is the floor of a loggia.

RoofSurfaceType, RoofSurface<xs:complexType name="RoofSurfaceType"> <xs:complexContent> <xs:extension base="AbstractBoundarySurfaceType"> <xs:sequence> <xs:element ref="_GenericApplicationPropertyOfRoofSurface" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================== --> <xs:element name="RoofSurface" type="RoofSurfaceType" substitutionGroup="_BoundarySurface"/> <!-- ========================================================================================== --> <xs:element name="_GenericApplicationPropertyOfRoofSurface" type="xs:anyType" abstract="true"/>

The major roof parts of a building or building part are expressed by the class RoofSurface. Secondary parts of a roof with a specific semantic meaning like dormers or chimneys should be modelled as BuildingInstallation.

ClosureSurfaceType, ClosureSurface<xs:complexType name="ClosureSurfaceType"> <xs:complexContent> <xs:extension base="AbstractBoundarySurfaceType"> <xs:sequence> <xs:element ref="_GenericApplicationPropertyOfClosureSurface" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================= --> <xs:element name="ClosureSurface" type="ClosureSurfaceType" substitutionGroup="_BoundarySurface"/> <!-- ========================================================================================= --> <xs:element name="_GenericApplicationPropertyOfClosureSurface" type="xs:anyType" abstract="true"/>

An opening in a building not filled by a door or window can be sealed by a virtual surface called ClosureSurface (cf. ). Hence, buildings with open sides like a barn or a hangar, can be virtually closed in order to be able to compute their volume. ClosureSurfaces are also used in the interior building model. If two rooms with a different function (e.g. kitchen and living room) are directly connected without a separating door, a ClosureSurface should be used to separate or connect the volumes of both rooms.

FloorSurfaceType, FloorSurface<xs:complexType name="FloorSurfaceType"> <xs:complexContent> <xs:extension base="AbstractBoundarySurfaceType"> <xs:sequence> <xs:element ref="_GenericApplicationPropertyOfFloorSurface" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================= --> <xs:element name="FloorSurface" type="FloorSurfaceType" substitutionGroup="_BoundarySurface"/> <!-- ========================================================================================= --> <xs:element name="_GenericApplicationPropertyOfFloorSurface" type="xs:anyType" abstract="true"/>

The class FloorSurface must only be used in the LOD4 interior building model for modelling the floor of a room.

InteriorWallSurfaceType, InteriorWallSurface<xs:complexType name="FloorSurfaceType"> <xs:complexContent> <xs:extension base="AbstractBoundarySurfaceType"> <xs:sequence> <xs:element ref="_GenericApplicationPropertyOfFloorSurface" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================= --> <xs:element name="FloorSurface" type="FloorSurfaceType" substitutionGroup="_BoundarySurface"/> <!-- ========================================================================================= --> <xs:element name="_GenericApplicationPropertyOfFloorSurface" type="xs:anyType" abstract="true"/>

The class InteriorWallSurface must only be used in the LOD4 interior building model for modelling the visible surfaces of the room walls.

CeilingSurfaceType, CeilingSurface<xs:complexType name="CeilingSurfaceType"> <xs:complexContent> <xs:extension base="AbstractBoundarySurfaceType"> <xs:sequence> <xs:element ref="_GenericApplicationPropertyOfCeilingSurface" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================= --> <xs:element name="CeilingSurface" type="CeilingSurfaceType" substitutionGroup="_BoundarySurface"/> <!-- ========================================================================================= --> <xs:element name="_GenericApplicationPropertyOfCeilingSurface" type="xs:anyType" abstract="true"/>

The class CeilingSurface must only be used in the LOD4 interior building model for modelling the ceiling of a room.

RoomType, Room<xs:complexType name="RoomType"> <xs:complexContent> <xs:extension base="core:AbstractCityObjectType"> <xs:sequence> <xs:element name="class" type="gml:CodeType" minOccurs="0"/> <xs:element name="function" type="gml:CodeType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="usage" type="gml:CodeType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="lod4Solid" type="gml:SolidPropertyType" minOccurs="0"/> <xs:element name="lod4MultiSurface" type="gml:MultiSurfacePropertyType" minOccurs="0"/> <xs:element name="boundedBy" type="BoundarySurfacePropertyType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="interiorFurniture" type="InteriorFurniturePropertyType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="roomInstallation" type="IntBuildingInstallationPropertyType" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="_GenericApplicationPropertyOfRoom" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================= --> <xs:element name="Room" type="RoomType" substitutionGroup="core:_CityObject"/> <!-- ========================================================================================= --> <xs:element name="_GenericApplicationPropertyOfRoom" type="xs:anyType" abstract="true"/>

A Room is a semantic object for modelling the free space inside a building and should be uniquely related to exactly one building or building part object. It should be closed (if necessary by using ClosureSurfaces) and the geometry normally will be described by a solid (lod4Solid). However, if the topological correctness of the boundary cannot be guaranteed, the geometry can alternatively be given as a MultiSurface (lod4MultiSurface). The surface normals of the outer shell of a GML solid must point outwards. This is important to consider when Room surfaces should be assigned Appearances. In this case, textures and colors must be placed on the backside of the corresponding surfaces in order to be visible from the inside of the room.

In addition to the geometrical representation, different parts of the visible surface of a room can be modelled by specialised BoundarySurfaces (FloorSurface, CeilingSurface, InteriorWallSurface, and ClosureSurface cf. ).

A special task is the modelling of passages between adjacent rooms. The room solids are topologically connected by the surfaces representing hatches, doors or closure surfaces that seal open doorways. Rooms are defined as being adjacent, if they have common _Openings or ClosureSurfaces. The surface that represents the opening geometrically is part of the boundaries of the solids of both rooms, or the opening is referenced by both rooms on the semantic level. This adjacency implies an accessibility graph, which can be employed to determine the spread of e.g. smoke or gas, but which can also be used to compute escape routes using classical shortest path algorithms (see ).

Accessibility graph derived from topological adjacencies of room surfaces (graphic: IGG Uni Bonn).

BuildingFurnitureType, BuildingFurniture<xs:complexType name="BuildingFurnitureType"> <xs:complexContent> <xs:extension base="core:AbstractCityObjectType"> <xs:sequence> <xs:element name="class" type="gml:CodeType" minOccurs="0"/> <xs:element name="function" type="gml:CodeType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="usage" type="gml:CodeType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="lod4Geometry" type="gml:GeometryPropertyType" minOccurs="0"/> <xs:element name="lod4ImplicitRepresentation" type="core:ImplicitRepresentationPropertyType" minOccurs="0"/> <xs:element ref="_GenericApplicationPropertyOfBuildingFurniture" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================= --> <xs:element name="BuildingFurniture" type="BuildingFurnitureType" substitutionGroup="core:_CityObject"/> <!-- ========================================================================================= --> <xs:element name="_GenericApplicationPropertyOfBuildingFurniture" type="xs:anyType" abstract="true"/>

Rooms may have BuildingFurnitures and IntBuildingInstallations. A BuildingFurniture is a movable part of a room, such as a chair or furniture. A BuildingFurniture object should be uniquely related to exactly one room object. Its geometry may be represented by an explicit geometry or an ImplicitGeometry object. Following the concept of ImplicitGeometry the geometry of a prototype building furniture is stored only once in a local coordinate system and referenced by other building furniture features (see ).

IntBuildingInstallationType, IntBuildingInstallation<xs:complexType name="IntBuildingInstallationType"> <xs:complexContent> <xs:extension base="core:AbstractCityObjectType"> <xs:sequence> <xs:element name="class" type="gml:CodeType" minOccurs="0"/> <xs:element name="function" type="gml:CodeType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="usage" type="gml:CodeType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="lod4Geometry" type="gml:GeometryPropertyType" minOccurs="0"/> <xs:element name="lod4ImplicitRepresentation" type="core:ImplicitRepresentationPropertyType" minOccurs="0"/> <xs:element name="boundedBy" type="BoundarySurfacePropertyType" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="_GenericApplicationPropertyOfIntBuildingInstallation" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================= --> <xs:element name="IntBuildingInstallation" type="IntBuildingInstallationType" substitutionGroup="core:_CityObject"/> <!-- ========================================================================================= --> <xs:element name="_GenericApplicationPropertyOfIntBuildingInstallation" type="xs:anyType" abstract="true"/>

An IntBuildingInstallation is an object inside a building with a specialised function or semantic meaning. In contrast to BuildingFurniture, IntBuildingInstallations are permanently attached to the building structure and cannot be moved. Typical examples are interior stairs, railings, radiators or pipes. Objects of the class IntBuildingInstallation can either be associated with a room (class Room), or with the complete building / building part (class _AbstractBuilding, cf. ). However, they should be uniquely related to exactly one room or one building / building part object. An IntBuildingInstallation optionally has attributes class, function and usage. The attribute class, which can only occur once, represents a general classification of the internal building component. With the attributes function and usage, nominal and real functions of a building installation can be described. For all three attributes the list of feasible values can be specified in a code list. For the geometrical representation of an IntBuildingInstallation, an arbitrary geometry object from the GML subset shown in can be used. Alternatively, the geometry may be given as ImplicitGeometry object. Following the concept of ImplicitGeometry the geometry of a prototype interior building installation is stored only once in a local coordinate system and referenced by other interior building installation features (see ). The visible surfaces of an interior building installation can be semantically classified using the concept of boundary surfaces (cf. ).

The LOD1 model of the Campus North of the Karlruhe Institute of Technology (KIT) shown in consists of 596 buildings and 187 building parts. The footprint geometries of the buildings are taken from a cadastral information system and extruded by a given height. Buildings with a unique identifier and a single height value are modeled as one building (bldg:Building). Buildings having a unique identifier but different height values are modeled as one building (bldg:Building) with one or more building parts (bldg:BuildingPart). Both buildings and building parts have solid geometries and their height values are additionally represented as thematic attribute (bldg:measuredHeight). shows an aerial photograph of the KIT Campus North (left) and the CityGML LOD1 model (right).

LOD1 model of the KIT Campus North (source: Karlsruhe Institute of Technology (KIT)).

An example for a fully textured LOD2 building model is given in which shows the Bernhardus church located in the city of Karlsruhe, Germany. On the left side of , a photograph of the church in real world is shown whereas the CityGML building model of the church with photorealistic textures is illustrated on the right. The model is bounded by a ground surface, several wall and roof surfaces. The railing above the church clock is modeled as a building installation (BuildingInstallation).

Textured LOD2 model of the Bernhardus church in Karlsruhe (source: Karlsruhe Institute of Technology (KIT), courtesy of City of Karlsruhe).

The model shown in was derived from a 3D CAD model generated during the planning phase of the building. On the left side of , the building is shown whereas on the right side the LOD3 model is presented. The building itself is bounded by wall surfaces, roof surfaces and a ground surface. Doors and windows are modeled including reveals. According to the cadaster data, the car port next to the building is not part of the building. Therefore the car port, the balcony and the chimney are modeled as building installations (BuildingInstallation). The model also contains the terrain intersection curve (lod3TerrainIntersection) as planned by the architect.

In order to determine the volume of the building, the geometries of all boundary surfaces, including doors and windows, are referenced by the building solid (lod3Solid) using the XLink mechanism. Consequently, the roof surfaces are split into surfaces representing the roof itself and surfaces representing the roof overhangs.

Example of a building modeled in the Level of Detail 3. The chimney, the balcony and the car port are modeled as building installations (source: Karlsruhe Institute of Technology (KIT), courtesy of Franz-Josef Kaiser).

The tunnel model is closely related to the building model. It supports the representation of thematic and spatial aspects of tunnels and tunnel parts in four levels of detail, LOD1 to LOD4. The tunnel model of CityGML is defined by the thematic extension module Tunnel (cf. ). provides examples of tunnel models for each LOD.

Examples for tunnel models in LOD1 (upper left), LOD2 (upper right), LOD3 (lower left) and LOD4 (lower right) (source: Google 3D warehouse).

The UML diagram of the tunnel model is shown in . The XML schema definition is attached in . The pivotal class of the model is _AbstractTunnel, which is a subclass of the thematic class _Site (and transitively of the root class _CityObject). _AbstractTunnel is specialized either to a Tunnel or to a TunnelPart. Since an _AbstractTunnel consists of TunnelParts, which again are AbstractTunnels, an aggregation hierarchy of arbitrary depth may be realized. As subclass of the root class _CityObject, an AbstractTunnel inherits all properties from _CityObject like the GML3 standard feature properties (gml:name etc.) and the CityGML specific properties like ExternalReferences (cf. ). Further properties not explicitly covered by _AbstractTunnel may be modelled as generic attributes provided by the CityGML Generics module (cf. ) or using the CityGML Application Domain Extension mechanism (cf. ).

Both classes Tunnel and TunnelPart inherit the attributes of _AbstractTunnel: the class of the tunnel, the function, the usage, the year of construction and the year of demolition. In contrast to _AbstractBuilding, Address features cannot be assigned to _AbstractTunnel.

UML diagram of CityGML’s tunnel model. Prefixes are used to indicate XML namespaces associated with model elements. Element names without a prefix are defined within the CityGML Tunnel module.

The geometric representation and semantic structure of an _AbstractTunnel is shown in . The model is successively refined from LOD1 to LOD4. Therefore, not all components of a tunnel model are represented equally in each LOD and not all aggregation levels are allowed in each LOD. In CityGML, all object classes are associated to the LODs with respect to the proposed minimum acquisition criteria for each LOD (cf. ). An object can be represented simultaneously in different LODs by providing distinct geometries for the corresponding LODs.

Similar to the building and brigde models (cf. and ), only the outer shell of a tunnel is represented in LOD1 — 3, which is composed of the tunnel’s boundary surfaces to the surrounding earth, water, or outdoor air. The interior of a tunnel may only be modeled in LOD4. Although the interior built environment is especially relevant for subsurface objects like tunnels or underground buildings, CityGML employs a consistent LOD concept for all thematic modules. If, in contrast, the representation of the interior of subsurface objects would be possible in all LODs, the LOD concept for subsurface objects would have to substantially differ from the LOD concept for aboveground objects. This would require the precise definition of a “transition surface” which delimits the scope of both LOD concepts. Furthermore, features being partially above and below ground would have to be split into an above-ground part (modeled according to the aboveground LOD concept) and a subsurface part (modeled according to the subsurface LOD concept). However, such a splitting violates the CityGML concept of unity of features and would not be feasible in many cases where the transition between above and below ground is often not precisely known or depends on (the LOD of) the terrain model. Hence, CityGML applies a single and consistent LOD concept to both aboveground and subsurface objects. As a consequence, penetrations between a tunnel and objects inside this tunnel (e.g., roads and railways) may occur in LOD1 — 3.

In LOD1, a tunnel model consists of a geometric representation of the tunnel volume. Optionally, a MultiCurve representing the TerrainIntersectionCurve (cf. ) can be specified. The geometric representation is refined in LOD2 by additional MultiSurface and MultiCurve geometries.

In LOD2 and higher LODs the outer structure of a tunnel can also be differentiated semantically by the classes _BoundarySurface and TunnelInstallation. A boundary surface is a part of the tunnel’s exterior shell with a special function like wall (WallSurface), roof (RoofSurface), ground plate (GroundSurface), outer floor (OuterFloorSurface), outer ceiling (OuterCeilingSurface) or ClosureSurface. The TunnelInstallation class is used for tunnel elements like outer stairs, strongly affecting the outer appearance of a tunnel. A TunnelInstallation may have the attributes class, function and usage (see ).

In LOD3, the openings in _BoundarySurface objects (doors and windows) can be represented as thematic objects.

In LOD4, the highest level of resolution, also the interior of a tunnel, composed of several hollow spaces, is represented in the tunnel model by the class HollowSpace. This enlargement allows a virtual accessibility of tunnels, e.g. for driving through a tunnel, for simulating disaster management or for presenting the light illumination within a tunnel. The aggregation of hollow spaces according to arbitrary, user defined criteria (e.g. for defining the hollow spaces corresponding to horizontal or vertical sections) is achieved by employing the general grouping concept provided by CityGML (cf. ). Interior installations of a tunnel, i.e. objects within a tunnel which (in contrast to furniture) cannot be moved, are represented by the class IntTunnelInstallation. If an installation is attached to a specific hollow space (e.g. lamps, ventilator), they are associated with the HollowSpace class, otherwise (e.g. pipes) with _AbstractTunnel. A HollowSpace may have the attributes class, function and usage whose possible values can be enumerated in code lists (, ). The class attribute allows a general classification of hollow spaces, e.g. commercial or private rooms, and occurs only once. The function attribute is intended to express the main purpose of the hollow space, e.g. control area, installation space, storage space. The attribute usage can be used if the way the object is actually used differs from the function. Both attributes can occur multiple times.

The visible surface of a hollow space is represented geometrically as a Solid or MultiSurface. Semantically, the surface can be structured into specialised _BoundarySurfaces, representing floor (FloorSurface), ceiling (CeilingSurface), and interior walls (InteriorWallSurface). Hollow space furniture, like movable equipment in control areas, can be represented in the CityGML tunnel model with the class TunnelFurniture. A TunnelFurniture may have the attributes class, function and usage.

XML namespace

The XML namespace of the CityGML Tunnel module is identified by the Uniform Resource Identifier (URI) . Within the XML Schema definition of the Tunnel module, this URI is also used to identify the default namespace.

TunnelType, Tunnel<xs:complexType name="TunnelType"> <xs:complexContent> <xs:extension base="AbstractTunnelType"> <xs:sequence> <xs:element ref="_GenericApplicationPropertyOfTunnel" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================== --> <xs:element name="Tunnel" type="TunnelType" substitutionGroup="_AbstractTunnel"/> <!-- ========================================================================================== --> <xs:element name="_GenericApplicationPropertyOfTunnel" type="xs:anyType" abstract="true"/>

The Tunnel class is one of the two subclasses of _AbstractTunnel. If a tunnel only consists of one (homogeneous) part, this class shall be used. A tunnel composed of structural segments, for example tunnel entrance and subway, has to be separated into one tunnel having one or more additional TunnelPart (see ). The geometry and non-spatial properties of the central part of the tunnel should be represented in the aggregating Tunnel feature.

TunnelPartType, TunnelPart<xs:complexType name="TunnelPartType"> <xs:complexContent> <xs:extension base="AbstractTunnelType"> <xs:sequence> <xs:element ref="_GenericApplicationPropertyOfTunnelPart" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================== --> <xs:element name="TunnelPart" type="TunnelPartType" substitutionGroup="_AbstractTunnel"/> <!-- ========================================================================================== --> <xs:element name="_GenericApplicationPropertyOfTunnelPart" type="xs:anyType" abstract="true"/>

If sections of a tunnel differ in geometry and / or attributes, the tunnel can be separated into parts (see ). Like Tunnel, the class TunnelPart is derived from _AbstractTunnel and inherites all attributes of _AbstractTunnel. A TunnelPart object should be uniquely related to exactly one tunnel or tunnel part object.

Example of a tunnel modeled with two tunnel parts (source: Helmut Stracke).

AbstractTunnelType, _AbstractTunnel<xs:complexType name="AbstractTunnelType"> <xs:complexContent> <xs:extension base="core:AbstractSiteType"> <xs:sequence> <xs:element name="class" type="gml:CodeType" minOccurs="0"/> <xs:element name="function" type="gml:CodeType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="usage" type="gml:CodeType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="yearOfConstruction" type="xs:gYear" minOccurs="0"/> <xs:element name="yearOfDemolition" type="xs:gYear" minOccurs="0"/> <xs:element name="lod1Solid" type="gml:SolidPropertyType" minOccurs="0"/> <xs:element name="lod1MultiSurface" type="gml:MultiSurfacePropertyType" minOccurs="0"/> <xs:element name="lod1TerrainIntersection" type="gml:MultiCurvePropertyType" minOccurs="0"/> <xs:element name="lod2Solid" type="gml:SolidPropertyType" minOccurs="0"/> <xs:element name="lod2MultiSurface" type="gml:MultiSurfacePropertyType" minOccurs="0"/> <xs:element name="lod2MultiCurve" type="gml:MultiCurvePropertyType" minOccurs="0"/> <xs:element name="lod2TerrainIntersection" type="gml:MultiCurvePropertyType" minOccurs="0"/> <xs:element name="outerTunnelInstallation" type="TunnelInstallationPropertyType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="interiorTunnelInstallation" type="IntTunnelInstallationPropertyType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="boundedBy" type="BoundarySurfacePropertyType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="lod3Solid" type="gml:SolidPropertyType" minOccurs="0"/> <xs:element name="lod3MultiSurface" type="gml:MultiSurfacePropertyType" minOccurs="0"/> <xs:element name="lod3MultiCurve" type="gml:MultiCurvePropertyType" minOccurs="0"/> <xs:element name="lod3TerrainIntersection" type="gml:MultiCurvePropertyType" minOccurs="0"/> <xs:element name="lod4Solid" type="gml:SolidPropertyType" minOccurs="0"/> <xs:element name="lod4MultiSurface" type="gml:MultiSurfacePropertyType" minOccurs="0"/> <xs:element name="lod4MultiCurve" type="gml:MultiCurvePropertyType" minOccurs="0"/> <xs:element name="lod4TerrainIntersection" type="gml:MultiCurvePropertyType" minOccurs="0"/> <xs:element name="interiorHollowSpace" type="InteriorHollowSpacePropertyType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="consistsOfTunnelPart" type="TunnelPartPropertyType" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="_GenericApplicationPropertyOfAbstractTunnel" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================== --> <xs:element name="_AbstractTunnel" type="AbstractTunnelType" abstract="true" substitutionGroup="core:_Site"/> <!-- ========================================================================================== --> <xs:element name="_GenericApplicationPropertyOfAbstractTunnel" type="xs:anyType" abstract="true"/>

The abstract class _AbstractTunnel contains properties for tunnel attributes, purely geometric representations, and geometric/semantic representations of the tunnel or tunnel part in different levels of detail. The attributes describe:

1. The classification of the tunnel or tunnel part (class), the different functions (function), and the usage (usage). The type of these attributes is gml:CodeType and the values can be specified in separate code lists.

2. The year of construction (yearOfConstruction) and the year of demolition (yearOfDemolition) of the tunnel or tunnel part. The yearOfConstruction is the year of completion of the tunnel. The yearOfDemolition is the year when the demolition of the tunnel was completed. The date (year) refer to real world time (e.g. 2011).

Spanning the different levels of detail, the tunnel model differs in the complexity and granularity of the geometric representation and the thematic structuring of the model into components with a special semantic meaning. This is illustrated in , showing the same tunnel in four different LODs. Some properties of the class _AbstractTunnel are also associated with certain LODs.

Tunnel model in LOD1 — LOD4 (source: Karlsruhe Institute of Technology (KIT)).

shows the correspondence of the different geometric and semantic themes of the tunnel model to LODs. In each LOD, the volume of a tunnel can be expressed by a gml:Solid geometry and/or a gml:MultiSurface geometry. The definition of a 3D Terrain Intersection Curve (TIC), used to integrate tunnels from different sources with the Digital Terrain Model, is also possible in all LODs. The TIC can — but does not have to — build closed rings around the tunnel or tunnel parts.

Semantic themes of the class _AbstractTunnel.

Geometric / semantic theme	Property type	LOD1	LOD2	LOD3	LOD4
Volume part of the tunnel shell	gml:SolidType	•	•	•	•
Surface part of the tunnel shell	gml:MultiSurfaceType	•	•	•	•
Terrain intersection curve	gml:MultiCurveType	•	•	•	•
Curve part of the tunnel shell	gml:MultiCurveType		•	•	•
Tunnel parts	TunnelPartType	•	•	•	•
Boundary surfaces ()	AbstractBoundarySurfaceType		•	•	•
Outer tunnel installations ()	TunnelInstallationType		•	•	•
Openings	AbstractOpeningType			•	•
Hollow spaces ()	HollowSpaceType				•
Interior tunnel installations	IntTunnelInstallationType				•

<xs:complexType name="AbstractBoundarySurfaceType" abstract="true"> <xs:complexContent> <xs:extension base="core:AbstractCityObjectType"> <xs:sequence> <xs:element name="lod2MultiSurface" type="gml:MultiSurfacePropertyType" minOccurs="0"/> <xs:element name="lod3MultiSurface" type="gml:MultiSurfacePropertyType" minOccurs="0"/> <xs:element name="lod4MultiSurface" type="gml:MultiSurfacePropertyType" minOccurs="0"/> <xs:element name="opening" type="OpeningPropertyType" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="_GenericApplicationPropertyOfBoundarySurface" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================== --> <xs:element name="_BoundarySurface" type="AbstractBoundarySurfaceType" abstract="true" substitutionGroup="core:_CityObject"/> <!-- ========================================================================================== --> <xs:element name="_GenericApplicationPropertyOfBoundarySurface" type="xs:anyType" abstract="true"/>

_BoundarySurface is the abstract base class for several thematic classes, structuring the exterior shell of a tunnel as well as the visible surface of hollow spaces and both outer and interior tunnel installations. It is a subclass of _CityObject and thus inherits all properties like the GML3 standard feature properties (gml:name etc.) and the CityGML specific properties like ExternalReferences. From _BoundarySurface, the thematic classes RoofSurface, WallSurface, GroundSurface, OuterCeilingSurface, OuterFloorSurface, ClosureSurface, FloorSurface, InteriorWallSurface, and CeilingSurface are derived. The thematic classification of tunnel surfaces is illustrated in for different types of tunnel cross sections and are specified below.

Examples for the use of boundary surfaces for tunnels with different cross sections. WallSurface, RoofSurface, GroundSurface, OuterCeilingSurface and OuterFloorSurface are available in LOD2 - 4, whereas InteriorWallSurface, FloorSurface and CeilingSurface may only be used in LOD4 to model the interior boundary surfaces of a hollow space.

For each LOD between 2 and 4, the geometry of a _BoundarySurface may be defined by a different gml:MultiSurface geometry. Starting from LOD3, a _BoundarySurface may contain _Openings (cf. ) like doors and windows. If the geometric location of openings topologically lies within a surface component (e.g. gml:Polygon) of the gml:MultiSurface geometry, these openings must be represented as holes within that surface. A hole is represented by an interior ring within the corresponding surface geometry object. According to GML3, the points have to be specified in reverse order (exterior boundaries counter-clockwise and interior boundaries clockwise when looking in opposite direction of the surface’s normal vector). If such an opening is sealed by a Door or a Window, their outer boundary may consist of the same points as the inner ring (denoting the hole) of the surrounding surface. The embrasure surfaces of an opening belong to the relevant adjacent _BoundarySurface. If, for example a door seals the opening, the embrasure surface on the one side of the door belongs to the InteriorWallSurface and on the other side to the WallSurface (cf. right part of for the same situation in a building model).

GroundSurfaceType, GroundSurface<xs:complexType name="GroundSurfaceType"> <xs:complexContent> <xs:extension base="AbstractBoundarySurfaceType"> <xs:sequence> <xs:element ref="_GenericApplicationPropertyOfGroundSurface" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================== --> <xs:element name="GroundSurface" type="GroundSurfaceType" substitutionGroup="_BoundarySurface"/> <!-- ========================================================================================== --> <xs:element name="_GenericApplicationPropertyOfGroundSurface" type="xs:anyType" abstract="true"/>

The ground plate of a tunnel or tunnel part is modelled by the class GroundSurface. Usually a GroundSurface is a boundary surface between the tunnel and the surrounding earth (soil, rock etc.) or water.

OuterCeilingSurfaceType, OuterCeilingSurface<xs:complexType name="OuterCeilingSurfaceType"> <xs:complexContent> <xs:extension base="AbstractBoundarySurfaceType"> <xs:sequence> <xs:element ref="_GenericApplicationPropertyOfOuterCeilingSurface" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================== --> <xs:element name="OuterCeilingSurface" type="OuterCeilingSurfaceType" substitutionGroup="_BoundarySurface"/> <!-- ========================================================================================== --> <xs:element name="_GenericApplicationPropertyOfOuterCeilingSurface" type="xs:anyType" abstract="true"/>

A mostly horizontal surface belonging to the outer tunnel shell and with the orientation pointing downwards can be modeled as an OuterCeilingSurface. Examples are the visible part of an avalanche protector or the boundary surface between the tunnel and the surrounding earth or water.

WallSurfaceType, WallSurface<xs:complexType name="WallSurfaceType"> <xs:complexContent> <xs:extension base="AbstractBoundarySurfaceType"> <xs:sequence> <xs:element ref="_GenericApplicationPropertyOfWallSurface" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================== --> <xs:element name="WallSurface" type="WallSurfaceType" substitutionGroup="_BoundarySurface"/> <!-- ========================================================================================== --> <xs:element name="_GenericApplicationPropertyOfWallSurface" type="xs:anyType" abstract="true"/>

All parts of the tunnel facade belonging to the outer tunnel shell can be modelled by the class WallSurface. Usually a WallSurface is a boundary surface between the tunnel and the surrounding earth (soil, rock etc.) or water.

OuterFloorSurfaceType, OuterFloorSurface<xs:complexType name="OuterFloorSurfaceType"> <xs:complexContent> <xs:extension base="AbstractBoundarySurfaceType"> <xs:sequence> <xs:element ref="_GenericApplicationPropertyOfOuterFloorSurface" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================== --> <xs:element name="OuterFloorSurface" type="OuterFloorSurfaceType" substitutionGroup="_BoundarySurface"/> <!-- ========================================================================================== --> <xs:element name="_GenericApplicationPropertyOfOuterFloorSurface" type="xs:anyType" abstract="true"/>

A mostly horizontal surface belonging to the outer tunnel shell and with the orientation pointing upwards can be modeled as an OuterFloorSurface.

RoofSurfaceType, RoofSurface<xs:complexType name="RoofSurfaceType"> <xs:complexContent> <xs:extension base="AbstractBoundarySurfaceType"> <xs:sequence> <xs:element ref="_GenericApplicationPropertyOfRoofSurface" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================== --> <xs:element name="RoofSurface" type="RoofSurfaceType" substitutionGroup="_BoundarySurface"/> <!-- ========================================================================================== --> <xs:element name="_GenericApplicationPropertyOfRoofSurface" type="xs:anyType" abstract="true"/>

Boundary surfaces belonging to the outer tunnel shell and with the main purpose to protect the tunnel from above are expressed by the class RoofSurface. The orientation of these boundaries is mainly pointing upwards.

ClosureSurfaceType, ClosureSurface<xs:complexType name="ClosureSurfaceType"> <xs:complexContent> <xs:extension base="AbstractBoundarySurfaceType"> <xs:sequence> <xs:element ref="_GenericApplicationPropertyOfClosureSurface" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================== --> <xs:element name="ClosureSurface" type="ClosureSurfaceType" substitutionGroup="_BoundarySurface"/> <!-- ========================================================================================== --> <xs:element name="_GenericApplicationPropertyOfClosureSurface" type="xs:anyType" abstract="true"/>

Openings in tunnels or hollow spaces not filled by a door or a window can be sealed by a virtual surface called ClosureSurface (cf. ). For example, the doorways of tunnels can be modelled as ClosureSurface.

FloorSurfaceType, FloorSurface<xs:complexType name="FloorSurfaceType"> <xs:complexContent> <xs:extension base="AbstractBoundarySurfaceType"> <xs:sequence> <xs:element ref="_GenericApplicationPropertyOfFloorSurface" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================== --> <xs:element name="FloorSurface" type="FloorSurfaceType" substitutionGroup="_BoundarySurface"/> <!-- ========================================================================================== --> <xs:element name="_GenericApplicationPropertyOfFloorSurface" type="xs:anyType" abstract="true"/>

The class FloorSurface must only be used in the LOD4 interior tunnel model for modelling the floor of hollow spaces.

InteriorWallSurfaceType, InteriorWallSurface<xs:complexType name="InteriorWallSurfaceType"> <xs:complexContent> <xs:extension base="AbstractBoundarySurfaceType"> <xs:sequence> <xs:element ref="_GenericApplicationPropertyOfInteriorWallSurface" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================== --> <xs:element name="InteriorWallSurface" type="InteriorWallSurfaceType" substitutionGroup="_BoundarySurface"/> <!-- ========================================================================================== --> <xs:element name="_GenericApplicationPropertyOfInteriorWallSurface" type="xs:anyType" abstract="true"/>

The class InteriorWallSurface is only allowed to be used in the LOD4 interior tunnel model for modelling the visible wall surfaces of hollow spaces.

CeilingSurfaceType, CeilingSurface<xs:complexType name="CeilingSurfaceType"> <xs:extension base="AbstractBoundarySurfaceType"> <xs:sequence> <xs:element ref="_GenericApplicationPropertyOfCeilingSurface" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================== --> <xs:element name="CeilingSurface" type="CeilingSurfaceType" substitutionGroup="_BoundarySurface"/> <!-- ========================================================================================== --> <xs:element name="_GenericApplicationPropertyOfCeilingSurface" type="xs:anyType" abstract="true"/>

The class CeilingSurface is only allowed to be used in the LOD4 interior tunnel model for modelling the ceiling of hollow spaces.

The example in shows a pedestrian underpass in the city centre of Karlsruhe, Germany. On the left side of , a photo illustrates the real world situation. Both entrances of the underpass are marked in the photo by dashed rectangles. On the right side of the figure, the CityGML tunnel model is shown. The terrain surrounding the tunnel has been virtually cut out of model in order to visualize the entire tunnel with its subsurface body. The same underpass is illustrated in from a different perspective. The camera is positioned in front of the left entrance (black dashed rectangle in ) and pointing in the direction of the right entrance (white dashed rectangle in ). On the right side of , the tunnel model is shown from the same perspective. Again holes are cut in the terrain surface in order to make the subsurface part of the tunnel visible. An LOD1 representation of the nearby buildings is shown in the background of the model.

Example of a tunnel modeled in LOD3 (real situation on the left side; CityGML model on the right side) (source: Karlsruhe Institute of Technology (KIT), courtesy of City of Karlsruhe).

The same LOD3 tunnel shown from a different perspective. The camera is positioned in front of the left entrance and pointing in the direction of the right entrance. (real situation on the left side; CityGML model on the right side). The model on the right also includes an LOD1 representation of the nearby buildings in the background (painted in light brown) (source: Karlsruhe Institute of Technology (KIT), courtesy of City of Karlsruhe).

The model is subdivided into one Tunnel (the actual underpass) and two TunnelParts (both entrances). The tunnel and tunnel parts are bounded by GroundSurface, WallSurface, RoofSurface. ClosureSurface objects are used to virtually seal the tunnel entrances. For safety reasons each of the two entrances has railings which are modeled as TunnelInstallation. Due to the high geometrical accuracy and the semantic richness, the model is classified as LOD3.

The bridge model allows for the representation of the thematic, spatial and visual aspects of bridges and bridge parts in four levels of detail, LOD 1 — 4. The bridge model of CityGML is defined by the thematic extension module Bridge (cf. ). illustrates examples of bridge models in all LODs.

Examples for bridge models in LOD1 (upper left), LOD2 (upper right), LOD3 (lower left) and LOD4 (lower right) (source: Google 3D warehouse)

The bridge model was developed in analogy to the building model (cf. ) with regard to structure and attributes. The UML diagram of the bridge model is depicted in , and the XML schema definition is presented in .

UML diagram of the bridge model, part one.

A (movable or unmovable) bridge is represented by an object of the class Bridge. This class inherits its attributes and relations from the abstract base class _AbstractBridge. The spatial properties are defined by a solid for each of the four LODs (relations lod1Solid to lod4Solid). In analogy to the building model, the semantical as well as the geometrical richness increases from LOD1 (blocks model) to LOD3 (architectural model). Simple examples of bridges in each of those LODs are depicted in . Interior structures like rooms are dedicated to LOD4. To cover the case of bridge models where the topology does not satisfy the properties of a solid (essentially water tightness), a multi surface representation is allowed (lod1MultiSurface to lod4MultiSurface). The line where the bridge touches the terrain surface is represented by a terrain intersection curve, which is provided for each LOD (relations lod1TerrainIntersection to lod4TerrainIntersection). In addition to the solid representation of a bridge, linear characteristics like ropes or antennas can be specified geometrically by the lod1MultiCurve to lod4MultiCurve relations. If those characteristics shall be represented semantically, the features BridgeInstallation or BridgeConstructionElement can be used (see ). All relations to semantic objects and geometric properties are listed in .

Bridge model in LOD1 — LOD4. (source: Karlsruhe Institute of Technology (KIT))

The semantic attributes of an _AbstractBridge are class, function, usage and is_movable. The attribute class is used to classify bridges, e.g. to distinguish different construction types (cf. ). The attribute function allows representing the utilization of the bridge independently of the construction.Possiblevalues may be railway bridge, roadway bridge, pedestrian bridge, aqueduct, etc. The option to denote a usage which is divergent to one of the primary functions of the bridge (function) is given by the attribute usage. The type of these attributes is gml:CodeType, the values of which can be defined in code lists. The name of the bridge can be represented by the gml:name attribute, which is inherited from the base class gml: _GML via the classes gml: _Feature, _CityObject, and _Site. Each Bridge or BridgePart feature may be assigned zero or more addresses using the address property. The corresponding AddressPropertyType is defined within the CityGML core module (cf. ).

The boolean attribute is_movable is defined to specify whether a bridge is movable or not. The modeling of the geometric aspects of the movement is delayed to later versions of this standard. Some types of movable bridges are depicted in .

Examples for movable bridges (source: ISO 6707).

Examples for different types of bridges.

XML namespace

The XML namespace of the CityGML Bridge module is identified by the Uniform Resource Identifier (URI) . Within the XML Schema definition of the Bridge module, this URI is also used to identify the default namespace.

BridgeConstructionElementType, BridgeConstructionElement<xs:complexType name="BridgeConstructionElementType"> <xs:complexContent> <xs:extension base="core:AbstractCityObjectType"> <xs:sequence> <xs:element name="class" type="gml:CodeType" minOccurs="0"/> <xs:element name="function" type="gml:CodeType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="usage" type="gml:CodeType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="lod1Geometry" type="gml:GeometryPropertyType" minOccurs="0"/> <xs:element name="lod2Geometry" type="gml:GeometryPropertyType" minOccurs="0"/> <xs:element name="lod3Geometry" type="gml:GeometryPropertyType" minOccurs="0"/> <xs:element name="lod4Geometry" type="gml:GeometryPropertyType" minOccurs="0"/> <xs:element name="lod1TerrainIntersection" type="gml:MultiCurvePropertyType" minOccurs="0"/> <xs:element name="lod2TerrainIntersection" type="gml:MultiCurvePropertyType" minOccurs="0"/> <xs:element name="lod3TerrainIntersection" type="gml:MultiCurvePropertyType" minOccurs="0"/> <xs:element name="lod4TerrainIntersection" type="gml:MultiCurvePropertyType" minOccurs="0"/> <xs:element name="lod1ImplicitRepresentation" type="core:ImplicitRepresentationPropertyType" minOccurs="0"/> <xs:element name="lod2ImplicitRepresentation" type="core:ImplicitRepresentationPropertyType" minOccurs="0"/> <xs:element name="lod3ImplicitRepresentation" type="core:ImplicitRepresentationPropertyType" minOccurs="0"/> <xs:element name="lod4ImplicitRepresentation" type="core:ImplicitRepresentationPropertyType" minOccurs="0"/> <xs:element name="boundedBy" type="BoundarySurfacePropertyType" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="_GenericApplicationPropertyOfBridgeConstructionElement" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================= --> <xs:element name="BridgeConstructionElement" type="BridgeConstructionElementType" substitutionGroup="core:_CityObject"/> <!-- ========================================================================================= --> <xs:element name="_GenericApplicationPropertyOfBridgeConstructionElement" type="xs:anyType"/> BridgeInstallationType, BridgeInstallation<xs:complexType name="BridgeInstallationType"> <xs:complexContent> <xs:extension base="core:AbstractCityObjectType"> <xs:sequence> <xs:element name="class" type="gml:CodeType" minOccurs="0"/> <xs:element name="function" type="gml:CodeType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="usage" type="gml:CodeType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="lod2Geometry" type="gml:GeometryPropertyType" minOccurs="0"/> <xs:element name="lod3Geometry" type="gml:GeometryPropertyType" minOccurs="0"/> <xs:element name="lod4Geometry" type="gml:GeometryPropertyType" minOccurs="0"/> <xs:element name="lod2ImplicitRepresentation" type="core:ImplicitRepresentationPropertyType" minOccurs="0"/> <xs:element name="lod3ImplicitRepresentation" type="core:ImplicitRepresentationPropertyType" minOccurs="0"/> <xs:element name="lod4ImplicitRepresentation" type="core:ImplicitRepresentationPropertyType" minOccurs="0"/> <xs:element name="boundedBy" type="BoundarySurfacePropertyType" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="_GenericApplicationPropertyOfBridgeInstallation" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================= --> <xs:element name="BridgeInstallation" type="BridgeInstallationType" substitutionGroup="core:_CityObject"/> <!-- ========================================================================================= --> <xs:element name="_GenericApplicationPropertyOfBridgeInstallation" type="xs:anyType" abstract="true"/>

Bridge elements which do not have the size, significance or meaning of a BridgePart can be modelled either as BridgeConstructionElement or as BridgeInstallation. Elements which are essential from a structural point of view are modelled as BridgeConstructionElement, for example structural elements like pylons, anchorages etc. (cf. ). A general classification as well as the intended and actual function of the construction element are represented by the attributes class, function, and usage. The geometry of a BridgeConstructionElement, which may be present in LOD1 to LOD4, is gml:_Geometry. Alternatively, the geometry may be given as ImplicitGeometry object. Following the concept of ImplicitGeometry the geometry of a prototype bridge construction element is stored only once in a local coordinate system and referenced by other bridge construction element features (cf. ). The visible surfaces of a bridge construction element can be semantically classified using the concept of boundary surfaces (cf. ).

Whereas a BridgeConstructionElement has structural relevance, a BridgeInstallation represents an element of the bridge which can be eliminated without collapsing of the bridge (e.g. stairway, antenna, railing). BridgeInstallations occur in LOD 2 to 4 only and are geometrically representated as gml:_Geometry. Again, the concept of ImplicitGeometry can be applied to BridgeInstallations alternatively, and their visible surfaces can be semantically classified using the concept of boundary surfaces (cf. ). The class BridgeInstallation contains the semantic attributes class, function and usage. The attribute class gives a classification of installations of a bridge. With the attributes function and usage, nominal and real functions of the bridge installation can be described. The type of all attributes is gml:CodeType and their values can be defined in code lists.

BridgeConstructionElements of a suspension bridge.

AbstractBoundarySurfaceType, _BoundarySurface<xs:complexType name="AbstractBoundarySurfaceType" abstract="true"> <xs:complexContent> <xs:extension base="core:AbstractCityObjectType"> <xs:sequence> <xs:element name="lod2MultiSurface" type="gml:MultiSurfacePropertyType" minOccurs="0"/> <xs:element name="lod3MultiSurface" type="gml:MultiSurfacePropertyType" minOccurs="0"/> <xs:element name="lod4MultiSurface" type="gml:MultiSurfacePropertyType" minOccurs="0"/> <xs:element name="opening" type="OpeningPropertyType" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="_GenericApplicationPropertyOfBoundarySurface" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================== --> <xs:element name="_BoundarySurface" type="AbstractBoundarySurfaceType" abstract="true" substitutionGroup="core:_CityObject"/> <!-- ========================================================================================== --> <xs:element name="_GenericApplicationPropertyOfBoundarySurface" type="xs:anyType" abstract="true"/>

The thematic boundary surfaces of a bridge are defined in analogy to the building module. _BoundarySurface is the abstract base class for several thematic classes, structuring the exterior shell of a bridge as well as the visible surfaces of rooms, bridge construction elements and both outer and interior bridge installations. It is a subclass of _CityObject and thus inherits all properties like the GML3 standard feature properties (gml:name etc.) and the CityGML specific properties like ExternalReferences. From _BoundarySurface, the thematic classes RoofSurface, WallSurface, GroundSurface, OuterCeilingSurface, OuterFloorSurface, ClosureSurface, FloorSurface, InteriorWallSurface, and CeilingSurface are derived.

For each LOD between 2 and 4, the geometry of a _BoundarySurface may be defined by a different gml:MultiSurface geometry.

In LOD3 and LOD4, a _BoundarySurface may contain _Openings (cf. ) like doors and windows. If the geometric location of _Openings topologically lies within a surface component (e.g. gml:Polygon) of the gml:MultiSurface geometry, these _Openings must be represented as holes within that surface. A hole is represented by an interior ring within the corresponding surface geometry object. According to GML3, the points have to be specified in reverse order (exterior boundaries counter-clockwise and interior boundaries clockwise when looking in opposite direction of the surface’s normal vector). If such an opening is sealed by a Door, a Window, or a ClosureSurface, their outer boundary may consist of the same points as the inner ring (denoting the hole) of the surrounding surface. The embrasure surfaces of an Opening belong to the relevant adjacent _BoundarySurface. If, for example a door seals the Opening, the embrasure surface on the one side of the door belongs to the InteriorWallSurface and on the other side to the WallSurface.

depicts a bridge with RoofSurfaces, WallSurfaces, OuterFloorSurfaces and OuterCeilingSurfaces. Besides Bridges and BridgeParts, BridgeConstructionElements, BridgeInstallations as well as IntBridgeInstallations can be related to _BoundarySurface. _BoundarySurfaces occur in LOD2 to LOD4. In LOD3 and LOD4, such a surface may contain _Openings (see ) like doors and windows.

Different BoundarySurfaces of a bridge.

GroundSurfaceType, GroundSurface<xs:complexType name="GroundSurfaceType"> <xs:complexContent> <xs:extension base="AbstractBoundarySurfaceType"> <xs:sequence> <xs:element ref="_GenericApplicationPropertyOfGroundSurface" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================= --> <xs:element name="GroundSurface" type="GroundSurfaceType" substitutionGroup="_BoundarySurface"/> <!-- ========================================================================================= --> <xs:element name="_GenericApplicationPropertyOfGroundSurface" type="xs:anyType" abstract="true"/>

The ground plate of a bridge or bridge part is modelled by the class GroundSurface. The polygon defining the ground plate is congruent with the bridge’s footprint. However, the surface normal of the ground plate is pointing downwards.

OuterCeilingSurfaceType, OuterCeilingSurface<xs:complexType name="OuterCeilingSurfaceType"> <xs:complexContent> <xs:extension base="AbstractBoundarySurfaceType"> <xs:sequence> <xs:element ref="_GenericApplicationPropertyOfOuterCeilingSurface" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================== --> <xs:element name="OuterCeilingSurface" type="OuterCeilingSurfaceType" substitutionGroup="_BoundarySurface"/> <!-- ========================================================================================== --> <xs:element name="_GenericApplicationPropertyOfOuterCeilingSurface" type="xs:anyType" abstract="true"/>

A mostly horizontal surface belonging to the outer bridge shell and having the orientation pointing downwards can be modeled as an OuterCeilingSurface.

WallSurfaceType, WallSurface<xs:complexType name="WallSurfaceType"> <xs:complexContent> <xs:extension base="AbstractBoundarySurfaceType"> <xs:sequence> <xs:element ref="_GenericApplicationPropertyOfWallSurface" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================= --> <xs:element name="WallSurface" type="WallSurfaceType" substitutionGroup="_BoundarySurface"/> <!-- ========================================================================================= --> <xs:element name="_GenericApplicationPropertyOfWallSurface" type="xs:anyType" abstract="true"/>

All parts of the bridge facade belonging to the outer bridge shell can be modelled by the class WallSurface.

OuterFloorSurfaceType, OuterFloorSurface<xs:complexType name="OuterFloorSurfaceType"> <xs:complexContent> <xs:extension base="AbstractBoundarySurfaceType"> <xs:sequence> <xs:element ref="_GenericApplicationPropertyOfOuterFloorSurface" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================== --> <xs:element name="OuterFloorSurface" type="OuterFloorSurfaceType" substitutionGroup="_BoundarySurface"/> <!-- ========================================================================================== --> <xs:element name="_GenericApplicationPropertyOfOuterFloorSurface" type="xs:anyType" abstract="true"/>

A mostly horizontal surface belonging to the outer bridge shell and with the orientation pointing upwards can be modeled as an OuterFloorSurface.

RoofSurfaceType, RoofSurface<xs:complexType name="RoofSurfaceType"> <xs:complexContent> <xs:extension base="AbstractBoundarySurfaceType"> <xs:sequence> <xs:element ref="_GenericApplicationPropertyOfRoofSurface" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================== --> <xs:element name="RoofSurface" type="RoofSurfaceType" substitutionGroup="_BoundarySurface"/> <!-- ========================================================================================== --> <xs:element name="_GenericApplicationPropertyOfRoofSurface" type="xs:anyType" abstract="true"/>

The major roof parts of a bridge or bridge part are expressed by the class RoofSurface.

ClosureSurfaceType, ClosureSurface<xs:complexType name="ClosureSurfaceType"> <xs:complexContent> <xs:extension base="AbstractBoundarySurfaceType"> <xs:sequence> <xs:element ref="_GenericApplicationPropertyOfClosureSurface" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================= --> <xs:element name="ClosureSurface" type="ClosureSurfaceType" substitutionGroup="_BoundarySurface"/> <!-- ========================================================================================= --> <xs:element name="_GenericApplicationPropertyOfClosureSurface" type="xs:anyType" abstract="true"/>

An opening in a bridge not filled by a door or window can be sealed by a virtual surface called ClosureSurface (cf. ). Hence, bridge with open sides can be virtually closed in order to be able to compute their volume. ClosureSurfaces are also used in the interior bridge model. If two rooms with a different are directly connected without a separating door, a ClosureSurface should be used to separate or connect the volumes of both rooms.

FloorSurfaceType, FloorSurface<xs:complexType name="ClosureSurfaceType"> <xs:complexContent> <xs:extension base="AbstractBoundarySurfaceType"> <xs:sequence> <xs:element ref="_GenericApplicationPropertyOfClosureSurface" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================= --> <xs:element name="ClosureSurface" type="ClosureSurfaceType" substitutionGroup="_BoundarySurface"/> <!-- ========================================================================================= --> <xs:element name="_GenericApplicationPropertyOfClosureSurface" type="xs:anyType" abstract="true"/>

The class FloorSurface must only be used in the LOD4 interior bridge model for modelling the floor of a bridge room.

InteriorWallSurfaceType, InteriorWallSurface<xs:complexType name="InteriorWallSurfaceType"> <xs:complexContent> <xs:extension base="AbstractBoundarySurfaceType"> <xs:sequence> <xs:element ref="_GenericApplicationPropertyOfInteriorWallSurface" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================= --> <xs:element name="InteriorWallSurface" type="InteriorWallSurfaceType" substitutionGroup="_BoundarySurface"/> <!-- ========================================================================================= --> <xs:element name="_GenericApplicationPropertyOfInteriorWallSurface" type="xs:anyType" abstract="true"/>

The class InteriorWallSurface must only be used in the LOD4 interior bridge model for modelling the visible surfaces of the bridge room walls.

CeilingSurfaceType, CeilingSurface<xs:complexType name="CeilingSurfaceType"> <xs:complexContent> <xs:extension base="AbstractBoundarySurfaceType"> <xs:sequence> <xs:element ref="_GenericApplicationPropertyOfCeilingSurface" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- ========================================================================================= --> <xs:element name="CeilingSurface" type="CeilingSurfaceType" substitutionGroup="_BoundarySurface"/> <!-- ========================================================================================= --> <xs:element name="_GenericApplicationPropertyOfCeilingSurface" type="xs:anyType" abstract="true"/>

The class CeilingSurface must only be used in the LOD4 interior bridge model for modelling the ceiling of a bridge room.

The bridge of Rees crossing the Rhine in Germany has three bridge parts which are separated by pylons. (left) depicts the Rees bridge model containing one Bridge feature which consists of three BridgePart features. The pylons, which are structurally essential, are represented by BridgeConstructionElements. On the top of the pylons, four lamps are located which are modeled as BridgeInstallation features (cf. right part of ).

The bridge of Rees, consisting of a Bridge feature and three BridgePart features (left). The bridge contains BridgeConstructionElement and BridgeInstallation features (right).

In the following , the main part of the bridge of Rees is shown as photograph on the left side (source: Harald Halfpapp), and the corresponding part of the LOD2 bridge model is depicted on the the right side (source: District of Recklinghausen / KIT).

The bridge of Rees (left photo (source: Harald Halfpapp); right LOD2 model (source: District of Recklinghausen / KIT)).

There are two bridges crossing the river Rhine at Karlsruhe, Germany. The first one is a two track railway bridge constructed as a truss bridge (cf. front). The second one is a four lane highway bridge constructed as a cable-stayed bridge (cf. background).

Bridge over the river Rhine at Karlsruhe (left a photo, right the 3D CityGML model) (source: Karlsruhe Institute of Technology (KIT), courtesy of City of Karlsruhe).

In CityGML both bridges are modeled as single Bridge object with BridgeConstructionElements and BridgeInstallations. The construction elements of the cable stayed bridge are the footings on both river sides and in the middle of the river, as well as the cables and the pylon. The construction elements of the truss bridge are the footings and the truss itself. Both bridges have several railings which are modeled as BridgeInstallation.

The bridge “Oberbaumbrücke” shown in is located in the centre of Berlin crossing the river Spree and serves as example for bridges having interior rooms. The real-world bridge is depicted in the left part of , whereas the corresponding CityGML model is shown on the right. The outer geometry of the bridge is modeled as gml:MultiSurface element (lod4MultiSurface property) and is assigned photorealistic textures. Additionally, the interior rooms located in both bridge towers are represented as BridgeRoom objects with solid geometries (gml:Solid assigned through the lod4Solid property). Due to its high geometric accuracy and the representation of the interior structures of both bridge towers, the model is classified as LOD4.

The bridge"Oberbaumbrücke" in Berlin represented as bridge model in LOD4 (left a photo, right the 3D CityGML model) (source: Berlin Senate of Business, Technology and Women; Business Location Center, Berlin; Technische Universität Berlin; Karlsruhe Institute of Technology (KIT)).

Waters have always played an important role in urbanisation processes and cities were built preferably at rivers and places where landfall seemed to be easy. Obviously, water is essential for human alimentation and sanitation. Water bodies present the most economical way of transportation and are barriers at the same time, that avoid instant access to other locations. Bridging waterways caused the first efforts of construction and resulted in high-tech bridges of today. The landscapes of many cities are dominated by water, which directly relates to 3D city models. Furthermore, water bodies are important for urban life as subject of recreation and possible hazards as e.g. floods.

The distinct character of water bodies compared with the permanence of buildings, roadways, and terrain is considered in this thematic model. Water bodies are dynamic surfaces. Tides occur regularly, but irregular events predominate with respect to natural forces, for example flood events. The visible water surface changes in height and its covered area with the necessity to model its semantics and geometry distinct from adjacent objects like terrain or buildings.

This first modelling approach of water bodies fulfils the requirements of 3D city models. It does not inherit any hydrological or other dynamic aspects. In these terms it does not claim to be complete. However, the semantic and geometric description given here allows further enhancements of dynamics and conceptually different descriptions. The water bodies model of CityGML is embraced by the thematic extension module WaterBody (cf. ).

The water bodies model represents the thematic aspects and three-dimensional geometry of rivers, canals, lakes, and basins. In the LOD 2-4 water bodies are bounded by distinct thematic surfaces. These surfaces are the obligatory WaterSurface, defined as the boundary between water and air, the optional WaterGroundSurface, defined as the boundary between water and underground (e.g. DTM or floor of a 3D basin object), and zero or more WaterClosureSurfaces, defined as virtual boundaries between different water bodies or between water and the end of a modelled region (see ). A dynamic element may be the WaterSurface to represent temporarily changing situations of tidal flats.

Illustration of a water body defined in CityGML (graphic: IGG Uni Bonn).

The UML diagram of the water body model is depicted in , for the XML schema definition see below and . Each WaterBody object may have the attributes class, function and usage whose possible values can be enumerated in code lists (cf. and ). The attribute class defines the classification of the object, e.g. lake, river, or fountain and can occur only once. The attribute function contains the purpose of the object like, for example national waterway or public swimming, while the attribute usage defines the actual usages, e.g. whether the water body is navigable. The latter two attributes can occur multiple times.

WaterBody is a subclass of _WaterObject and transitively of the root class _CityObject. The class _WaterObject may be differentiated in further subclasses of water objects in the future. The geometrical representation of the WaterBody varies through the different levels of detail. Since WaterBody is a subclass of _CityObject and hence a feature, it inherits the attribute gml:name._The _WaterBody can be differentiated semantically by the class _WaterBoundarySurface. A _WaterBoundarySurface is a part of the water body’s exterior shell with a special function like WaterSurface, WaterGroundSurface or WaterClosureSurface. As with any _CityObject, WaterBody objects as well as WaterSurface, WaterGroundSurface, and WaterClosureSurface may be assigned ExternalReferences(cf. ) and may be augmented by generic attributes using CityGML’s Generics module (cf. ).

The optional attribute waterLevel of a WaterSurface can be used to describe the water level, for which the given 3D surface geometry was acquired. This is especially important when the water body is influenced by the tide. The allowed values can be defined in a corresponding code list.

UML diagram of the water body model in CityGML. Prefixes are used to indicate XML namespaces associated with model elements. Element names without a prefix are defined within the CityGML WaterBody module.

Both LOD0 and LOD1 represent a low level of illustration and high grade of generalisation. Here the rivers are modelled as MultiCurve geometry and brooks are omitted. Seas, oceans and lakes with significant extent are represented as a MultiSurface (). Every WaterBody may be assigned a combination of geometries of different types. Linear water bodies are represented as a network of 3D curves. Each curve is composed of straight line segments, where the line orientation denotes the flow direction (water flows from the first point of a curve, e.g. a gml:LineString, to the last). Areal objects like lakes or seas are represented by 3D surface geometries of the water surface.

Starting from LOD1 water bodies may also be modelled as water filled volumes represented by Solids. If a water body is represented by a gml:Solid in LOD2 or higher, the surface geometries of the corresponding thematic WaterClosureSurface, WaterGroundSurface, and WaterSurface objects must coincide with the exterior shell of the gml:Solid. This can be ensured, if for each LOD X the respective lodXSolid representation (where X is between 2 and 4) does not redundantly define the geometry, but instead references the corresponding polygons (using GML3’s XLink mechanism) of the lodXSurface elements (where X is between 2 and 4) of WaterClosureSurface, WaterGroundSurface, and WaterSurface.

LOD2 to LOD4 demand a higher grade of detail and therefore any WaterBody can be outlined by thematic surfaces or a solid composed of the surrounding thematic surfaces.

Every object of the class WaterSurface, WaterClosureSurface, and WaterGroundSurface must have at least one associated surface geometry. This means, that every WaterSurface, WaterClosureSurface, and WaterGroundSurface feature within a CityGML instance document must contain at least one of the following properties: lod2Surface, lod3Surface, lod4Surface.

The water body model implicitly includes the concept of TerrainIntersectionCurves (TIC), e.g. to specify the exact intersection of the DTM with the 3D geometry of a WaterBody or to adjust a WaterBody or WaterSurface to the surrounding DTM (see ). The rings defining the WaterSurface polygons implicitly delineate the intersection of the water body with the terrain or basin.

XML namespace

The XML namespace of the CityGML WaterBody module is identified by the Uniform Resource Identifier (URI) . Within the XML Schema definition of the WaterBody module, this URI is also used to identify the default namespace.

The transportation model of CityGML is a multi-functional, multi-scale model focusing on thematic and functional as well as on geometrical/topological aspects. Transportation features are represented as a linear network in LOD0. Starting from LOD1, all transportation features are geometrically described by 3D surfaces. The areal modelling of transportation features allows for the application of geometric route planning algorithms. This can be useful to determine restrictions and manoeuvres required along a transportation route. This information can also be employed for trajectory planning of mobile robots in the real world or the automatic placement of avatars (virtual people) or vehicle models in 3D visualisations and training simulators. The transportation model of CityGML is provided by the thematic extension module Transportation (cf. ).

The main class is TransportationComplex, which represents, for example, a road, a track, a railway, or a square. illustrates the four different thematic classes.

Representations of TransportationComplex (from left to right: examples of road, track, rail, and square) (source: Rheinmetall Defence Electronics).

A TransportationComplex is composed of the parts TrafficArea and AuxiliaryTrafficArea. depicts an example for a LOD2 TransportationComplex configuration within a virtual 3D city model. The Road consists of several TrafficAreas for the sidewalks, road lanes, parking lots, and of AuxiliaryTrafficAreas below the raised flower beds.

Example for the representation of a TransportationComplex in LOD2 in CityGML: a road, which is the aggregation of TrafficAreas and AuxiliaryTrafficAreas (source: City of Solingen, IGG Uni Bonn).

depicts the UML diagram of the transportation model, for the XML schema definition see .

UML diagram of the transportation model in CityGML. Prefixes are used to indicate XML namespaces associated with model elements. Element names without a prefix are defined within the CityGML Transportation module.

The road itself is represented as a TransportationComplex, which is further subdivided into TrafficAreas and AuxiliaryTrafficAreas. The TrafficAreas are those elements, which are important in terms of traffic usage, like car driving lanes, pedestrian zones and cycle lanes. The AuxiliaryTrafficAreas are describing further elements of the road, like kerbstones, middle lanes, and green areas.

TransportationComplex objects can be thematically differentiated using the subclasses Track, Road, Railway, and Square. Every TransportationComplex has the attributes class, function and usage whose possible values can be enumerated in code lists ( and ). The attribute class describes the classification of the object, function describes the purpose of the object, for example national motorway, country road, or airport, while the attribute usage can be used, if the actual usage differs from the function. The attributes function and usage can occur multiple times.

In addition both TrafficArea and AuxiliaryTrafficArea may have the attributes class, function, usage, and surfaceMaterial. The attribute class describes the classification of the object. For TrafficArea, _function describes, if the object for example may be a car driving lane, a pedestrian zones, or a cycle lane, while the _usage attribute indicates which modes of transportation can use it (e.g. pedestrian, car, tram, roller skates). The attribute surfaceMaterial specifies the type of pavement and may also be used for AuxiliaryTrafficAreas (e.g. asphalt, concrete, gravel, soil, rail, grass). The function attribute of the AuxiliaryTrafficArea defines, for example kerbstones, middle lanes, or green areas. The possible values can also be specified in code lists.

The shape of each traffic area is defined by a surface geometry. Additional metadata may be defined by using attributes from pre-defined catalogues. This affects the class, function and usage of each traffic area as well as its surface material. The attribute catalogues may be customer- or country-specific. The following tables show examples for various kinds of TrafficArea:

TransportationComplex is a subclass of _TransportationObject and of the root class _CityObject. The geometrical representation of the TransportationComplex varies through the different levels of detail. Since TransportationComplex is a subclass of _CityObject and hence a feature, it inherits the attribute gml:name. The street name is also stored within the gml:name property of the Road feature.

In the coarsest LOD0 the transportation complexes are modelled by line objects establishing a linear network. On this abstract level, path finding algorithms or similar analyses can be executed. It also can be used to generate schematic drawings and visualisations of the transport network. Since this abstract definition of transportation network does not contain explicit descriptions of the transportation objects, it may be task of the viewer application to generate the graphical visualisation, for example by using a library with style-definitions (width, color resp. texture) for each transportation object.

Starting from LOD1 a TransportationComplex provides an explicit surface geometry, reflecting the actual shape of the object, not just its centerline. In LOD2 to LOD4, it is further subdivided thematically into TrafficAreas, which are used by transportation, such as cars, trains, public transport, airplanes, bicycles or pedestrians and in AuxiliaryTrafficAreas, which are of minor importance for transportation purposes, for example road markings, green spaces or flower tubs. The different representations of a TransportationComplex for each LOD are illustrated in .

TransportationComplex in LOD0, 1, and 2-4 (example shows part of a motorway) (source: Rheinmetall Defence Electronics).

In LOD0 areal transportation objects like squares should be modelled in the same way as in GDF, the ISO standard for transportation networks, which is used in most car navigation systems. In GDF a square is typically represented as a ring surrounding the place and to which the incident roads connect. CityGML does not cover further functional aspects of transportation network models (e.g. speed limits) as it is intended to complement and not replace existing standards like GDF. However, if specific functional aspects have to be associated with CityGML transportation objects, generic attributes provided by CityGML’s Generics module (cf. ) can be used. Moreover, further objects of interest can be added from other information systems by the use of ExternalReferences (see ). For example, GDF datasets, which provide additional information for car navigation, can be used for simulation and visualisation of traffic flows. The values of the object attributes can be augmented or replaced using the concept of dictionaries (see ). These directories may be country- or user-specific (especially for country-specific road signs and signals).

TransportationComplex in LOD 2-4: representation of a road with a complex cross-section profile (example shows urban road) (source: Rheinmetall Defence Electronics).

The following example shows a complex urban crossing. The picture on the left is a screenshot of an editor application for a training simulator, which allows the definition of road networks consisting of transportation objects, external references, buildings and vegetation objects. On the right, the 3D representation of the defined crossing is shown including all referenced static and dynamic models.

Complex urban intersection (left: linear transportation network with surface descriptions and external references, right: generated scene) (source: Rheinmetall Defence Electronics).

XML namespace

The XML namespace of the CityGML Transportation module is identified by the Uniform Resource Identifier (URI) . Within the XML Schema definition of the Transportation module, this URI is also used to identify the default namespace.

Vegetation features are important components of a 3D city model, since they support the recognition of the surrounding environment. By the analysis and visualisation of vegetation objects, statements on their distribution, structure and diversification can be made. Habitats can be analysed and impacts on the fauna can be derived. The vegetation model may be used as a basis for simulations of, for example forest fire, urban aeration or micro climate. The model could be used, for example to examine forest damage, to detect obstacles (e.g. concerning air traffic) or to perform analysis tasks in the field of environmental protection. The vegetation model of CityGML is defined by the thematic extension module Vegetation (cf. ).

The vegetation model of CityGML distinguishes between solitary vegetation objects like trees and vegetation areas, which represent biotopes like forests or other plant communities (). Single vegetation objects are modelled by the class SolitaryVegetationObject, whereas for areas filled with a specific vegetation the class PlantCover is used. The geometry representation of a PlantCover feature may be a MultiSurface or a MultiSolid, depending on the vertical extent of the vegetation. For example regarding forests, a MultiSolid representation might be more appropriate. The UML diagram of the vegetation model is depicted in , for the XML schema definition see below and .

Example for vegetation objects of the classes SolitaryVegetationObject and PlantCover (graphic: District of Recklinghausen).

A SolitaryVegetationObject may have the attributes class, function, usage, species height, trunkDiameter and crownDiameter. The attribute class contains the classification of the object or plant habit, e.g. tree, bush, grass, and can occur only once (see and ). The attribute species defines the species’ name, for example “Abies alba”, and can occur at most once (see and ). The optional attributes function and usage denotes the intended respectively real purpose of the object, for example botanical monument, and can occur multiple times. The possible attribute values for class, species, function, and usage can be provided in a code list. The attribute_height_containsthe relative height of the object. The attributes crownDiameter and_trunkDiameter_ represent the plant crown and trunk diameter respectively. The trunk diameter is often used in regulations of municipal cadastre (e.g. tree management rules).

A PlantCover feature may have the attributes class, function, usage and averageHeight. The plant community of a PlantCover is represented by the attribute class. The values of this attribute can be specified in a code list (cf. and ) whose values should not only describe one plant type or species, but denote a typical mixture of plant types in a plant community. This information can be used in particular to generate realistic 3D visualisations, where the PlantCover region is automatically, perhaps randomly, filled with a corresponding mixture of 3D plant objects. The attributes function and usage indicate the intended respectively real purpose of the object, for example national forest, and can occur multiple times. The attribute_averageHeight_denotes the average relative vegetation height.

Since both SolitaryVegetationObject and PlantCover are derived fom _CityObject, they inherit all attributes of a city object, in particular a name (gml:name) and an ExternalReference to a corresponding object in an external information system, which may contain botanical information from public environmental agencies (see ).

UML diagram of vegetation objects in CityGML. Prefixes are used to indicate XML namespaces associated with model elements. Element names without a prefix are defined within the CityGML Vegetation module.

The geometry of a SolitaryVegetationObject may be defined in LOD 1-4 explicitly by a GML geometry having absolute coordinates, or prototypically by an ImplicitGeometry (cf. ). Solitary vegetation objects probably are one of the most important features where implicit geometries are appropriate, since the shape of most types of vegetation objects, such as trees of the same species, can be treated as identical in most cases. Furthermore, season dependent appearances may by mapped using ImplicitGeometry. For visualisation purposes, only the content of the library object defining the object’s shape and appearance has to be swapped (cf. ).

Visualisation of a vegetation object in different seasons (source: District of Recklinghausen).

A SolitaryVegetationObject or a PlantCover may have a different geometry in each LOD. Whereas a SolitaryVegetationObject is associated with the gml:_Geometry class representing an arbitrary GML geometry (by the relation lodXGeometry, $X\in \left[1̈4\right]$X in [1..4]), a PlantCover is restricted to be either a gml:MultiSolid or a gml:MultiSurface. An example of a PlantCover modelled as gml:MultiSolid is a ‘solid forest model’, see .

Example for the visualisation/modelling of a solid forest (source: District of Recklinghausen).

XML namespace

The XML namespace of the CityGML Vegetation module is identified by the Uniform Resource Identifier (URI) . Within the XML Schema definition of the Vegetation module, this URI is also used to identify the default namespace.

City furniture objects are immovable objects like lanterns, traffic lights, traffic signs, flower buckets, advertising columns, benches, delimitation stakes, or bus stops (, ). City furniture objects can be found in traffic areas, residential areas, on squares or in built-up areas. The modelling of city furniture objects is used for visualisation of, for example city traffic, but also for analysing local structural conditions. The recognition of special locations in a city model is improved by the use of these detailed city furniture objects, and the city model itself becomes more alive and animated. The city furniture model of CityGML is defined by the thematic extension module CityFurniture (cf. ).

City furniture objects can have an important influence on simulations of, for example city traffic situations. Navigation systems can be realised, for example for visually handicapped people using a traffic light as routing target. Likewise, city furniture objects are important to plan a heavy vehicle transportation, where the exact position and further conditions of obstacles must be known.

Real situation showing a bus stop (left). The advertising billboard and the refuge are modelled as CityFurniture objects in the right image (source: 3D city model of Barkenberg).

Real situation showing lanterns and delimitation stakes (left). In the right image they are modelled as CityFurniture objects with ImplicitGeometry representations (source: 3D city model of Barkenberg).

The UML diagram of the city furniture model is depicted in , for the XML schema definition see below and .

The class CityFurniture may have the attributes class, function and usage. Their possible values can be specified in corresponding code lists ( and ). The class attribute allows an object classification like traffic light, traffic sign, delimitation stake, or garbage can, and can occur only once. The function attribute describes, to which thematic area the city furniture object belongs to (e.g. transportation, traffic regulation, architecture), and can occur multiple times. The attribute usage denotes the real purpose of the object.

UML diagram of city furniture objects in CityGML. Prefixes are used to indicate XML namespaces associated with model elements. Element names without a prefix are defined within the CityGML CityFurniture module.

Since CityFurniture is a subclass of _CityObject and hence is a feature, it inherits the attribute gml:name. As with any _CityObject, CityFurniture objects may be assigned ExternalReferences(cf. ) and may be augmented by generic attributes using CityGML’s Generics module (cf. ). For ExternalReferences city furniture objects can have links to external thematic databases. Thereby, semantic information of the objects, which cannot be modelled in CityGML, can be transmitted and used in the 3D city model for further processing, for example information from systems of powerlines or pipelines, traffic sign cadaster, or water resources for disaster management.

City furniture objects can be represented in city models with their specific geometry, but in most cases the same kind of object has an identical geometry. The geometry of CityFurniture objects in LOD 1-4 may be represented by an explicit geometry (lodXGeometry where X is between 1 and 4) or an ImplicitGeometry object (lodXImplicitRepresentation with X between 1 and 4). Following the concept of ImplicitGeometry the geometry of a prototype city furniture is stored only once in a local coordinate system and referenced by other city furniture features (see ). Spatial information of city furniture objects can be taken, for example, from city maps or from public and private external information systems.

In order to specify the exact intersection of the DTM with the 3D geometry of a city furniture object, the latter can have a TerrainIntersectionCurve (TIC) for each LOD (cf. ). This allows for ensuring a smooth transition between the DTM and the city furniture object.

XML namespace

The XML namespace of the CityGML CityFurniture module is identified by the Uniform Resource Identifier (URI) . Within the XML Schema definition of the CityFurniture module, this URI is also used to identify the default namespace.

The following example of a CityGML dataset is an extract of the model of a delimitation stake in LOD3 and contains the attributes class = 1000 and function = 1520 (delimitation stake) whose coded attribute values are taken from a code list proposed by the SIG 3D (cf. ). The delimitation stake with the object ID stake0815 has an ExternalReference pointing to a cadastre object within the German ALKIS database (www.adv-online.de) which is identified by the URI urn:adv:oid:DEHE123400007001.

The example dataset shows the geometry of the top surface (gml:id “cover”) and of the left surface (gml:id “surfLeft”) of the stake which are both depicted in . The top surface is assigned a constant material (white color) and the left surfaceis textured using the texture image stake.gif by denoting the relevant texture coordinates. Both surface appearances are modelled using the CityGML Appearance module (cf. ).

Example of a simple city furniture object (source: District of Recklinghausen).

<!-- delimitation stake in LOD3 --> <CityFurniture gml:id="stake0815"> <core:externalReference> <core:informationSystem>http://www.adv-online.de</core:informationSystem> <!-- Reference to ALKIS --> <core:externalObject> <core:uri>urn:adv:oid:DEHE123400007001</core:uri> <!-- ALKIS Object ID --> </core:externalObject> </core:externalReference> <app:appearance> <app:Appearance> <app:surfaceDataMember> <app:X3DMaterial> <app:ambientIntensity>0.4</app:ambientIntensity> <app:diffuseColor>1.0 1.0 1.0</app:diffuseColor> <app:target>#cover</app:target> </app:X3DMaterial> </app:surfaceDataMember> <app:surfaceDataMember> <app:ParameterizedTexture> <app:imageURI>stake.gif</app:imageURI> <app:textureType>typical</app:textureType> <app:target uri="#surfLeft"> <app:TexCoordList> <app:textureCoordinates ring="#surfLeft_ring1"> 0.000 0.000 1.000 0.000 1.000 1.000 0.000 1.000 0.000 0.000 </app:textureCoordinates> </app:TexCoordList> </app:target> </app:ParameterizedTexture> </app:surfaceDataMember> </app:Appearance> </app:appearance> <class codeSpace="http://www.sig3d.org/codelists/standard/cityfurniture/2.0/CityFurniture_class.xml">1000</class> <!-- 1000 = traffic --> <function codeSpace="http://www.sig3d.org/codelists/standard/cityfurniture/2.0/CityFurniture_function.xml">1520</function> <!-- 1520 = boundary post --> <lod3Geometry> <!--Stake 0.06x0.06x1.2--> <gml:Solid srsName="urn:ogc:def:crs,crs:EPSG:6.12:31466,crs:EPSG:6.12:5783"> <gml:exterior> <gml:CompositeSurface> <gml:surfaceMember> <gml:Polygon gml:id="cover"> <gml:exterior> <!-- Cover-Surface --> <gml:LinearRing> <gml:pos>5733500.060 2572400.060 61.200</gml:pos> <gml:pos>5733500.060 2572400.000 61.200</gml:pos> <gml:pos>5733500.000 2572400.000 61.200</gml:pos> <gml:pos>5733500.000 2572400.060 61.200</gml:pos> <gml:pos>5733500.060 2572400.060 61.200</gml:pos> </gml:LinearRing> </gml:exterior> </gml:Polygon> </gml:surfaceMember> <gml:surfaceMember> <gml:Polygon gml:id="surfLeft"> <gml:exterior> <!-- Surface left --> <gml:LinearRing gml:id="surfLeft_ring1"> <gml:pos>5733500.060 2572400.000 60.000</gml:pos> <gml:pos>5733500.000 2572400.000 60.000</gml:pos> <gml:pos>5733500.000 2572400.000 61.200</gml:pos> <gml:pos>5733500.060 2572400.000 61.200</gml:pos> <gml:pos>5733500.060 2572400.000 60.000</gml:pos> </gml:LinearRing> </gml:exterior> </gml:Polygon> </gml:surfaceMember> ... </gml:CompositeSurface> </gml:exterior> </gml:Solid> </lod3Geometry> </CityFurniture>

LandUse objects can be used to describe areas of the earth’s surface dedicated to a specific land use, but also to describe areas of the earth’s surface having a specific land cover with or without vegetation, such as sand, rock, mud flats, forest, grasslands, etc (i.e. the physical appearance). Land use and land cover are different concepts; the first describes human activities on the earth’s surface, the second describes its physical and biological cover. However, the two are interlinked and often mixed in practice. LandUse objects in CityGML represent both concepts: They can be employed to represent, parcels, spatial planning objects, recreational objects and objects describing the physical characteristics of an area, in 3D (e.g. wetlands). shows the UML diagram of land use objects, for the XML schema definition see and . The land use model of CityGML is provided by the thematic extension module LandUse (cf. ).

UML diagram of land use objects in CityGML. Prefixes are used to indicate XML namespaces associated with model elements. Element names without a prefix are defined within the CityGML LandUse module.

Every LandUse object may have the attributes class, function, and usage. The class attribute is used to represent the classification of land use objects, like settlement area, industrial area, farmland etc., and can occur only once. The possible values can be specified in a code list (cf. ). The attribute function defines the purpose of the object or their nature, like e.g. cornfield or heath, while the attribute usage can be used, if the way the object is actually used differs from the function. Both attributes can occur multiple times.

The LandUse object is defined for all LOD 0-4 and may have different geometries in any LOD. The surface geometry of a LandUse object is required to have 3D coordinate values. It must be a GML3 MultiSurface, which might be assigned appearance properties like textures or colors (using CityGML’s appearance model, cf. ).

LandUse objects can be employed to establish a coherent geometric/semantical tesselation of the earth’s surface. In this case topological relations between neighbouring LandUse objects should be made explicit by defining the boundary LineStrings only once and by referencing them in the corresponding Polygons using XLinks (cf. ). shows a land use tesselation, where the geometries of the land use objects are represented as triangulated surfaces. In fact, they are the result of a constrained triangulation of a DTM with consideration of breaklines defined by a 2D vector map of land use classifications.

LOD0 regional model consisting of land use objects in CityGML (source: IGG Uni Bonn).

XML namespace

The XML namespace of the CityGML LandUse module is identified by the Uniform Resource Identifier (URI) . Within the XML Schema definition of the LandUse module, this URI is also used to identify the default namespace.

The CityGML grouping concept has been introduced in . CityObjectGroups are modelled using the Composite Design Patternfrom software engineering (cf. Gamma et al. 1995): CityObjectGroups aggregate CityObjects and furthermore are defined as special CityObjects. This implies that a group may become a member of another group realizing a recursive aggregation schema. However, in a CityGML instance document it has to be ensured (by the generating application) that no cyclic groupings are included. shows the UML diagram for the class CityObjectGroup, forthe XML schema see . The grouping concept of CityGML is defined by the thematic extension module CityObjectGroup (cf. ).

UML diagram of city object groups in CityGML. Prefixes are used to indicate XML namespaces associated with model elements. Element names without a prefix are defined within the CityGML CityObjectGroup module.

The class CityObjectGroup has the optional attributes class, function and usage. The class attribute allows a group classification with respect to the stated function and may occur only once. The function attribute is intended to express the main purpose of a group, possibly to which thematic area it belongs (e.g. site, building, transportation, architecture, unknown etc.). The attribute usage can be used, if the way the object is actually used differs from the function. Both attributes can occur multiple times. Each member of a group may be qualified by a role name, reflecting the role each _CityObject plays in the context of the group. Furthermore, a CityObjectGroup can optionally be assigned an arbitrary geometry object from the GML3 subset shown in in . This may be used to represent a generalised geometry generated from the members geometries.