1. Introduction
Standardised data models can play a vital role in areas where complex information is handled by various stakeholders coming from different backgrounds as they ensure lossless data exchange, facilitate the development of reliable software solutions and, therefore, enhance the overall data interoperability.
Urban Building Energy Modelling (UBEM) represents a good example in this regard. In UBEM, different scenarios of the energy demand and supply of a city can be simulated at the individual building level [
1]. As such, UBEM serves as a valuable set of approaches, methods, and tools to support decision-makers in detecting energy-saving potentials and in subsequently allocating required resources for retrofitting purposes [
2]. However, UBEM requires large and heterogeneous quantities of information, such as data regarding energy consumption, local climate, occupant behaviour, physical properties of the buildings and their geometries [
3,
4].
The international standard City Geography Markup Language (CityGML), issued by the Open Geospatial Consortium (OGC), offers the possibility to model urban environments, including buildings, in a 3D space. CityGML defines “basic entities, attributes, and relations” of relevant urban objects, functioning both as a conceptual data model for semantically enriched 3D city models and as a storage and exchange format [
5]. Currently, the most widely used version is CityGML 2.0, which was released in 2012.
CityGML is intentionally designed to be application-independent. Nevertheless, in certain cases, additional classes or attributes may be needed for specific domains. For this reason, CityGML can be extended following two approaches. The first one allows for the definition of so-called generic attributes and generic city objects without the need to extend the conceptual data model. The second one, on the other hand, offers more modelling capabilities but demands an extension of the data model. This second approach is referred to as the Application Domain Extension (ADE) mechanism.
The Energy ADE version 1.0 is such an extension for CityGML. It builds upon the CityGML 2.0 Core and Building modules and extends them by means of additional classes and properties. As such, it has been conceived and designed as a solution to model and store relevant data needed for UBEM. It offers the possibility to model both data serving as input for energy-related applications and data storing the application results, in order to facilitate further building or city-wide energy assessments. The ultimate goal is to promote data interoperability between different UBEM stakeholders by means of a standardised data model [
6]. The Energy ADE 1.0 was released in 2018 through a joint effort of various international parties and stakeholders (familiar/expert with/in either CityGML or UBEM). It is mentioned in the literature as a best-practice example when it comes to ADE development due to its technical maturity and available documentation. As a result, the Energy ADE has already been used in several national and international projects [
7,
8].
In September 2021, version 3.0 of the CityGML standard was released by the OGC. The new version introduces considerable changes to the Core module with a revised geometry concept and a newly established space concept. Furthermore, new modules for time-dependent properties and man-made constructions have been added. Moreover, it is easier to include several ADEs at once thanks to an improved ADE mechanism [
7].
These changes directly affect the portability of the Energy ADE to CityGML 3.0. First, the Energy ADE is not compatible with the revised ADE mechanism. Second, some classes have been changed in terms of name, attributes, or overall hierarchical position in the data model. Thus, they do not link seamlessly to the existing Energy ADE data model anymore. Furthermore, some classes and properties in the Energy ADE are now already natively incorporated in CityGML 3.0. This makes certain Energy ADE classes obsolete or redundant—which is against the main raison d’être of an ADE, i.e., to extend the data model only where necessary. Finally, CityGML 3.0 introduces many additional classes, which potentially represent a better semantic fit from which to derive ADE classes.
The Energy ADE covers a variety of technical aspects and is a good example of how ADEs can incorporate and take advantage of new functionalities of CityGML 3.0. Additionally, there are currently no well-documented and published examples of existing ADEs being ported from CityGML 2.0 to CityGML 3.0. For this reason, this article presents the work carried out to map the Energy ADE to CityGML 3.0. The challenge and the goal have been to map the Energy ADE classes, wherever and whenever necessary, to the CityGML 3.0 data model, without any losses in terms of semantics and functional modelling capabilities. Eventually, data modelled according to CityGML 2.0 and Energy ADE 1.0 must fulfil the requirement to be convertible to CityGML 3.0 extended with the “new” Energy ADE and without any data losses. The conceptual work carried out in this process and the main implementation steps will be presented, including the data conversion and tests carried out to evaluate the mapping. Particular attention is paid to establishing a uniform, rule-based mapping and its reasoning.
Keeping these overall goals in mind, the core of the investigation has been dedicated to understanding to which extent the Energy ADE for CityGML 2.0 needs to be adapted in order to be conformant with the newly released CityGML 3.0 standard. Throughout this process, the Energy ADE 1.0 classes that become obsolete, those that need to be adapted, and those that can be mostly taken over have been identified. The resulting “new” Energy ADE for CityGML 3.0 is available both as a UML class diagram and as an XML schema definition (XSD) file. Lastly, data conversion tests are carried out using Safe Software’s FME.
When it comes to CityGML 2.0, a lot of experience has already been reported in the past decade regarding the creation of ADEs. Biljecki et al. [
8] provide an extensive review of many heterogeneous ADEs created for different application domains. Additionally, a formal UML-based approach to create ADEs has been proposed by van den Brink et al. [
9] which is based on the well-established model-driven approach and has also been applied to the development of CityGML 3.0 [
10].
However, due to the relatively recent publication of the CityGML 3.0 conceptual model, not much literature has been published up to now regarding ADEs for CityGML 3.0 or the mapping of existing ADEs to the new CityGML version.
Biljecki et al. [
11] propose how to extend CityGML 3.0 in order to convert data from IFC to CityGML 3.0. Starting from the awareness that differences in the scope and intent between IFC and CityGML lead to inevitable data losses when converting the former to the latter, the authors identify a subset of IFC data that is beneficial to keep and convert to CityGML by means of an ad hoc ADE.
In the context of Underground Land Administration (ULA), Seidian et al. [
12,
13] have recently dealt with the modelling of underground legal boundaries, in order to tackle the lack of a link between underground physical and legal data in current practices. As a result, they propose to extend CityGML 3.0 by means of the so-called VicULA (Victoria Underground Land Administration) ADE, in which underground legal data elements can be logically embedded into a 3D data model. The VicULA ADE has been specifically developed for Victoria, Australia, however, according to the authors, the proposed model and approach can be used and replicated in other jurisdictions by adjusting the data requirements for underground legal boundaries.
The Utility Network ADE [
14] represents a valuable source of inspiration for mapping an existing ADE from CityGML 2.0 to 3.0—which best resembles the core of the work presented in this article. The Utility Network ADE is openly available on GitHub not only as a UML diagram. It also includes the derived XSD schema and the accompanying configuration files to carry out the conversion using ShapeChange (more details will be provided later in the article). However, unfortunately, neither scientific publications nor detailed documentation of the process is currently available.
Finally, Bachert [
15] has recently and specifically dealt with the conversion of the Energy ADE from CityGML 2.0 to 3.0. This article is extracted from and extends this work. Therefore, as a result of the relative scarcity of available publications, this article can represent a reference for other existing ADEs to be converted to CityGML 3.0.
The following sections will provide more details on each of the above-mentioned steps. The article is structured as follows:
Section 2 describes the applied method, followed in
Section 3 by some theoretical background on the Energy ADE and the description of some updates in CityGML 3.0 that are relevant to this article. In this context, we would like to point out that we assume that the reader is already familiar with the general concepts of CityGML 2.0, CityGML 3.0, and UML modelling. The same applies to the Energy ADE, for which we only provide an overview of its main characteristics while referencing further existing literature for the reader who may want (or need) to read more extensively about it.
Section 4 contains a detailed explanation of the mapping and its logic, followed by further steps of the implementation in
Section 5.
Section 6 presents and discusses the result and
Section 7 contains the conclusions, as well as the outlook.
Although several UML excerpts from the Energy ADE, CityGML 2.0 and CityGML 3.0 are provided throughout the article, we nevertheless heartily advise the reader to have the full UML class diagrams at hand. They can be retrieved at the following links:
2. Methodology Overview
The work presented in the article follows and adapts the UML-based approach to create ADEs by van den Brink et al. [
9]. The creation of the “new” Energy ADE is complemented with the actual transformation of test data from CityGML 2.0 + Energy 1.0 to CityGML 3.0 + the “new” Energy ADE, in order to test and verify the conversion from one data model to the other without any data losses.
Overall, the developed methodology consists of three steps which are summarised in
Figure 1. Following the above-mentioned model-driven approach, first, a data model is defined at the conceptual level including its required classes, properties and relations. For this purpose, UML is chosen as the formal modelling language to define the mapped ADE. The conceptual mapping process constitutes the core of this work and is first carried out module by module in a “pen-and-paper” approach. Only afterwards, the UML class diagrams are created using the modelling software Enterprise Architect v. 13. This first step is shown in
Figure 1 in dark transparent green.
In the second step, depicted in
Figure 1 in light transparent green, the transfer format is derived from the UML data model. Here, based on the GML target encoding, an XSD schema file is derived. It specifies how to correctly read, write and validate Energy ADE GML files for CityGML 3.0. The XSD schema is created using the Java tool ShapeChange v. 2.11, which requires a specified configuration file and then automatically applies the encoding rules to the UML class diagrams.
The last, third step, depicted in light transparent blue in
Figure 1, consists of creating a CityGML 2.0 + Energy ADE test dataset which is then converted to a CityGML 3.0 + “new” Energy ADE dataset. This third step is meant to test the overall applicability of the newly mapped ADE and to prove whether data can be indeed converted without data losses. Therefore, the test dataset has been intentionally prepared to cover every feature type, property and relation of the Energy ADE at least once. Both the dataset creation and the conversion are implemented with the ETL software FME Desktop v. 2022. The conversion workspace builds upon a pre-existing template available on the FME Hub, which converts the Building module and other frequently used classes to CityGML 3.0 [
16]. The methodology briefly presented here will be described in more detail in the coming sections.
4. Mapping the Energy ADE to CityGML 3.0
As described in
Section 2, the methodology to map the Energy ADE to CityGML 3.0 consists of three main steps. This section describes the first step which comprises the detailed mapping process. In order to do so, rules that generally apply throughout all modules are defined beforehand.
Section 5 will further elaborate on the remaining two steps, namely the corresponding XSD file derivation and the creation of test data based on CityGML 2.0 and Energy ADE 1.0, as well as its conversion to CityGML 3.0 + “new” Energy ADE.
The goal is to perform the mapping without changing the contents of the Energy ADE and, thus, to convey the same information as before. However, in order to ensure logical consistency and a coherent modelling style throughout all modules, a set of mapping guidelines has been established.
4.1. Mapping Principles
The general mapping principles provide general instructions on how classes should be mapped, especially if there are several alternative possibilities. On the other hand, the overarching mapping decisions are more concrete. They are distinctive mapping rules which apply to all ADE classes and/or relations.
When it comes to the general mapping principles, they are:
“Integrate as much as possible”: According to this principle, Energy ADE classes should be integrated as “deep” into the CityGML 3.0 UML model as possible. This allows for the use of the new space and geometry concept and, thus, adds another layer of semantic meaning to the classes. In addition, the ADE classes do not need to define their own geometries anymore and can benefit from a multiple LOD representation, inherited directly from the CityGML 3.0 Core module. An alternative would be to keep the ADE classes closer to each other at a very high level in the UML model (i.e., deriving them, for example, directly from AbstractFeature). However, as a consequence, the geometry and space concept would not apply to them—which in fact would disregard one of the main changes in CityGML 3.0.
“Maintain logical symmetry”: This principle suggests that classes that are similar in the Energy ADE should be mapped in a similar way to CityGML 3.0 in order to obtain a logically consistent mapping. For example, ADE classes with a similar meaning, or at the same conceptual level, should be mapped to the same hierarchy level or be derived from the same parent class in the CityGML 3.0 data model.
On the individual level, the integration of an Energy ADE class into CityGML 3.0 depends on various factors. The primary factor is the compatibility between the ADE class and its potential parent class. An ADE class might fit multiple CityGML 3.0 classes within their specialisation path (e.g., AbstractBuilding or Building). In such cases, it has to be assessed whether additional properties and relationships of the more specialised class add value to the ADE class, or not. Additionally, a comparison is made on how similar classes are mapped to fulfil the second general modelling principle. It is also necessary to examine whether the decision might inadvertently impact other ADE classes, such as by introducing properties inherited by another ADE class.
While, in the first moment, these mapping principles may seem abstract, they will become clearer through the provided examples later on. It is however essential to note that these principles allow flexibility, sometimes offering multiple solutions in specific scenarios. Eventually, the decision is made at the level of the individual classes. Nonetheless, some specific overarching mapping decisions account for all classes and are summarised in the following list.
When it comes to the overarching mapping decisions, they are:
“AbstractFeatureWithLifespan over AbstractFeature”: AbstractFeatureWithLifespan is always preferred as the parent class over AbstractFeature. This allows for the inclusion of properties such as validFrom and validTo. Therefore, every ADE object can be depicted in various versions across its historical timeline;
“Maintain abstract classes”: Abstract classes enable the modular structure of UML class diagrams and facilitate a clear connection between the different modules. On top of that, they are kept for symmetry reasons between the original and the “new” Energy ADE;
“Keep multiplicities, relations and properties”: The multiplicities, relations and properties remain as they are unless there is a specific reason to change them in the “new” Energy ADE version.
The following part demonstrates by means of examples how the Energy ADE is concretely mapped to CityGML 3.0 with explanations of the reasoning behind it. Due to the size of the Energy ADE, the given cases cover only the most important aspects and particularities of the mapping. However, the detailed full mapping can be found in [
15]. The examples are organised by modules and are always preceded by a brief explanation of how the module is defined in the Energy ADE for CityGML 2.0.
4.2. The Core Module in the Energy ADE for CityGML 2.0
The Core module, depicted in
Figure 9, extends the CityGML abstract classes
_CityObject and
_AbstractBuilding. The CityGML 2.0 class
_AbstractBuilding is extended by means of the ADE hook mechanism to include properties needed for the computation of the building energy demand. This includes attributes regarding its geometry (e.g.,
volume,
floorArea), construction typology (
constructionWeight) and energy archetype of building (
buildingType). Additionally, information regarding
WeatherData or
EnergyDemand can be associated with every
_CityObject.
WeatherData information is needed either to perform accurate simulations or to store the pre-computed weather-related information (e.g., from solar irradiation pre-processing).
EnergyDemand, on the other hand, is used to describe an object’s time-dependent energy demand, be it in terms of electricity, (natural) gas, etc. Additionally, the Core module establishes anchor points to the remaining ADE modules by means of other abstract classes (e.g.,
AbstractThermalZone,
AbstractUsageZone) and displays their interrelations. Finally, it defines new base classes for the remaining modules and introduces new enumerations and codelists.
4.3. Mapping the Core Module to CityGML 3.0
4.3.1. BuildingProperties
As previously mentioned, additional properties are injected into
AbstractBuilding via the ADE hook mechanism. In CityGML 3.0, the new data type
BuildingProperties is derived from
ADEOfAbstractBuilding and is used to add the corresponding Energy ADE properties to CityGML 3.0
AbstractBuilding. The fully mapped Core module of the Energy ADE for CityGML 3.0 is depicted in
Figure 10.
Conveniently, some Energy ADE properties can be “replaced” by equivalent ones already provided in CityGML 3.0, i.e.,
volume,
floorArea, and
heightAboveGround. How the properties are transferred is shown using the example of
volume in
Figure 11. Likewise,
floorArea is mapped to the
area property of
AbstractSpace and
heightAboveGround to the property
height of
AbstractConstruction in the newly added Construction module of CityGML 3.0. Finally, as CityGML 3.0 centralises all geometries in the Core module, Energy ADE geometry properties such as the
referencePoint are mapped directly to the already existing
lod0Point property.
4.3.2. EnergyDemand
According to the Energy ADE for CityGML 2.0 (see
Figure 9) a
_CityObject (including its specialisation classes) can
demand multiple
EnergyDemand instances. However, association relationships cannot be added directly to any CityGML class, as this would alter the original data model. Consequently, the CityGML 2.0
_CityObject class itself must be extended by means of the ADE hook, from which the relation to the
EnergyDemand class can be defined. In this case, the new data type
EnergyADECityObjectProperties is created for the CityGML 3.0 class
AbstractCityObject. From here, the relation to
EnergyDemand is made.
When it comes to the
EnergyDemand class, the mandatory property
energyAmount is linked to a further class that is used to model time series. For CityGML 3.0, the Energy ADE
AbstractTimeSeries class (and its subclasses) is largely integrated into CityGML 3.0’s Dynamizer module. Thus, the way how properties are modelled for time-varying properties has changed considerably. Similarly, all Energy ADE classes having a property linked to a time-dependent class now require a relation to
AbstractDynamizer. CityGML 3.0 already provides a relation from any
AbstractCityObject to
AbstractDynamizer (as can be seen in the CityGML 3.0 Core module). Yet,
EnergyDemand is derived from
AbstractFeatureWithLifespan and therefore this relation needs to be created additionally. This is achieved by a relation from
EnergyDemand to
AbstractDynamizer with the role name
dynamizer. The multiplicity of 1 makes it a mandatory relation. As the property
energyAmount itself is obligatory for
EnergyDemand, the multiplicity of 1 ensures the connection to
AbstractDynamizer and, thus, serves as a security check for the modelling of time-varying property values. Beyond this, the specifics of the Dynamizer module and the time series data are explained in further detail later on, in
Section 4.9.
4.4. The Building Physics Module in the Energy ADE for CityGML 2.0
According to the Energy ADE, a building can be subdivided into one or several thermal zones (corresponding to class ThermalZone), with each zone having its own thermal behaviour. The thermal zones are delimited from each other or the exterior of the building by thermal boundaries (class ThermalBoundary). Doors, windows or other openings within the thermal boundary represent thermal openings (class ThermalOpening).
Each one of these three classes can be optionally associated with a geometry (a Solid for the
ThermalZone, and a MultiSurface for
ThermalBoundary and
ThermalOpening) to represent their explicit geometry. Please note that, by decision of the Energy ADE designers, such properties (i.e.,
volumeGeometry and
surfaceGeometry) allow only for a single representation and, thus, are decoupled from the usual LOD representation typical of CityGML [
6].
ThermalZones can furthermore contain multiple
UsageZone instances, the respective abstract class
AbstractUsageZone is depicted in the Core module. Beyond this, the thermal and optical properties of
ThermalOpening and
ThermalBoundary can be described through their relation to
AbstractConstruction.
Figure 12 depicts an overview of the Building physics module of the Energy ADE.
4.5. Mapping the Building Physics Module to CityGML 3.0
As already mentioned, there is usually more than one possibility to perform a mapping. The Building physics module is a good example thereof as it also illustrates how the mapping principles presented in
Section 4.1 come to fruition.
The first mapping option is to derive the
ThermalZone,
ThermalBoundary and
ThermalOpening classes directly from
AbstractCityObject, shown in
Figure 13. As such, the implementation would be very similar to the one in the Energy ADE for CityGML 2.0. Consequently, the classes stay close together at the same hierarchy level within CityGML 3.0. All properties remain unchanged, and the geometries are explicitly defined within the new classes.
Alternatively, the ADE classes can be integrated deeper into the CityGML 3.0 data model depending on their best semantic fit. For example, the class
ThermalZone can be subclassed from
AbstractSpace, while the classes
ThermalBoundary and
ThermalOpening become a specialisation of
AbstractSpaceBoundary (see
Figure 14). In this way, some of the Energy ADE properties can be mapped to already existing CityGML 3.0 ones, as seen before in the case of
AbstractBuilding. Additionally, the geometries do not need to be explicitly defined inside the ADE classes anymore, as they are now inherited from those existing in the CityGML 3.0 Core module. Besides, the space concept in the Core module enriches the ADE classes with an additional level of semantic meaning.
Due to these reasons, the latter mapping approach is the preferred one and is further pursued. In the following, it is discussed how the three Energy ADE classes are modelled in detail.
4.5.1. AbstractThermalZone and ThermalZone
In CityGML 3.0, an
AbstractLogicalSpace class and its subclasses are defined via thematic considerations and, thus, they fit the intrinsically logical concept of a
ThermalZone. Although
AbstractLogicalSpace is a suitable superclass itself, it is relatively generic compared to its more specialised subclasses. Moreover, the mapping principles foresee the integration of ADE classes as deep as possible into the CityGML 3.0 data model to add value. Hence, a closer look at
BuildingUnit as a potential parent class is taken. A
BuildingUnit is a “logical subdivision of a Building […] formed according to some homogeneous property” [
7]. In the case of the
ThermalZone class, this homogeneous property relates to the isothermal volume making up a thermal zone. However, having
BuildingUnit as the parent class for
ThermalZone results in an interrelation conflict with the Energy ADE class
BuildingUnit in the Occupant behaviour module. Anticipating some mapping decisions in the Occupant behaviour module, the ADE
BuildingUnit is merged into the CityGML 3.0
BuildingUnit by adding properties via the usual ADE hook mechanism. However, these additional properties could then also be inherited by
ThermalZone, eventually leading to a logical inconsistency (the details of this reasoning will become more evident when describing the mapping of the Occupant behaviour module in
Section 4.7). In order to avoid such logical inconsistencies,
AbstractThermalZone is subclassed from
AbstractBuildingSubdivision.
Figure 15 illustrates the different mapping options.
As seen before, the attributes floorArea and volume can be replaced through this mapping by area and volume of AbstractSpace. Furthermore, the geometry property volumeGeometry of ThermalZone can be replaced (i.e., inherited) by the geometry defined in the CityGML 3.0 Core module.
4.5.2. ThermalBoundary and ThermalOpening
In order to utilise the CityGML 3.0 properties for the Energy ADE
ThermalBoundary and
ThermalOpening classes, they have to be derived from the class
AbstractThematicSurface or one of its specialised thematic surface classes. For visual reference, an excerpt of the CityGML 3.0 UML class diagram for thematic surfaces is provided in
Figure 16.
Again, several mapping possibilities exist. One option is to derive the class
ThermalBoundary from
AbstractConstructionSurface and the class
ThermalOpening from
AbstractFillingSurface. In this case, the relation
fillingSurface between the CityGML 3.0 parent classes (see
Figure 16) could replace the
contained relationship between
ThermalBoundary and
ThermalOpening in the Energy ADE (see
Figure 12).
Although the class ThermalOpening fits semantically well with AbstractFillingSurface, there is a slight mismatch between ThermalBoundary and AbstractConstructionSurface. The AbstractConstructionSurface class is meant to bind CityGML 3.0 Construction features (a subclass of AbstractOccupiedSpace). However, a ThermalZone is a logical space and does not fall under the category of a construction. Hence, ThermalZone cannot be bound by a construction surface.
Technically, it is possible to model the Energy ADE classes at different “levels” in the CityGML 3.0 UML diagram. But according to the general mapping principles, similar classes should ideally be derived from the same or comparable parent classes. As such, logical consistency and therefore an easier understanding of the UML diagrams can be ensured. Eventually, a semantically correct mapping, together with the principle of maintaining logical symmetry, outweighs the deeper integration into the CityGML 3.0 UML data model. As a result, ThermalBoundary and ThermalOpening are both mapped to the more generic CityGML 3.0 class AbstractThematicSurface. Regarding attributes, area in ThermalBoundary and ThermalOpening can be replaced by the area property of AbstractThematicSurface. The surface geometries are also replaced by the corresponding CityGML 3.0 geometries defined in its Core module.
The complete UML diagram of the resulting mapped Building Physics module is shown in
Figure 17.
4.6. The Occupant Behaviour Module in the Energy ADE for CityGML 2.0
In the Energy ADE, the Occupant behaviour module defines classes to model different usage zones and how they are utilised by occupants and facilities such as electrical appliances (see
Figure 18). By including schedules, it is possible to represent their behaviour over the day, year, etc. Central to the module is the class
UsageZone, which defines regions of homogenous usage with regard to their occupants and included facilities. Its properties describe factors affecting the indoor temperature (
heatingSchedule,
coolingSchedule,
ventilationSchedule) and the usage type (
usageZoneType). Moreover, a
UsageZone may contain several
BuildingUnit instances, which specify ownership information. To further specify internal heat gains,
BuildingUnit and
UsageZone both have relations to
Occupants and
Facilities (
LightingFacilities,
DHWFacilities,
ElectricalAppliances).
Similarly to what was mentioned before for the Building physics module, class UsageZone can be optionally associated with a solid geometry. Also, in this case, the volumeGeometry property allows only for a single representation and, thus, is decoupled from the usual LOD representation of CityGML.
4.7. Mapping the Occupant Behaviour Module to CityGML 3.0
4.7.1. AbstractUsageZone and UsageZone
Given the previous definition of the CityGML 3.0
BuildingUnit class, it qualifies as a fitting parent class for the Energy ADE’s
UsageZone. Since
UsageZone shows similar traits to
ThermalZone in the Building physics module, the same issue of potentially inheriting unwanted properties occurs when the class
BuildingUnit is extended via the ADE hook (see
Figure 19). Consequently,
AbstractUsageZone is also mapped to the next higher generalisation class,
AbstractBuildingSubdivision. As a result,
BuildingUnit does not serve as a generalisation class for
AbstractUsageZone and
AbstractThermalZone and unwanted properties are not passed on to them. In addition, this solution satisfies the principle of logical symmetry between the two similar classes
ThermalZone and
UsageZone.
4.7.2. BuildingUnit
The concepts of the CityGML 3.0
BuildingUnit and of the Energy ADE
BuildingUnit, which specifies ownership information, match rather well. Because the classes already have the same name and also fit semantically, the CityGML 3.0 class is extended through the ADE hook mechanism to include the additional properties (via the DataType
BuildingUnitOccupancy). This eventually leads to the mapping shown in
Figure 20.
A positive side-effect of this mapping solution is that BuildUnit now inherits a property for a volumetric geometry through its integration with the CityGML 3.0 space and geometry concept. The property floorArea is mapped to the corresponding CityGML 3.0 property and the relation to Address is also already provided.
4.8. The TimeSeries Classes in the Energy ADE for CityGML 2.0
In the Energy ADE, the time series classes are meant to facilitate the modelling of time-varying attribute values. For this, properties in other modules have the property type
AbstractTimeSeries (see e.g., property
energyAmount of class
EnergyDemand shown in
Figure 21).
Figure 22 shows how the
AbstractTimeSeries class is further specialised into four subclasses to deal with either regular or irregular time series, possibly stored in-line or in external files. Regular time series have a given time period (
temporalExtent) and time interval (
timeInterval) for the measurements. Irregular time series, on the other hand, provide a specific timestamp for every measurement value. Additionally, some metadata can be provided via associated enumeration classes.
4.9. Mapping the TimeSeries Classes to the Dynamizer Module in CityGML 3.0
One of the major additions to CityGML 3.0 is the ability to model time-dependent attribute values by means of the Dynamizer module. A Dynamizer object can be associated with each property of an
AbstractCityObject class (and therefore all its subclasses) via the relation to
AbstractDynamizer. The details on the modelling of such properties are beyond the scope of this article; however, further information can be found in [
17].
In the Energy ADE, the classes EnergyDemand, WeatherData and EnergyFlow have the time-dependent properties energyAmount, values, and energyAmount, respectively. However, as these classes are derived from AbstractFeatureWithLifespan and not from AbstractCityObject, they do not inherit the relation to AbstractDynamizer. Thus, a new ad hoc relation must be modelled from the respective ADE class to AbstractDynamizer. Because the time-varying properties in the Energy ADE are mandatory, they are required to be referenced by a Dynamizer instance. This is emphasised through the multiplicity of 1 from the respective ADE class to AbstractDynamizer. In addition, a descriptive note states in the UML diagram which of the properties is to be referenced by Dynamizer.
With the new modelling technique of time-varying properties, their property types also need to be updated, as they are now expressed as a static value in the respective class. Therefore, as time series consist of values of complex type measure (i.e., value + unit of measure), their type must be set to
Measure. An example in terms of UML is shown in
Figure 23 for the classes
EnergyDemand (property
energyAmount) and
WeatherData (property
values).
4.9.1. IrregularTimeSeries
The class IrregularTimeSeries of the Energy ADE conceptually corresponds to the class GenericTimeseries of the Dynamizer module. The time-value pair itself (Energy ADE: MeasurementPoint/CityGML 3.0: TimeValuePair) is modelled in both cases with a property for the timestamp (time/timestamp) and one for the value (value/doubleValue) and, thus, can be mapped directly. However, the uom attribute of the class is mapped to the uom attribute of the class AbstractAtomicTimeseries.
4.9.2. IrregularTimeSeriesFile
In a similar way,
IrregularTimeSeriesFile is mapped to
TabulatedFileTimeseries. Only the property
recordSeparator cannot be mapped to any of the CityGML 3.0 properties and is therefore added via the ADE hook mechanism through the new data type subclass
TabulatedFileTimeseriesExtension. In addition to the CityGML 3.0 class
TabulatedFileTimeseries, another class also handles externally stored time series:
StandardFileTimeseries. It references files in standardised formats such as the OGC Observations & Measurements Standard or OGC TimeseriesML [
7]. Nevertheless, mapping
IrregularTimeSeriesFile to this class is not suitable as this would require altering the input file or losing properties.
4.9.3. RegularTimeSeries
In the Energy ADE, RegularTimeSeries stores an array of time-dependent values together with its total temporal extent, defined as start and end timestamps, and the interval between the timestamp of each value. However, the Dynamizer module of CityGML 3.0 does not offer an equivalent class to the Energy ADE RegularTimeSeries. The closest candidate would be GenericTimeseries, which however requires that each time-dependent value be stored together with its accompanying timestamp. The additional timestamps for each value could be computed using the information provided by the original Energy ADE RegularTimeSeries data. Choosing the GenericTimeseries as target class would, however, lead to a far less compact representation compared to the Energy ADE RegularTimeSeries. Thus, opting for this mapping strategy—besides being rather impractical—contradicts the purpose of a compact encoding by the RegularTimeSeries.
As a result, an alternative mapping strategy is preferred: A new class RegularTimeseries (please note the small s in Timeseries to match the naming style of other Dynamizer classes) is derived from AbstractAtomicTimeseries. The goal is to overcome the above-mentioned limitations. Furthermore, the attribute temporalExtent is mapped to the properties firstTimestamp and lastTimestamp of the Dynamizer class AbstractTimeseries.
4.9.4. RegularTimeSeriesFile
Also, for the Energy ADE class
RegularTimeSeriesFile there is no predefined class in the Dynamizer module. The closest option,
TabulatedFileTimeseries, requires a value for either
timeColumnNo or
timeColumnName, meaning that a column containing the timestamps
must be specified. However, such a column does not exist in a regular time series file. Several options were considered on how to best map the
RegularTimeSeriesFile to the Dynamizer module. Among them are manually adapting the input file, creating a separate ADE class, or creating a shared
AbstractRegularTimeseries class for
RegularTimeseries and
RegularTimeseriesFile. All of them are discussed in detail in [
15].
Eventually, the implemented mapping uses the
TabulatedFileTimeseries nonetheless, but with a workaround for the OCL constraint. One of the required properties, which indicates the column for the timestamps in the referenced file (
timeColumnName), asks for a CharacterString data type. When using the
TabulatedFileTimeseries class for regular time series files, this property can simply be given a NaN (Not a Number) or string value expressing that such a column is not included. Additionally, the ADE property
timeInterval is added to
TabulatedFileTimeseries via the ADE hook mechanism. This solution has the advantage of using existing classes rather than creating new ones. Therefore, the UML model remains more compact and avoids modelling repetitive information. Last but not least, it follows the mapping principles of logical symmetry and integrating as much as possible. The resulting final UML class diagram, covering the mapping of the Energy ADE classes for time series, is provided in
Figure 24.
4.10. The Schedules Classes in the Energy ADE for CityGML 2.0
Class
AbstractSchedule and its subclasses, as seen in
Figure 25, are part of the Supporting classes module of the Energy ADE. Therefore, they are referenced by the other modules in a similar way as the
AbstractTimeSeries class. Schedules are used to describe to which extent features or appliances are operated in a certain time period.
The specialisation classes of AbstractSchedule are characterised by increasing degrees of freedom regarding how the schedules can be designed. The most general option is ConstantValueSchedule which specifies one single value for average usage. Further, DualValueSchedule differentiates between idle and operating times. The DailyPatternSchedule models change operation times based on the period of the year and the day. Lastly, the TimeSeriesSchedule gives complete freedom by modelling the usage through a custom-defined time series.
4.11. Mapping the Schedule Classes to CityGML 3.0
When it comes to mapping the Energy ADE schedules, no directly corresponding concept exists in CityGML 3.0. Thus, they can be mapped in a simpler way than the time series, although some adjustments are still required.
For example, in the Energy ADE, the classes have the stereotype «type». Within CityGML 3.0, this stereotype is not used anymore for application schemas. Nevertheless, to be able to reference the schedules via XLinks, as is very often the case in this context, the new stereotype requires a unique identifier. Because of this reason, «DataType» cannot be used for this purpose. Instead, the classes are given the stereotype «FeatureType».
As
AbstractSchedule needs to be linked to one of the existing classes within the CityGML 3.0 model, the parent class
AbstractFeatureWithLifespan is selected. Choosing instead
AbstractCityObject as a parent class would not be a conceptually logical solution, because schedules are neither a city object nor do they have a spatial extent. At a higher level,
AbstractFeature would be a possible choice, as it is more general. Still, in coherence with the
general mapping principles, this is not the preferred option.
AbstractFeatureWithLifespan offers instead a deeper integration into the data model and furthermore ensures logical symmetry with
AbstractDynamizer, which also derives from it. The excerpt from the UML class diagram depicted in
Figure 26 shows these relations.
The properties of the mapped Energy ADE classes that are described via schedules have now the property type
AbstractSchedule. This in-line representation (in the original Energy ADE) is de facto the same as the relation by reference from a feature type to
AbstractSchedule (see
Figure 27) in the mapped version for CityGML 3.0.
4.11.1. ConstantValueSchedule and DualValueSchedule
The classes are changed to «FeatureType» and are subclassed from AbstractSchedule. None of their properties can be mapped to CityGML 3.0, therefore, the overall structure remains nearly identical to the original Energy ADE.
4.11.2. TimeSeriesSchedule
The only property timeDependingValues specifies, as a ratio, how much something is used over a given time and, as such, does not need a unit of measure. The time-dependent values can be modelled through a connection to AbstractDynamizer. Here, the user is free to choose which class in the Dynamizer module best describes the intended time series.
4.11.3. DailyPatternSchedule
Two options for mapping the class
DailyPatternSchedule were considered. In the first one, the original Energy ADE structure (i.e., as compositions of
PeriodOfYear and
DailySchedule) is simply recreated for CityGML 3.0. Alternatively, the
CompositeTimeseries and
TimeseriesComponent in the Dynamizer module are used to re-model the nested structure of the Energy ADE class
DailyPatternSchedule. This second mapping choice is made possible in CityGML 3.0 because the class
CompositeTimeseries can contain multiple instances of the class
TimeseriesComponent, which are themselves associated with any of the available time series derived from the class
AbstractTimeseries (see
Figure 28).
To pursue this second modelling approach, the Energy ADE class
DailySchedule is mapped to the data type
TimeseriesComponent. Yet, its property
dayType cannot be included in
TimeseriesComponent, because the ADE hook mechanism does not apply to data types. As a workaround
dayType is added to
AbstractAtomicTimeseries through an ADE hook instead because every
TimeseriesComponent is eventually described by the other time series. Furthermore, the
period property of the class
PeriodOfYear has to be mapped to two different classes within the Dynamizer module due to the flexibility the nested structure of
DailyPatternSchedule gives. If a
DailyPatternSchedule has only one time period, the property can be added to
CompositeTimeseries with the ADE hook mechanism. If a
DailyPatternSchedule has multiple time periods (
PeriodOfYear), the
period property is directly attached to the time series. This is realised through a hook to the class
AbstractAtomicTimeseries. The new properties added to the Dynamizer module for the
DailyPatternSchedule are summarised in
Figure 29.
With this mapping solution, even though it is rather complex, the class DailyPatternSchedule for CityGML 3.0 requires only the property timeDependingValues and a connection to AbstractDynamizer. As such, it makes use of the concepts already available in CityGML 3.0 and adheres to the general mapping principles.
6. Results and Discussion
In this section, the results are presented, and the implemented mapping strategy, its implications, and the lessons learnt are discussed. The reflection will cover mainly the chosen level of integration between the Energy ADE and the CityGML 3.0 data model, the resulting geometry representation and how the gained insights can be beneficial for the development (or conversion) of other ADEs in the context of CityGML 3.0.
Regarding the mapping results, an excerpt is contained in
Table 1. It contains three classes, indicating how much they have changed during the mapping process, as well as some relevant details. The classes shown in
Table 1 are chosen to provide three representative examples. For space and readability reasons, the table containing all classes is presented in
Appendix A.
In the table, the status “Mostly taken over” means that only some minor changes were necessary to fit CityGML 3.0. “Adapted” refers to some major adjustments and “Obsolete” tells that the Energy ADE class was completely replaced by a CityGML 3.0 one. For example, the ADE properties for _AbstractBuilding were mapped to native CityGML 3.0 properties wherever possible and were furthermore adapted according to the restructured ADE hook mechanism. These are not structural changes, which is why this mapping is categorised as “Mostly taken over”. On the other hand, the class AbstractEnergySystem was mapped to a new generalisation class which integrates it into the new space and geometry concept. In the Energy ADE for CityGML 2.0, the class could not be represented geometrically. These changes alter the structure of the Energy ADE class, which is thus assigned the status “Adapted”.
6.1. Level of Integration
The resulting data model of the Energy ADE for CityGML 3.0, together with the developed XSD file and FME workbench, prove that a data conversion can be successfully carried out without any data losses. The mapping procedure has followed the guidelines listed in
Section 4.1, which allow for a uniform mapping on a logical and conceptual level. However, sometimes there is more than one possible solution to perform the mapping. Thus, for the sake of completeness, two possible alternative mapping strategies are briefly outlined in the following subsections, although they were ultimately not implemented and only the mapping strategy presented in
Section 4 was used to obtain the XSD file and the FME workbench. We have called them “minimum” and “middle ground” mapping strategies.
6.1.1. Minimum Mapping
The so-called “minimum mapping” approach could be seen as a sort of brute-force mapping, in which only strictly necessary “technical” adjustments would be made for the Energy ADE to work with CityGML 3.0. In other words, all Energy ADE classes would be derived directly from CityGML 3.0 AbstractCityObject or AbstractFeature, without any further reasoning on exploiting the new classes and concepts of CityGML 3.0.
Some of the strictly necessary “technical” adjustments would be required due to the revised ADE hook mechanism of CityGML 3.0. Moreover, the generalisation class names would need to be updated according to the new standard (e.g., from _CityObject to AbstractCityObject). At last, the stereotype «type» in ServiceLife, WeatherData, the time series and schedules classes would need to be adapted to a viable alternative. It remains open to further investigation how time series could be dealt with in this scenario. The closest option to the original Energy ADE would be to change the classes to the stereotype «FeatureType» and use AbstractFeature as the parent class for AbstractTimeSeries. This solution, not further followed in our mapping of time series, however, was used to map the Energy ADE schedules.
The result of a “minimum mapping” approach would lead to a resulting data model that is “closer” to the original Energy ADE for CityGML 2.0. On the one hand, it would offer a less complex solution than the proposed one by keeping the classes closer together and deriving them all from CityGML 3.0 classes that are rather high up in the hierarchy (AbstractFeature, AbstractCityObject). On the other hand, it would not take into account many of the changes in CityGML 3.0. None of the classes would be derived from classes of a lower hierarchy level than AbstractCityObject and would thus not utilise the newly introduced space and geometry concept. Therefore, the geometries would need to be explicitly defined, none of the properties could be replaced by CityGML 3.0 ones, and the ADE classes would furthermore not benefit from any of the additionally provided semantics. As a result, a lot of redundant information would be created through this mapping approach, which is not the purpose of an extension of the given data model.
6.1.2. Middle Ground
A second possible alternative could consist of a compromise between the “minimum mapping” approach and its opposite one, i.e., the implemented “integrate as much as possible” approach. Here, the ADE classes could be integrated into the CityGML 3.0 space and geometry concept where the semantic relation is evident. However, only abstract space classes would be considered. AbstractThermalZone would then for instance either be subclassed from AbstractSpace or AbstractLogicalSpace. Furthermore, Energy ADE classes without geometries would remain subclassed from AbstractCityObject (i.e., Facilities). For the remaining classes, it would remain open to discussion whether to derive them from AbstractFeature or AbstractFeatureWithLifespan.
This middle-ground solution would utilise the CityGML 3.0 geometries where applicable, while not giving new ones to ADE classes that did not have them before. Additionally, it would also provide some additional contextual information. Thus, this strategy would benefit from some of the updates in CityGML 3.0, and at the same time, keep the Energy ADE closer to the original one.
Both herewith discussed alternative mapping approaches could probably be implemented, also without any loss of information. The only major difference would consist in the different levels of integration with CityGML 3.0 and, therefore, how much additional context is provided. Yet, as opposed to these two mapping options, the actually implemented one accounts for all changes and new features in CityGML 3.0. It adheres to the strategy proposed in the CityGML 3.0 Conceptual Model Standard, i.e., to derive the classes according to their best semantic fit. Moreover, it also complies with the CityGML 3.0 developers’ ideal that as little as possible be derived from AbstractCityObject itself.
6.2. Geometry Representation
Several Energy ADE classes which were formerly derived from _CityObject are now subclassed from CityGML 3.0 classes further down in the hierarchy. This tighter integration with the space and geometry concepts has several advantages.
First, the existing CityGML 3.0 geometries are now reused instead of explicitly defining them in the ADE classes themselves. Through this, a multi-geometry representation in different LODs of the Energy ADE classes is now possible for Energy ADE classes derived from AbstractCityObject or its subclasses. In the Energy ADE for CityGML 2.0, only one geometry representation is foreseen per class. Since this restriction does not apply anymore in the case of the Energy ADE for CityGML 3.0, guidelines should be provided on how to best apply these new modelling possibilities. For instance, it is now possible to model a ThermalZone in LOD2 or in LOD3. But how and when? We believe that, in general, a good starting point is the common LOD notion as defined in CityGML 3.0, that could be applied and adapted to the use case.
Another result of the deeper integration into the CityGML 3.0 data model is that some Energy ADE classes can now be represented through geometries as opposed to before. This is the case for all classes which formerly derived from _CityObject such as Facilities or subclasses of AbstractEnergySystem. However, their geometric representation remains optional, so that no additional conditions are required.
Nevertheless, some additional specific rules for the geometry representation of individual classes should be defined, such as a maximum LOD or mandatory relations to other classes and their geometries (i.e., geometry representation of Facilities only through lod0Point). However, these particular definitions go beyond the scope of this research.
Seemingly, this contradicts the aim of this work to map the Energy ADE without any changes in its content and functionalities. While this is true to some extent, the pros of the overall logic and consistent mapping outweigh the resulting cons. The resulting issue of the extended functionality could be circumvented by restricting the geometric modelling of those classes as described before. This way, the CityGML 3.0 modelling style would be respected without extending the functionalities of the Energy ADE.
6.3. Considerations beyond Mapping
The goal of this research was to map the Energy ADE to CityGML 3.0 without changing its content or functionalities. However, the thorough examination of both those data models resulted in insights/possibilities on changes beyond mere mapping. While these options were not implemented, they are nonetheless briefly presented at this point. For a more detailed explanation, the reader is invited to refer to [
15].
First, the mandatory relation to the Dynamizer for the Energy ADE classes with time-dependent properties could be instead modelled as optional. This way, such properties could also be represented in a simplified way by a single static value. Second, the ADE class RegularTimeseries, which is added to the Dynamizer module, only accepts numeric values for its property values. Yet, the similar CityGML 3.0 class GenericTimeseries also allows other data types for the values such as Booleans or strings. Allowing them in RegularTimeseries as well would make the class more flexible and also more coherent to CityGML 3.0.
These examples show that not all changes of CityGML 3.0 can be used with the applied mapping approach. One reason for this is that the original Energy ADE was developed for CityGML 2.0. A newly modelled Energy ADE specifically for CityGML 3.0 would thus most likely lead to a different result.
On this note, we would also like to suggest the incorporation of class RegularTimeseries into future releases of CityGML 3.0. The modelling solution that we propose represents a more space-efficient encoding compared to the current GenericTimeseries.
7. Conclusions
The release of CityGML 3.0 comes with many changes, which, on the one hand, imply that Application Domain Extensions developed for its previous version cannot function anymore with the latest version unless some adjustments are made. On the other hand, CityGML 3.0 opens up new opportunities for ADEs to make use of its extended functionalities such as the centrally defined space and geometry concepts, newly introduced classes and properties, as well as the possibility to model time-dependent attribute values using the Dynamizer.
This article has investigated the possibilities of how these changes affect ADEs using the example of the Energy ADE, and how an ADE can be mapped to CityGML 3.0 without reducing its modelling capabilities. The Energy ADE was chosen as it is one of the most complex (and best documented) ADEs currently available for CityGML 2.0 and it covers different data modelling strategies when it comes to extending CityGML, as well as different simple and complex data types, including codelists and enumerations.
The mapping of the Energy ADE from CityGML 2.0 to 3.0 was carried out following a model-driven approach, as it is the suggested approach for CityGML 2.0 ADEs and upon which CityGML 3.0 was developed, too. To test the validity of the mapping and the actual data transformation, a CityGML 2.0 + Energy ADE sample dataset was created and successfully converted to CityGML 3.0 + “new” Energy ADE in FME. The resulting FME workbench, as well as the generated XSD schema file for the Energy ADE, are publicly available via a GitHub repository.
The results show that a mapping of the Energy ADE to CityGML 3.0 is indeed possible. When performing the mapping, the “integrate as much as possible” approach was chosen and implemented, although other alternative approaches (also briefly mentioned in this article) could have been adopted. As a result, the “new” Energy ADE has become more compact through the mapping of attributes and the replacement of all geometries by means of the centrally defined geometry concept in CityGML 3.0. Furthermore, the ADE classes are now semantically richer due to the new space concept and their mapping to more specialised classes within the CityGML 3.0 data model. Some time series classes could be fully replaced by CityGML 3.0 classes in the Dynamizer module.
Of course, only more testing and further implementations will show the overall applicability of the developed mapping approach, for the Energy ADE in this specific case, but also for other existing ADEs to be ported to CityGML 3.0. Nevertheless, given the scarcity of existing publications and documentation on this specific topic, together with the limited number of available examples, we believe that our experience may contribute to narrowing the knowledge gap and serve as an example for other ADEs to follow.