The Energy Application Domain Extension for CityGML: enhancing interoperability for urban energy simulations

Abstract

The road towards achievement of the climate protection goals requires, among the rest, a thorough rethinking of the energy planning tools (and policies) at all levels, from local to global. Nevertheless, it is in the cities where the largest part of energy is produced and consumed, and therefore it makes sense to focus the attention particularly on the cities as they yield great potentials in terms of energy consumption reduction and efficiency increase. As a direct consequence, a comprehensive knowledge of the demand and supply of energy resources, including their spatial distribution within urban areas, is therefore of utmost importance. Precise, integrated knowledge about 3D urban space, i.e. all urban (above and underground) features, infrastructures, their functional and semantic characteristics, and their mutual dependencies and interrelations play a relevant role for advanced simulation and analyses.

As a matter of fact, what in the last years has proven to be an emerging and effective approach is the adoption of standard-based, integrated semantic 3D virtual city models, which represent an information hub for most of the above-mentioned needs. In particular, being based on open standards (e.g. on the CityGML standard by the Open Geospatial Consortium), virtual city models firstly reduce the effort in terms of data preparation and provision. Secondly, they offer clear data structures, ontologies and semantics to facilitate data exchange between different domains and applications. However, a standardised and omni-comprehensive urban data model covering also the energy domain is still missing at the time of writing (January 2018). Even CityGML falls partially short when it comes to the definition of specific entities and attributes for energy-related applications.

Nevertheless, and starting from the current version of CityGML (i.e. 2.0), this article describes the conception and the definition of an Energy Application Domain Extension (ADE) for CityGML. The Energy ADE is meant to offer a unique and standard-based data model to fill, on one hand, the above-mentioned gap, and, on the other hand, to allow for both detailed single-building energy simulation (based on sophisticated models for building physics and occupant behaviour) and city-wide, bottom-up energy assessments, with particular focus on the buildings sector. The overall goal is to tackle the existing data interoperability issues when dealing with energy-related applications at urban scale.

The article presents the rationale behind the Energy ADE, it describes its main characteristics, the relation to other standards, and provides some examples of current applications and case studies already adopting it.

Introduction

According to the United Nations [35], 54% of today’s world population lives in cities, and by 2050, further 2.5 billion people will be added to the urban population. This urbanisation trend yields a number of challenges ranging from the identification of effective strategies on how to guarantee all the basic services (e.g. water, energy, etc.) to everyone in a cost-effective and environmentally friendly way, to the reduction of the environmental impact associated. Today, cities are responsible for 71% of the greenhouse gas emissions greatly contributing to climate change and air pollution [17].

Facing these challenges demands for a holistic urban planning perspective considering the different aspects of sustainable development, namely the economic, environmental and social ones. One of the crucial points is to reconcile urban planning with environmental targets, which include decreasing energy demand and CO₂ emissions, and increasing the share of renewable energy.

In order to support the energy transition process at city scale, Urban Energy Modelling [4, 31] has been experiencing a steady increase in terms of popularity in the last decade: many actors, ranging from international research centres to private sector, have been developing specific algorithms and software solutions providing new digital methods for energy planning and decision support. Decision makers in municipalities, housing authorities, energy supply companies and other stakeholders are slowly realising the enormous potential of such tools and progressively adopting them.

These new methods and tools invert the classical top-down approach as seen so far in the past decades, and propose a more detailed, mostly bottom-up, modelling approach, which generally starts at the building level in terms of granularity and spatial resolution.

For energy planning purposes, for example, a comprehensive knowledge of the demand and supply of energy resources, including their spatial distribution within urban areas, is of utmost importance. Precise and comprehensive knowledge about urban space, infrastructures, and underground features is thus required for simulation and analysis.

Given the number of stakeholders involved in a city, obtaining (and managing) such detailed information for each urban feature is however often a rather complex and resource-demanding task, as it requires to gather, harmonise, integrate, and eventually manage heterogeneous data for a large quantity of objects for the whole city. Therefore, efficient exchange of harmonised good quality data from heterogeneous sources among the different urban actors, on one hand, and among the different software tools, on the other hand, is fundamental to realise sound and holistic analyses [28]. In other words, data interoperability plays a fundamental role in all steps regarding Urban Energy Modelling. And the adoption of standards is the key to overcome said complexity, and, in the end, the most reasonable way which should be further pursued – especially whenever reliable open standards exist.

Open data models for the built environment

When it comes to the modelling of the built environment, only a relatively small number of open model standards exist, the common goal being to ease interoperability between heterogeneous software platforms. However, they are strongly dependent on the scale and application domain they are conceived for.

For single buildings – it is the case of the Building Information Model (BIM) domain – the two most commonly adopted open standards are either IFC (Industry Foundation Classes)¹² or gbXML (green building XML).³ The former is intended to describe building and construction-industry data, supporting all phases of the building’s lifecycle, i.e. planning, construction, usage, renovation and demolition. The latter is specially designed as an open schema for sharing building information between disparate building design and simulation software tools. Both data models cover 3D geometry and semantics.

Similarly to BIM – however at urban scale –, the terms Urban Information Model (UIM) [16] or City Information Model (CIM) [37] have been proposed in recent years. One of the fundamental differences resides however in the overall shift when it comes to the geometry modelling paradigm: from the constructive-solid-geometry and parametric modelling one, typical of the BIM world, to the boundary-representation one, typical of the GIS world.

As a matter of fact, semantic 3D city models [15] have been steadily gaining momentum in the last decade as they offer an integrated and harmonised information hub for a theoretically unlimited number of geospatial application. An integrated virtual city model can represent coherently all city entities, spatially and (possibly) in 3D, together with all relevant characteristics, relations and dependencies. What is more, it can reduce the effort in terms of data preparation and provision, and, secondly, offer clear data structures, ontologies and semantics to facilitate data exchange between different domains and applications.

When working at city scale, the number of choices with regards to open and standard data models comprises essentially only CityGML [21]⁴ and – at least for the European Union – the INSPIRE [5] Data Specification on Buildings⁵ (which, in part, takes inspiration from CityGML itself). Although they share common concepts, their modelling granularity is dependent on the scale and purpose, with CityGML being essentially conceived for the city and regional scale, and INSPIRE for the cross-border/international level. At the same time, CityGML guarantees a certain overlap with the BIM domain, given its semantic and spatial granularity that, for the buildings, reaches down till the room level. An exemplary representation is given in Fig. 1.

Fig. 1

Qualitative comparison of suitability of INSPIRE, CityGML and BIM data models with regards to territorial scales

In particular, CityGML is an open data model and information exchange standard by the Open Geospatial Consortium,⁶ defining classes and relations for the most relevant 3D topographic objects in cities (e.g. buildings, transportation infrastructures, city furniture, water bodies) regarding their geometry, topology, semantics, and appearance. The representation of buildings includes semantically distinct geometries for basement slabs, wall and roof surfaces, as well as specific attributes for the description of the roof shape, usage type, number of storeys, construction year, and building height.

Of relevance is the possibility to extend CityGML by means of so-called Application Domain Extensions (ADE): depending on the specific needs, new features or properties can be added, hence greatly augmenting modelling capabilities offered by CityGML.

Open energy data models for the built environment

When narrowing down the focus from general-purpose open data models to specific (open) energy data models, the already mentioned gbXML is the most widely used data exchange format between different modelling software products for energy analysis at building scale. However, at city scale, there is still a lack of a complete and published open standard data model at the time of writing (January 2018). INSPIRE envisions indeed a limited number of energy-related attributes for buildings (e.g. connections to networks, energy performance, heating source and system) however they are far too few to cover the needs of complex multi-domain applications.

Even CityGML, intentionally conceived as an application-independent information model, partially falls short: some attributes like the year of construction, the building class and usage are provided, but, again, they are too few. Additional attributes can indeed be defined, but they cannot be stored natively in a systematic and standard way. As a consequence and to add to the complexity, the existing tools for assessment of energy-topics at urban scale often rely on proprietary, application-specific, and sometimes closed data formats, de facto nullifying data interoperability.

For this reason, and – originally – in order to cross-validate their respective urban energy simulation platforms, the University of Applied Sciences Stuttgart (HFT) and the Technical University of Munich (TUM) started working together in 2013 on the harmonisation of their data models into a unique extension of the CityGML information model, called Energy ADE. Since then, several international partners have joined this initiative. In May 2014 an international group of experts from 11 European organisations from Germany, France, Italy, Switzerland and Austria was set up to plan the further development of the Energy ADE on a common, cooperative and consensus-driven basis. The development groups of six urban energy simulation platforms joined the group from the beginning: CitySim [32], SimStadt [28], EnergieAtlas [18], Modelica library AixLib [24], the SUNSHINE platform [14] and the Curtis platform [9]. The intense collaborative work led to the frequent release of new development versions of the Energy ADE, on average every 6 months, e.g. from version 0.4 (May 2014) till version 1.0 (January 2018).

The goal of the Energy ADE is to provide a unique and standard-based data model to overcome, on one side, the above-mentioned data interoperability issues and, on the other side, to allow for both detailed single-building energy simulations and city-wide bottom-up energy assessment. The Energy ADE focuses primarily on the building, its physical properties and the systems installed in it. It is not meant to cover urban centralised energy infrastructures, like district heating system or gas networks, as they are instead the focus of another application domain extension, namely the Utility Network ADE [23]. Some parts of the Energy ADE can however be used beyond the building scale to characterise, for example, the energy demand of other urban objects like street lamps, or the energy production of power plants.

This paper introduces and describes the latest and current release of the Energy ADE, version 1.0. It further presents some software solutions, as well as concrete case studies, in which the Energy ADE plays a role in facilitating data interoperability for energy-related applications, although at different levels of integration.

The article is structured as follows. The following The energy ADE: data model section constitutes the major contribution of the article and gives first a general overview of the Energy ADE and its characteristics, then it describes more in details the different modules composing it and briefly explains the relation of the Energy ADE with regards to another ADE, namely the Utility Network ADE. The energy ADE: database implementation section describes how a database schema of the Energy ADE was derived and implemented, extending the already freely available 3D City Database (i.e. the reference database implementation of the CityGML standard), in order to allow for storage of all Energy-ADE-related data. The energy ADE: examples of software applications section contains some examples of software solutions and applications which already exploit the Energy ADE, in addition some experiences from case studies in different cities and projects are also reported. Conclusions section contains the conclusions, the lessons learned, as well as a summary of planned improvements, future enhancements and next steps in the future development of the Energy ADE.

The energy ADE: data model

Data requirement analysis

The design of the Energy ADE Design has been driven by two mains objectives:

• store and manage energy-relevant data collected at urban scale, based for instance on the buildings data specifications of INSPIRE Directive of the European Parliament (2007/2/CE), or concepts defined by the US Building Energy Data Exchange Specification (BEDES),⁷ such as building usage, year of construction, number of dwellings and residents, etc.;

• provide data to assess the energy performance of buildings using a variety of different approaches and software tools, e.g. ranging from standard-based energy balance methods as of ISO 13790, to sub-hourly dynamic simulations by means of specific software programs).

Existing data models, especially those of the energy simulation tools, were analysed and compared in order to find common features and understand the various modelling approaches. As a result, several classes and attributes were identified and organised in thematic modules within the Energy ADE. At the same time, IT and – more specifically – CityGML specialists contributed to integrating and harmonising the new proposed classes with the existing ones in CityGML.

One of the starting points was the need to define the volume bounded by a thermal hull in a building, which represents one of the basic entities required for nearly all energy-simulation purposes. The thermal hull contains one or multiple thermal zones. In addition, each thermal zone needs to be further characterised in terms of usage, occupancy and energy systems. Other requirements were identified when it comes to modelling materials and constructions (and their physical properties), as well as the need to deal with schedules and other time-dependent variables (time-series).

In terms of geometrical representation, CityGML already offers different levels of detail (LoD). Of particular relevance for urban energy modelling are nowadays LoD1 and LoD2 models, despite their of lack precise information about glazed surfaces. On the other hand, LoD3 (let alone LoD4!) models are unlikely to be available for whole cities, at least in the near future, and – if available – their geometrical representation is generally not directly suitable for the most energy simulation tools.

Central problem in many cases is the geometrical representation of the building’s exterior shell, which for a LoD3 model must also take into account architectural details like roof overhangs, reveals, decorative facade elements, or complex lattice windows (see Fig. 2). Thus, the LoD3 volume and boundary surface geometry may contain elements which either are not part of the building’s thermal hull (e.g. roof overhang) or hit generalization assumptions of the used physical building model (e.g. constant thickness of thermal boundary, 1D energy transmission through a thermal boundary).

Fig. 2

Example of a CityGML LoD3 model with roof overhang and reveals

For these reasons, the Energy ADE classes are linked to the existing CityGML ones and can profit from the existing multi-LoD representation of CityGML (if available and if desired). At the same time, however, the modelling of the thermal hull in terms of thermal surfaces and thermal openings can also be decoupled from the CityGML geometries and can be carried out independently with own geometries or – as an extreme example – completely semantically without explicit geometries.

One of the peculiarity of the Energy ADE is its flexibility: as it must cover different (energy) application scenarios, it must deal with heterogeneous data qualities and modelling paradigms. For simplified energy assessments, a building modelled as single-zone with simplified thermal properties (U-values, g-values, etc.) might suffice, but for more complex dynamic simulations, multi-zone models with detailed geometries, layered constructions and complex occupancy schedules are required.

A thorough description of each class are given in Overview of the data model section.

Extending CityGML

CityGML has been intentionally conceived as an application-independent information model, therefore it is not designed for specific use cases. In order to support advanced applications like energy-related simulations, it lacks specific features and properties. However, CityGML already offers schema-inherent concepts to add new features and properties. The former can be represented by the class GenericCityObject, and, for the latter, the property set of any city object (a class derived from the CityGML base class _CityObject) can be extended by so-called generic attributes (derived from abstract class GenericAttribute) or sets thereof. However, this extension mechanism has a severe drawback: the semantic meaning of the extended features or properties is only defined by free text. This makes an interoperable data exchange difficult and prohibits conformance checking with standard tools.

Since CityGML version 0.4.0, the standard supports a second extension mechanism, i.e. the definition of a so-called Application Domain Extension (ADE). Because an ADE is always realised as a separate XML-schema in an own namespace, the interoperability and checking issues are resolved. The ADE mechanism uses two different concepts to extend the CityGML base schemas:

• New feature classes or city objects can be specified by derivation from the general GML class _Feature, the _CityObject base class, or any specific CityGML class;

• Additional application-specific properties of existing CityGML classes can be defined in the ADE namespace. These properties may be of simple or complex type and may include geometries or relations with other CityGML or ADE classes.

While the first extension concept only uses standard XML-schema technology, the second one needs specific extensions of the CityGML classes with abstract properties called ADE-hooks, which are described in the CityGML specification. An ADE schema may be developed manually, or automatically derived from an UML model based on the transformation rules described in van den Brink et al. [36].

The CityGML Energy ADE uses both extension concepts and is realised as a UML diagram.

As a proof of the versatility and flexibility of the ADE mechanism, there are already several other ADEs at the time of writing. They are meant to assess specific domains such as urban noise [22], immovable property taxation [10], indoor routing and positioning [13], indoor facilities management [19, 20], utility networks [6, 7, 23], cultural heritage [25]. An updated list of the currently available ADEs can be retrieved from the CityGML Wikipage.⁸

Overview of the data model

Within the UML-based data model show in Fig. 3, a number of functional modules can be identified. The different UML packages and their mutual dependencies are depicted in different colours. The following modules, subsequently described in detail, can be distinguished:

• The Energy ADE Core module, defining a number of abstract base classes and some generally used data types, enumerations and codelists, and extending the CityGML feature classes _AbstractBuilding and _CityObject with new properties;

• The Building Physics module, supporting parameters for single- or multi-zone building energy simulations;

• The Occupant Behaviour module, enabling to model the behaviour of the building’s occupants;

• The Material and Construction module, providing physical parameters of the building materials;

• The Energy Systems module, enabling to represent the energy conversion, distribution, storage and emission devices of a building and the energy flow between them;

• Various Supporting Classes to represent time series of physical data, schedules and weather data.

Fig. 3

Colour-coded modular structure of the Energy ADE UML diagram. The colour coding for the different classes is used also in the following Figures

All resources of the Energy ADE are freely available through a Wikipage⁹ and a public GitHub repository.¹⁰

Core module

The Energy ADE Core module has three main functions: It extends two classes of the CityGML base standard with energy relevant properties, it provides abstract base classes for the four central functional modules of the Energy ADE (“Occupant Behaviour”, “Material and Construction”, “Energy Systems” and “Building Physics”), and it defines a number of data types, enumerations and codelists which are used in more than one functional module. With this structure, it is possible to avoid mutual dependencies between these modules.

In the CityGML standard the class _AbstractBuilding is used to represent either a complete building (class Building) or a building part (class BuildingPart). The extension of these types in the Energy ADE follows different goals. In order to support rough assessment of a building’s energy demand, a number of general energy-related parameters are defined: a classification of the general building usage (buildingType), a rough classification of the building construction structure (constructionWeight), important geometrical (volume, floorArea) and locational (referencePoint, heightAboveGround) parameters, and average material parameters (see Material and construction module section) of the building exterior shell (aggregatedBuildingConstruction). If a building has energy performance certificates, the corresponding information (energyPerformanceCertification) can also be specified. In Fig. 4 the corresponding UML diagram is presented.

Fig. 4

Extension of the CityGML classes _AbstractBuilding and _CityObject

All properties mentioned so far only support rough energy assessments, which are nevertheless essential for city-wide bottom-up energy related investigations. In order to also support detailed energy simulations at building level which take into account time-variant weather conditions and occupants’ behaviour, a more sophisticated model for the building physics and the building usage are needed. The Energy ADE therefore supports the partition of a building into different thermal zones (class ThermalZone, see Building physics module section) and usage zones (class UsageZone, see Occupant behaviour module section).

Figure 4 also shows that also the CityGML base _CityObject is extended by two relations. The relation demands points to a class EnergyDemand, which allows connecting any city object with parameters specifying its needed amount of energy (energyAmount) to satisfy a specific end use (endUse) like space heating or domestic hot water production. The relation weatherData enables to connect any city object with time series of meteorological or radiation parameters (WeatherData). Furthermore, the Energy ADE core module provides the abstract class AbstractEnergySystem, from which all specific classes for representing energy systems (see Energy systems module section) are derived. Via relation installedIn, an energy system may be connected to any city object.

Building physics module

The Building Physics module provides important input data for detailed simulations of a building thermal behaviour, e.g. for computation of space-heating and space-cooling demands. For this purpose, the new classes ThermalZone, ThermalBoundary, and ThermalOpening are defined, which may be related with the corresponding CityGML classes Room, _BoundarySurface and _Opening. In Fig. 5 the corresponding UML diagram is presented.

Fig. 5

UML diagram of the Building Physics module

A ThermalZone class represents the reference volume for heating and cooling demand calculation. It is generally a “thermally homogeneous” space considered as isothermal, but, for simplified building energy modelling, it may also refer to several building rooms and zones with different usage boundary conditions. A building may be separated into several ThermalZone objects, for instance in the case of mixed-usage building, or to distinguish rooms or zones with different orientations (i.e. solar gains) and/or thermal behaviour.

ThermalZone objects hold a series of energy-related attributes characterising its geometry (floorArea, volume), its conditioning status (isCooled, isHeated, indirectlyHeatedAreaRatio) and overall building-physics properties (additionalThermalBridgeUValue, infiltrationRate, effectiveThermalCapacity). Furthermore, it may optionally contain an explicit volume geometry (volumeGeometry), useful in particular for visualisation purposes. If occupied, a ThermalZone must be related to at least one UsageZone object, which contains the usage boundary conditions for the heating and cooling demand calculation (see Occupant behaviour module section).

The ThermalZone objects are separated from each other and from the environment by ThermalBoundary objects, which are assumed to be planar or quasi-planar surfaces. Each ThermalZone is geometrically closed by its whole set of bounding ThermalBoundary objects (relation boundedBy). On the other hand, a ThermalBoundary object must refer to one (boundary between a ThermalZone object and the building environment) or two corresponding ThermalZone objects via the ordered relation delimits. In the case a ThermalBoundary object separates two adjacent ThermalZone objects, actually corresponding to an intermediate floor, ceiling, interior or shared wall, its geometrical representation coincides with the plane lying at the middle of the construction thickness.

A ThermalBoundary may contain attributes characterising its type (thermalBoundaryType), orientation (azimuth and inclination), size (area), explicit geometry (surfaceGeometry), and material properties for the “opaque” part of the corresponding building element (Construction). If parts of a ThermalBoundary have different material properties, especially allowing the transfer of radiation energy, these parts must be separately modelled as ThermalOpening (relation contains). A ThermalOpening has the same orientation as the underlying ThermalBoundary, has a mandatory relation Construction to an AbstractConstruction object (see Material and construction module section), and can optionally carry information on indoor and outdoor shading devices (indoorShading, outdoorShading) and its maximal openable ratio (openableRatio).

Material and construction module

The Material and Construction module of the Energy ADE physically characterises the building construction parts, detailing their structure and specifying their thermal and optical properties. The central feature type of the module is the Construction class, which may either be used directly or as ReverseConstruction, modelling a baseConstruction with inverted order of layers. In Fig. 6 the corresponding UML diagram is presented.

Fig. 6

UML diagram of the Material and Construction module

Each Construction object may be characterised by optical and/or physical properties. The OpticalProperties type specifies the emissivity (ratio of the long-wave radiation emitted by an object), the reflectance (fraction of incident radiation which is reflected by an object), the transmittance (fraction of incident radiation which passes through a specific object) and the glazingRatio (proportion of the construction surface which is transparent) of the construction and its surfaces. There is no property for radiation absorptance, because according to the Kirchoff and Lambert law, the absorptance and the emittance are equal for a given wavelength range for a diffuse grey body.

The thermal properties of a Construction may be characterised with two possible “levels of detail”: Either with the heat transmission coefficient uValue for steady-state thermal modelling, or by an ordered list of Layer objects detailing different layers of materials and their thermal behaviour. Each Layer is composed of one or more LayerComponent objects representing a homogeneous part of a Layer (composed of a unique material) covering a given fraction (areaFraction) of it. Each LayerComponent is related with exactly one material object, either a Gas (which has negligible thermal capacity) or a SolidMaterial.

Occupant behaviour module

The Occupant Behaviour module contains classes to represent the occupants of a building and their behaviour, as far as it is relevant for an energy simulation. The main underlying idea is to define regions of homogeneous usage (class UsageZone), which are referenced by a ThermalZone. In Fig. 7 the corresponding UML diagram is presented.

Fig. 7

UML model of the Occupant Behaviour module

Optionally, a UsageZone may be subdivided into different BuildingUnit objects holding ownership information. A UsageZone has a mandatory attribute usageZoneType, globally characterising the usage of the corresponding part of the building. Further optional properties are the size of the corresponding floor area (floorArea), a geometrical representation of the zone’s volume (volumeGeometry), and an indication which floors of the zone are really used (usedFloors). In order to specify the desired indoor climate conditions, schedules for nominal temperatures of heating (heatingSchedule), cooling (coolingSchedule) and ventilation (ventilationSchedule) can be specified. Different types of schedules are supported, this is discussed later in detail in Supporting classes: time series, schedules and weather data section.

The internal energy gains due to the heat emission of facilities (lighting, electrical appliances and domestic hot water (DHW) facilities), and the occupants themselves can be modelled in different ways. The easiest method is to sum up all heat energy gains by specifying an average power (avarageInternalGains). Alternatively, the operational schedules of the different facilities (base class Facilities and derived classes DHWFacilities, LightingFacilities and ElectricalAppliances) and the corresponding maximal heat dissipation power can be specified. For a detailed assessment of the internal gains due to the heat produced by people, the class Occupants is foreseen. It represents a homogeneous group of occupants of a UsageZone or BuildingUnit, categorized in one occupancyType (e.g. residents, workers, visitors etc.). Occupants objects are characterized by a given maximal number of persons (numberOfOccupants) which occupy the corresponding zone or building unit and follow a certain time schedule (occupancyRate). For the zone thermal modelling, the maximal heat dissipation (heatDissipation) of this occupant group can also be specified.

Energy systems module

The Energy Systems module represents the energy forms and energy systems to perform energy demand and supply analyses. It allows to calculate the CO₂ emissions or primary energy balances. It is related to the Energy ADE and CityGML model through the class EnergyDemand and the abstract class AbstractEnergySystem. Both can be related to any _CityObject. AbstractEnergySystem is the abstract base class for all specific classes representing energy conversion systems (derived from AbstractEnergyConversionSystem), energy distribution systems (derived from AbstractEnergyDistributionSystem), energy storage systems (derived from AbstractStorageSystem), or an energy emitter (class EmitterSystem). The energy being transmitted and exchanged between these different energy system components is represented by the class EnergyFlow, which holds a mandatory attribute for the energyAmount (arbitrary time series of energy values) and an optional classification energyCarrier for the energy carrier (Fig. 8).

Fig. 8

Simplified UML model of the Energy Systems module

An energy conversion system is defined as system for producing the energy necessary to satisfy the end-use (or to feed the networks) from an energy source. The Energy ADE holds special classes for a number of specific conversion systems (Table 1), which all are derived from AbstractEnergyConversionSystem. Energy distribution systems, which must be specialised as thermal or power distribution systems, are in charge of delivering the energy inside the building, from the place of energy production to the place of end-use. The same distinction between thermal energy and electric power is applied for the classes representing energy storage systems. The last type of energy system is the emitter (class Emitter), defined as end unit which emits useful energy (e.g. heat, cool) in the zone where it is required.

Table 1 Special classes for the energy conversion systems

Supporting classes: time series, schedules and weather data

The thematic modules previously described use a number of supporting classes to represent series of time dependent values (AbstractTimeSeries and derived classes, Fig. 9), schedules (AbstractSchedule and derived classes, Fig. 10) and weather or climate data (Fig. 11).

Fig. 9

UML diagram of the time series classes

Fig. 10

UML diagram for schedules

Fig. 11

UML diagram for weather data

The data model distinguishes between regular and irregular time series. In regular time series, the values have a defined start and end time (temporalExtent) and a constant time increment (timeInterval). The time series values itself may either be stored directly in the XML-document (class RegularTimeSeries) or in a separate file with table structure (class RegularTimeSeriesFile). In irregular time series, each value has an individual time stamp. Again, the time series values and the corresponding time instances may be stored in the XML-document (IrregularTimeSeries referring to MeasurementPoint objects) or on an external file-based table (IrregularTimeSeriesFile). All specific time series types have a common set of metadata (TimeValuesProperties), specifying e.g. the used acquisition method (acquisitionMethod), interpolation type (interpolationType) or a thematic description of the values (thematicDescription).

Figure 10 depicts the four different types of schedules currently supported by the Energy ADE. The simplest type is the ConstantValueSchedule, specifying only one value (attribute avarageValue) for the complete time interval regarded, which for building energy related applications normally is a specific or typical year. The DualValueSchedule defines two different values, one for operating times (usageValue) and one for idle times (idleValue). Optionally, the number of usage days per year and usage hours per day may be specified in addition. The most frequently used schedule type in practical applications is the DailyPatternSchedule. It enables to specify different time periods within a year (periodOfYear), where each period is related with schedules for specific days of the week (DailySchedule). A specific DailySchedule object is characterised by its dayType (e.g. week day, weekend, or a specific day of the week) and a time series of values (schedule) valid for this day. The fourth and most general schedule type is the TimeSeriesSchedule, where any (regular or irregular) time series may be used.

For advanced energy related simulations of building or urban level, time dependent weather or climate data are also very important. In order to combine the energetic model of a building with the meteorological data, the classes WeatherData and WeatherStation are foreseen. Every city object may be related to an arbitrary number of WeatherData objects, each of them holding a time series of values for a specific physical parameter, characterised by the attribute weatherDataType. The class WeatherStation allows to aggregate different WeatherData objects in order to use them for an energy related simulation.

Connection of the energy ADE with the utility network ADE

As already mentioned, the Energy ADE is not the only Application Domain Extension being actively developed at the time of writing. Of particular relevance for the Energy ADE is however the Utility Network ADE, which complements its scope and scale. If the Energy ADE focuses primarily on buildings, the Utility Network ADE takes care of what happens outside the building boundaries, i.e. it focuses on the utility network infrastructure (electricity, gas, wastewater, etc.).

The Utility Network ADE defines a topological network model facilitating sophisticated analyses and simulations on utility networks and supplying infrastructures. Included are, amongst others, network hierarchies of arbitrary depth, nesting of network components, and modelling of multi-modal networks. Furthermore, it allows for the representation of the network components as 3D topographic city objects.

The development started originally at Technical University of Berlin in 2011 [6, 7], and has continued since then, with the latest development work carried on at the Technical University of Munich recently [23].

Despite the existence of several other data models and standards for utility networks (e.g. the INSPIRE Utility Networks model, the ISO standard Industry Foundation Classes (IFC) and the ESRI Geometric Network model) the Utility Network ADE aims, on the one hand, at providing a common basis for the integration of diverse models in order to facilitate joint analyses and visualisation tasks, but, on the other hand, also intends to overcome shortcomings of existing network models with respect to the following characteristics:

• For the representation of heterogeneous networks (i.e. not only for specific types of networks), the data model should allow for a dual representation of network topography as well as topology and for a representation of topographic/graphic aspects (including 3D) as well as of functional aspects;

• The data model should allow for a hierarchical modelling of networks and subnetworks as well as of components and subcomponents and for modelling interdependencies between network features and city objects as well as between network features of different types of networks (Fig. 12).

Fig. 12

Decomposition and hierarchical structuring of networks in the context of power supply. Image source: Kutzner and Kolbe [23]

Given the general interest for the level of development and the results achieved so far, the development of the Energy ADE and of the Utility Network ADE are converging, in order to slowly but progressively optimise and harmonise the respective data models.

The energy ADE: database implementation

The Energy ADE extends the CityGML data model to add several energy-related entities and attributes which are particularly required in order to develop applications dealing with Urban Energy Planning. With the Energy ADE reaching a good level of maturity and stability, there has been a growing interest and need in having a suitable spatial Relational Database Management System (RDBMS) implementation of the Energy ADE, ideally extending the already available free and open-source CityGML 3D City Database (3DCityDB)¹¹ which represents the reference implementation as database schema of the CityGML data model.

As a matter of fact, the current version of the 3DCityDB (and the set of accompanying software tools like the Import/Export tool) do not provide a generic solution for handling CityGML ADE elements in CityGML instance documents. Research work is indeed being carried out at the Technical University of Munich and by the 3DCityDB development team to extend to 3DCityDB and the accompanying software tools to deal with any ADE and to automatically perform the mapping between the object-oriented model and the relational-database model, in order to derive database schemas “on the fly”. Further details can be read in Yao and Kolbe [38].

While waiting for this planned and powerful upgrade of the 3DCityDB toolchain to be fully developed, tested, optimised, implemented and finally released to the public, a manually derived database schema was implemented and is now freely available. The current implementation is based on the Energy ADE v. 0.8 but it already incorporates nearly all additions and changes up to the current version 1.0. Initial work started internally at the Austrian Institute of Technology (AIT) during version 0.6 of the Energy ADE [2]. As reported by some of the Energy ADE developers, similar and parallel (sometimes partial) implementations had already been carried out in the past by different groups, generally tailored to specific project needs. However, a common, shared, publicly available and well-documented implementation had not been made available so far.

System and design decisions

Currently, the 3D City Database schema is provided for Oracle with the Spatial or Locator licensing option (10G R2 or higher) and PostgreSQL (9.1 or higher) with PostGIS extension (2.0 or higher). The 3DCityDB extension for the Energy ADE requires the latest version of the 3DCityDB (v. 3.3.0) and is currently implemented for PostgreSQL only. As the overall goal of this extension is to facilitate direct connection and usage of the 3DCityDB relational database by users and applications programmers, a number of design and implementation decisions were taken according to the inspiring criteria briefly listed in the following:

• a) Define a non-concurrent way of extending the 3DCityDB with other ADEs (e.g. the Utility Networks ADE) at the same time, for example adopting naming prefixes to avoid potential homonymy conflicts with other ADEs or standard 3DCityDB objects;

• b) Build upon the existing objects of the 3DCityDB (relations, stored procedures, etc.), but keep the original ones untouched in order to guarantee the normal usage of the Importer/Exporter tool with “plain” CityGML instance documents;

• c) Try to stay as close as possible to the original design “style” of the 3DCityDB when it comes to tables, constraints, naming conventions, data types, etc.;

• d) Follow the Energy ADE as close as possible. This means also that tables and attribute names in the database are kept as close as possible to the original names of the Energy ADE as indicated in the UML diagrams;

• e) Keep the number of tables in check, i.e. grouping and merging multiple classes into one table – whenever reasonable –, although at the cost of some inefficiencies (e.g. in terms of disk space consumption);

All resources of the database implementation of the Energy ADE (DDL procedures, documentation, test data, etc.) are already freely available and can be downloaded from GitHub.¹²

ADE support in the 3DCityDB

Before proceeding with the Energy ADE itself, a number of changes and additions to the current original 3DCityDB implementation were required in order to add support to Application Domain Extensions.

As already mentioned, the 3DCityDB should allow for support of different ADEs at the same time. Moreover, it should be possible to store metadata information about any ADE (e.g. name, version, xml schema location, etc.), avoid potential homonymy conflicts among tables belonging to different ADEs or standard 3DCityDB objects, and to provide a flexible way of defining/extending stored procedures to facilitate the overall database management.

For these reasons, a set of rules were first defined and then implemented, in order to prepare the 3DCityDB to be extended by an Application Domain Extension. Their implementation can be roughly summarised in three main points, which will be briefly described in the following.

• a) Add a Metadata module to “register” ADEs;

• b) Define rules to map ADE classes to new or existing tables;

• c) Define rules to deal with database stored procedures.

Please note that all rules were agreed upon within the 3DCityDB development team and are being gradually tested and implemented for the next official 3DCityDB release. A schematic representation of the structure of the extended 3DCityDB is given in Fig. 13.

Fig. 13

Schematic representation of the extended 3DCityDB: the ADE extension mechanism layer allows for the further implementation of any ADE on top of the existing database schema for CityGML

The Metadata module is meant to allow for “registration” of an ADE upon installation, in that all relevant information and metadata are stored in the 3DCityDB. It obeys to the rule that every ADE must be self-consistent, i.e. references to CityGML schemas are allowed, but not to other ADEs. As long as this constraint is respected, an ADE itself can be composed of several schemas.

In order to avoid homonymy conflicts among tables belonging to different ADEs or standard CityGML, every ADE must be assigned a unique prefix, which is used consistently in the 3DCityDB to identify uniquely all entities (tables, stored procedures, triggers, etc.) derived from that ADE. For example, in the case of the Energy ADE v. 0.8, the prefix “nrg8_” is used.

In addition, the Metadata module adds some new tables that are used to store all necessary metadata about each ADE.

Regarding the mapping rules for the ADE classes, one or more classes of the UML diagrams are mapped onto one table. The name of the table is identical to the class name in most of the cases (the “abstract” name prefix is left out), with the addition of the above-mentioned prefix (e.g. “nrg8_”). The name of the attributes in the tables are kept as close as possible to those of the respective classes. The scalar attributes of the classes become columns of the corresponding table with identical (or very similar) names. For every attribute including measure information an additional _UNIT-suffixed column is provided to specify the unit of measurement.

In general, the overall logic of the current database implementation of Energy ADE is to follow and reflect as much as possible the original one of the 3DCityDB. Furthermore, as a general rule, no changes to original 3DCityDB tables are allowed, in order to secure that the Importer/Exporter will continue working as usual, though no ADE data will be “seen”.

Keeping in mind these design criteria, a number of rules to map ADE classes to tables were identified and implemented. A detailed explanation is out of the scope of this articles, however further information can be found in the documentation of the Energy ADE extension for the 3DCityDB.

An example of mapping is presented in Fig. 14. For intuitive understanding, classes that are merged to a single table in the relational schema are shown as light orange blocks in the UML diagram.

Fig. 14

Example of mapping of the classes for time series to database tables: classes are merged into the two tables nrg8_time_series and nrg8_time_series_file, as shown by means of the light orange background boxes

Finally, besides creating new tables, whenever an ADE is implemented as database schema, a number of stored procedures must be also provided to help data management, given the complexity of the underlying schema. In the original 3DCityDB, stored procedures (or functions, in the PostgreSQL jargon) can be grouped approximately in the “delete”, “get_envelope” and “miscellaneous” families. In particular, the “delete” stored procedures provide a convenient way of deleting objects having data spread over different tables.

For the Energy ADE stored procedures, a similar approach applies: a number of functions for each of the three families (“delete”, “get_envelope” and “miscellaneous”) are implemented, too.

Despite the adopted design criteria to keep the database implementation of the Energy ADE as simple as possible, the database structure can be sometimes complex in terms of CRUD operations (i.e. select, insert, update and delete), especially when dealing with the tables added by the ADE. Data belonging to a specific class can be split and stored in different tables in the database. For this reason, and to facilitate CRUD operations at database level, some updatable views are also provided. Views represent a facilitated way to access data, ideally providing one single table that “hides” the complex structure of the actual database. Moreover, if a view is also updatable, entries can be updated, inserted and deleted directly interacting with the view as if it were a normal table.

The availability of the Energy ADE as database schema allows to interact with data either by writing, for example, routines/functions/code in any programming language, or by means of existing Extract Transform and Load (ETL) tools like the Feature Manipulation Engine¹³ by Safe Software or Hale Studio¹⁴ by WeTransform.

The energy ADE: examples of software applications

Due to the novelty status of the Energy ADE and its highly dynamic development process, the availability of authoring tools to directly generate Energy-ADE-conformant data is still lacking on the market. For the same reasons, existing building energy simulation tools do not natively support the Energy ADE as input/output data format, yet.

Dealing with the concrete implementation of the data model for existing software packages is out of the scope of this article. Nevertheless, some of the partners in the development consortium have been establishing and testing prototypical workflows to test and demonstrate the relevance of the Energy ADE in supporting data interoperability among the heterogeneous software tools generally involved in urban energy simulations. This applies for example to CAD and GIS tools for data generation and collection, database systems for storage, visualisation tools, thermal simulation packages, etc.

Therefore, the following section will present two of these prototypical workflows as examples: the first developed at the Karlsruhe Institute of Technology (KIT), and the second at the University of Applied Sciences, Stuttgart (HFT). In addition, three case studies (in Germany, Austria and Italy) with direct relations to the Energy ADE will be shortly presented afterwards. Here it will be shown how the Energy ADE was adopted and implemented – though at different levels of completeness.

Working with energy ADE data

Workflow developed at KIT

Besides a geometrical representation of a building’s exterior shell, a CityGML model contains only little information for supporting thermal simulations. Available are, if any, the building’s year of construction, a classification of the building’s function and eventually the number of storeys above ground. Many software systems are principally able to simulate for example the building’s annual heat demand based on these few data. However, in these cases the simulations are based on a lot of specific assumptions and derivations internally performed by the software. As a consequence, the simulation results are normally not immediately comprehensible, and different software systems produce strongly differing results for the same set of input parameters.

The Karlsruhe Institute of Technology has therefore established a workflow (Fig. 15), in which a CityGML LoD2 or LoD3 building model first is enhanced by means of energy-relevant information and then stored as Energy-ADE-compliant dataset. A second software system, called IFCExplorer [8], reads this dataset, transforms it into the input data model of a specific building energy simulation software, starts the simulation, and finally integrates the simulation results (in form yearly aggregated values and time series of different temperatures and energy demands) back into the Energy-ADE-compliant dataset.

Fig. 15

Energy ADE supported workflow from CityGML to energy simulation

The first part of this workflow is realised in the software GML-Toolbox¹⁵ by a number of interactively controlled steps. In each of these steps, the software determines plausible values for the relevant parameters, based on the available information like, for example, the building’s year of construction, the function and the construction weight. The user may accept all automatically proposed values, or change selected parameters. In this way, the whole data enrichment process is accelerated and carried out automatically or semi-automatically.

In the first step of the workflow, the CityGML LoD2 or LoD3 model is checked for geometrical and semantical correctness. Necessary conditions for deriving an energy simulation model from a CityGML building model are the existence of a geometrically correct building volume, and a set of geometrically correct exterior boundary surfaces, which can be transformed into ThermalBoundary objects (see chapter 2.3). For the latter, the different boundary surfaces must be geometrically correct and non-overlapping, and need a (within certain limits) unique surface orientation. Furthermore, the union of all boundary surfaces must be identical with the exterior of the building’s volume. At the moment, only CityGML Building objects without references to BuildingPart objects are processed, because shared walls between different BuildingParts are not represented in CityGML.

During the checking process, a number of geometry properties (e.g. building gross volume, size and orientation of boundary surfaces) are calculated on base of the geometrical representations. Next, these parameters and the available attributive information on building level are presented to the user for manual correction and completion. In the following step, building physics parameters, like heat capacities, heat resistances and optical properties, are assigned to the building’s boundary surfaces and openings. In case of a LoD2 model containing no information on doors and windows, the user can assign an “opening ratio” to each boundary surface.

After this step, it is possible to generate an Energy-ADE-compliant model with one ThermalZone object for the complete building volume and one ThermalBoundary object for each CityGML _BoundarySurface. For LoD3 models, every Door or Window related with the _BoundarsSurface object is directly transformed into a ThermalOpening object. For LoD2 models, using the assigned opening ratio of the boundary surface, an artificial ThermalOpening (without explicit geometry) is generated and related to the ThermalBoundary.

Additionally, if required, daily profiles for the nominal cooling and heating temperatures, ventilation rates, and the heat gains due to lighting, electrical devices and the presence of occupants can be specified, which are integrated as one UsageZone object into the Energy-ADE-compliant model.

Finally, specific weather data time series may be chosen, which are integrated as WeatherStation object into the output data set. As input data format for externally available weather data, CSV files as well as the XML format of the software ETU-Gebäudesimulation (in short: GebSim) from the company ETU Hottgenroth¹⁶ are supported. In any case, the enhanced CityGML model is exported as Energy ADE dataset. As a consequence, it can be stored in a suited database (e.g. the 3DCityDB, see The energy ADE: database implementation section) or processed by any Energy-ADE-compliant simulation tool. In the workflow established at KIT, the commercially available building energy simulation system ETU-Gebäudesimulation is used. The interface to this simulation system is established by means of the software IFCExplorer, supporting import, visualisation and processing of geospatial data in different formats like IFC, gbXML, CityGML or arbitrary CityGML ADEs (Fig. 16).

Fig. 16

Integration and visualisation of different geospatial data formats in the IFCExplorer

Based on pure CityGML or Energy ADE models, the IFCExplorer can generate a GebSim database, start the simulation process, extract the simulation results from the database for visualisation purposes (Fig. 17) and integrate the simulation results into an Energy-ADE-compliant database.

Fig. 17

CityGML model of Rotterdam: Visualisation of the simulated annual heating energy demand per square meter of floor area

Workflow developed at HFT Stuttgart

Having as goal the exploitation of the potential offered by standard-based 3D city models, the departments Energy and Geoinformatics of the University of Applied Sciences (HFT), Stuttgart, joined forces to develop a new and extendible platform for urban energy and environmental analyses, called SimStadt [28].¹⁷

SimStadt adopts CityGML and, partially, the Energy ADE as internal shared data model among the different component modules. It takes advantage directly of the peculiarities of CityGML in its software design, in that the flexibility offered by CityGML in terms of 4 distinct Levels of Detail (LoD) allows the virtual city model to adapt to local building parameter availability and quality, and application requirements. As a consequence, SimStadt profits of the multi-LoD concept in its simulation models: the present version is compatible with LoD1 and LoD2, and soon with LoD3. Upon import, the 3D city models are validated and checked for geometrical and topological errors. When it comes to the characteristics of the different objects (buildings, thermal boundaries, etc.) they are either imported directly from pro-processing modules and benchmarking building libraries. In Fig. 18 a general schema of the different components of SimStadt is presented. These allows for the following atomic functionalities:

• CityGML city model validation and import;

• 3D city model data pre-processing and quality check (for geometry, building physics, usage, energy systems);

• Import and processing of weather data, based on different data sources and formats (e.g. tmy3 or PVGIS);

• Radiation Processor, using different radiation and sky models (Hay model, Simplified Radiosity Algorithm);

• Modules for solar potential and photovoltaics analysis;

• Heating demand prediction based on the monthly energy balance method from standard DIN V 15899–2;

• Generation of building refurbishment scenarios for buildings based on refurbishment rate and priorities;

• Interactive data visualisation, exploration and reporting, as well as export of analysis results.

• Extendibility by means of plug-ins to other simulation tools, e.g. for district heating (Stanet, see later) or other third-party software for dynamic simulation of energy systems (e.g. Insel¹⁸);

Fig. 18

Schematic representation of the data and process workflow developed at the University of Applied Sciences of Stuttgart (HFT)

When it comes to the last point regarding extendibility, and thanks to its modular structures, SimStadt can be also extended with further modules and more complex workflows corresponding to new urban energy analyses, provided that the required data are available either in the input 3D city model or can be retrieved and integrated from other external web services.

The SimStadt platform currently permits the following analysis: solar potential and photovoltaics analysis, building heating demand prediction, simulation of long-term refurbishment scenarios, assessment of CO₂ emissions, and automatic layout and sizing of district heating network (new or extension). It is programmed in Java and uses the free and open-source citygml4j library¹⁹ to load, process and store CityGML files. A Graphical User Interface (GUI) (Fig. 19) enables to navigate through the different workflows and workflow steps, allowing for the analysis of the intermediary results at each step through charts, tables and other output like 3D visualisations (Fig. 20). The GUI also enables the user to modify the hypotheses and parameters of workflow steps and create scenarios accordingly.

Fig. 19

Example of the SimStadt Graphical User Interface, representing a heat density map

Fig. 20

3D visualisation of a virtual 3D city model representing the building specific heating demand calculated with SimStadt

The building heating demand calculation of SimStadt consists in a monthly energy balance method standardised in the DIN 18599 (German equivalent of ISO 13790), based on the geometry of the CityGML 3D city models and the energy-related data of the Energy ADE. To verify its reliability, simulated results were compared with measured energy consumptions at building level in three case studies in Germany and Netherland (Ludwigsburg, Karlsruhe, Rotterdam) [29]. Although closely related also to the data quality of the input 3D city model, it was found that for buildings whose minimum required information was available (year of construction/refurbishment and buildings usage), the deviation between simulated and measured heating demand varies between 5% and 30% [30].

Case studies

The districts of Sonnenberg and Grünbühl in Ludwigsburg, Germany

In the framework of the project EnEff:Stadt Ludwigsburg,²⁰ an integrated energy concept has been realised for the post-war district Grünbühl and its new neighbour district Sonnenberg in the South-West of Ludwigsburg, Germany.

This integrated energy concept combines the refurbishment of the post-war buildings with the construction of new low-energy buildings, as well as an innovative micro district heating system (DHS). Early in the planning process, the following questions came in the focus: “Why connecting low-heating-demand buildings to a district heating?” or “Is it worth to extend the district heating network in the refurbished post-war district, and how to integrate decentralised renewable energies?”.

The district Grünbühl is a typical German post-war district with multi-family houses mainly built in the 50s and 60s of the XX century, which require nowadays an urgent overall refurbishment. Grünbühl has 2350 inhabitants for a ground area of 23.6 ha. Half of its 250 buildings are of residential type, the rest are office, administration or mixed-use buildings. A connection of Grünbühl to the local district heating system is already decided.

A CityGML-based city model in LoD2 was provided to the project team by the GIS department of Ludwigsburg. The year of construction and usage of each building is available, whereas building types and subsequent refurbishment information data are missing for some buildings. Based on the horizontal solar irradiations from the online database PVGIS, solar irradiations incoming on each facade and roof surface were computed using the Simplified Radiosity Algorithm [33]. This allows to precisely assess the solar potential for photovoltaics and solar collector, as well as the passive solar gains, since this algorithm considers the occlusions and reflections caused by the surrounding buildings.

Using SimStadt, the heating energy demand for all residential buildings in Grünbühl were computed. The results were then evaluated, using the gas consumptions provided per building block by the local energy supply company. The deviations vary between 2% and 31% for the different buildings, closely related with the data availability and quality. Further details on the whole method and assumptions are available in Nouvel et al. [30] (Fig. 21).

Fig. 21

Comparison of simulated and measured specific heating demand of the district of Grünbühl

Each building, associated with its calculated heating demand and peak load, represents a consumer node of the DHS extension. The next step consisted in the automatic import of the street layout from OpenStreetMap. By assigning some cost functions to the different zones (main streets, paths, private land), and using the R* Graph algorithm, SimStadt generated also a cost optimal DHS layout connecting all the nodes. If the location of the heating plant was unknown, this was positioned in the barycentre of all consumer nodes. An example is shown in Fig. 22, the heating plant is represented by the red dot.

Fig. 22

Buildings and district heating system layout in Grünbühl generated by SimStadt. The red dot represents the heating plant, it is placed in the barycentre of the study area as a proxy position

The calculated geometric and load data were formatted and transferred to the network simulation software Stanet,²¹ thanks to a plug-in integrated in the SimStadt platform. Stanet sizes the diameter of all pipes and calculates the water flows, the temperature and pressure drops, and the heat losses of the pipes. The following DHS characteristics were considered for this study: a temperature level of 90/55 °C, a pipe roughness thickness of 0.07 mm, a static pressure in the return pipes of 2 bar and a pump pressure head of 4 bar.

The district of Meidling in Vienna, Austria

Within the European project CI-NERGY,²² which aims, among the rest, at developing urban decision making and operational optimisation software tools to minimise non-renewable energy use in cities, the municipalities of Vienna in Austria and Geneva in Switzerland were chosen as case studies for their very ambitious sustainability goals. Although this section focuses on the Vienna case study, further CI-NERGY-related information about the other case study city Geneva can be found in Agugiaro et al. [3].

In Vienna, one of the goals defined by the Smart City Wien Framework Programme is to decrease the final energy consumption per capita by 40% by 2050 (compared to 2005) and, at the same time, the per-capita primary energy input should drop from 3000 to 2000 W, i.e. to 48 kWh per day, as envisioned by the so-called 2000-W society.

Starting from 2015, a large number of datasets (both spatial and non-spatial) were collected for the whole city of Vienna. Many of them were harmonised and integrated in order to generate the CityGML-based semantic 3D city model of the district of Meidling [1]. In addition, the 3D city model was extended by means of the Energy ADE [2]. The district of Meidling was chosen because it offers a good compromise in terms of available data, heterogeneity in terms of buildings, and size (both geographical extension and number of buildings). The district of Meidling spans an area of approximately 8.2 km², it counts circa 90,000 inhabitants (i.e. circa 11,000 inhabitants/km2) and is a densely populated urban area with numerous residential buildings of different sizes and typologies, but also with large recreational areas and parks. It can be approximately divided into two main parts: the north-eastern one is characterised by a heavily developed urban residential texture, while the south-western one is a more mixed (industrial and light residential) area, which then gradually continues southwards. In Meidling there are circa 7400 buildings, of which approximately 5600 are residential or mixed-residential ones.

Starting from the 3D city model, a methodology to compute the energy performance of residential buildings, conceptually similar to the one previously described in the case of Ludwigsburg, was developed, however taking as reference for the calculation method the Austrian norm ÖNORM B 8110–6. All residential buildings were characterised by physical parameters extracted either from the 3D city model or, when necessary, from existing parameter libraries such as the Guideline 6 on energy performance behaviour of buildings by the Austrian Institute of Construction Engineering.²³

Once the energy performance for the current situation was carried out, the most energy-inefficient buildings could be spatially identified, and different refurbishment scenarios were computed depending on the data available about the specific building and the energy resources (e.g. photovoltaic, geothermal, etc.) (Fig. 23). Moreover, results at building level were aggregated at building block level, in order to offer a generalised view of the overall energy performance of a block (Fig. 24).

Fig. 23

“Twin view” visualisation modus for energy performance scenarios: the current energy performance class of each building [left] can be compared with the corresponding one after a refurbishment has been carried out [right]

Fig. 24

Example of hybrid (multi-scale) representation of the energy performance class of buildings and building blocks. The user can select among different scenarios in the upper-left drop-down menu and query buildings and blocks for thematic data

The adoption of a 3D visualisation interface, as well as the possibility to query data and results at building level directly in the web-based 3D environment greatly improved the effectiveness in exploring, communicating, and (optionally) publishing the results. More details can be found in Skarbal et al. [34].

The city of Reggio Emilia, Italy

In the framework of the European project GeoSmartCity,²⁴ aiming at providing an open source platform to facilitate the collection, integration, harmonisation and delivery of urban geodata to monitor both the performance and the real consumption of energy at urban level, the Municipality of Reggio Emilia, Italy, participated as a case study city together with Oeiras in Portugal and Marousi in Greece.

In the case of Reggio Emilia, the municipality was mainly interested in collecting data from heterogeneous authoritative sources, integrating them into a spatial RDBMS modelled according to INSPIRE (buildings) coupled with, for the energy part, the CityGML Energy ADE, in order to create a coherent information hub regarding energy classification and energy consumption of buildings. Finally, a selection of datasets were to be published as open data.

More specifically, data were collected for Reggio Emilia from different sources at local, regional and national levels, from both public and private organisations: 2D building footprints from the municipal topographical maps as well as from cadastral maps, data about the building use, volume and number of units from the national urban cadastre, energy consumption data from the National Tax Agency and from IREN (the local energy provider), energy performance certificates from the regional register (Sistema Accreditamento Certificazione Energetica), availability and characteristics of installed solar panels from the national agency (Gestore Servizi Energetici).

Unlike the projects described before, in the case of Reggio Emilia the main goal was not to generate and enrich a CityGML-based 3D city model to be further used for simulation purposes. Instead, the focus was rather on semantics: both the INSPIRE Implementing Rules on interoperability of spatial data sets and services²⁵ and the Data Specification on Buildings (Technical Guidelines) were taken as fundamental blocks upon which to develop an extension of the data model to seamlessly integrate most of the concepts from the CityGML Energy ADE.

The resulting hybrid INSPIRE and Energy ADE data model for buildings was later implemented as database schemas for both Oracle and PostgreSQL/PostGIS platforms, and is publicly available on GitHub.²⁶

All collected data were integrated, harmonised and stored into the hybrid Energy-ADE-compliant spatial RDBMS, allowing to manage consistently all relevant properties of each building (e.g. energy certificates, energy consumption, etc.), in particular thanks to the implementation – among the rest – of the ThermalZone concept.

As a direct consequence, otherwise previously scattered data could be finally explored, analysed and compared in a more efficient way, providing for example the municipal functionaries with selected “views” regarding specific aspects, such as the annual thermal or electrical consumption normalised by the volume and grouped by building use.

In order to facilitate data access and exploration, a web-based intranet application called “Energy Geoviewer” was developed. Two examples are shown in Figs. 25 and 26.

Fig. 25

Screenshot of the Reggio Emilia intranet application “Energy Geoviewer” (CO₂ emission simulation, based on actual energy consumption data – values from 2014)

Fig. 26

Screenshot of Reggio Emilia intranet application “Energy Geoviewer” (CO₂ emission estimation, based on actual energy consumption data – values from 2014)

As previously mentioned, a selection of 14 harmonised datasets were finally published through the GeoSmartCity Data Catalog²⁷ as well as from the Reggio Emilia municipal open data portal, with data anonymized at building level (e.g. with values of energy consumption normalised by building volume).

Conclusions

Sustainable development of cities is necessary to face challenges such as climate change, air pollution and poverty. With energy being at the heart of many of these issues, urban planning needs to go hand-in-hand with energy planning. Urban energy modelling, coupled with simulation and optimisation methods and integrated tools appear to be a key component in finding promising solutions. Overcoming interoperability issues to promote and facilitate data and software integration plays therefore a crucial role towards advanced, geospatially-enabled smart applications. Standardisation is one of the keys to achieve such integration, and this article focuses on the process of standard-based data modelling in the field of energy.

After giving a brief overview of the existing standards, their main characteristics and respective shortcomings, this paper has presented the Energy Application Domain Extension (ADE) for the CityGML standard. The goal of the Energy ADE is to provide a unique and standard-based data model to overcome, on one side, data interoperability issues among heterogeneous energy-related applications, and, on the other side, to allow for both detailed single-building energy simulations and city-wide bottom-up energy assessments, with particular focus on buildings.

From the data modelling point of view, the adoption of the CityGML standard for urban data modelling grants an open, powerful, flexible and extendable solution which allows to provide harmonised and homogeneous data to the simulation tools, regardless of the original data formats and origin. What is more, the extendibility of CityGML by means of Application Domain Extensions (e.g. Energy and Utility Network ADE) greatly improves the modelling capabilities of CityGML for – but not limited to – energy-related tools and applications.

As examples of current usage of the Energy ADE in terms of software applications, two workflows have been presented where the Energy ADE plays a major role in facilitating information exchange among heterogeneous tools needed for energy-related applications at urban level. In addition, three case studies (three cities in three different countries) have been described, in order to show that the Energy ADE is already being used internationally, despite its novelty status, its dynamic development process and – as an understandable consequence – its lack of out-of-the-box natively compatible tools (so far).

Nevertheless, the increasing attention paid at international level to the Energy ADE is a proof that it is indeed filling a gap and responding to specific needs when it comes to urban energy modelling. What can already be observed is that the number of case studies and software solutions adopting CityGML and the Energy ADE is slowly but steadily growing, and this is a further proof of how such a standardisation process is needed and beneficial to the development of newer, smarter solutions.

Outlook

Having reached version 1.0, the Energy ADE data model will be kept stable for at certain period of time (at least 1 year), in order to allow the partners in the consortium as well as external companies to adapt their existing tools. The main efforts of the Energy ADE consortium will shift from sustained development to dissemination, implementation and further testing. The idea is to focus on demonstrating and proving the benefits of using this new data model for building and urban simulations. Therefore, it is planned to define one or a small number of Energy ADE benchmark models. Each of these models describes a real energy simulation scenario on building or urban level solely with Energy ADE conformant data. The benchmark problems can be processed with different simulation tools, and the results can be compared. In addition, the current version of the Energy ADE is planned to be published as official OGC Best Practice document in the following months.

Although version 1.0 will be kept stable for a certain time, in the medium term the data model will need maintenance and adaptation. One of the reasons for this is that other extensions of the CityGML standard are being developed, which partly have a functional overlap with the Energy ADE. Among these are the already mentioned Utility Network ADE (see Connection of the energy ADE with the utility network ADE section) or the Dynamizer ADE [11].²⁸ Even though the central topic of the latter is the modelling of dynamic features, it also contains concepts for representing time series, which might replace the equivalent ones of the Energy ADE in future versions.

The current version of the Energy ADE is compatible only with CityGML 2.0, i.e. the current version of CityGML. However, CityGML is being further developed, too. Work for the next version 3.0 release has started as far as 2012 and is being carried out by the CityGML Standards Working Group of the OGC. CityGML 3.0 is expected to include several changes which are very likely to make the current Energy ADE incompatible. Proposal for some of these changes have been already published (e.g. [12, 26, 27]) and will probably change the LoD concept, add a sub-partitioning concept for building volumes, include support for time series, as well as for materials and constructions. However, at the moment, the precise release date of CityGML 3.0 is not known, and details about the current state of development are not available for the general public, yet. Therefore, it can be assumed that, when CityGML 3.0 is released, the Energy ADE will have to be adapted. On the other hand, experiences from the past show that, even if a new version of the standard exists, it may take significant time before the latest version achieves wide adoption. Hence, CityGML 2.0 and the Energy ADE 1.0 will have sufficient time to be used and, the latter, further refined and improved.

The future of CityGML notwithstanding, constructive feedback for further improvements is expected from a number of on-going projects which are adopting the Energy ADE (and, sometimes, other ADEs) and which will deliver results and share experiences in the near future. The currently on-going project IntegrCiTy,²⁹ for example, is using both the Energy ADE and the Utility Network ADE. The project focuses on energy supply networks in cities (natural gas, electricity and heating/cooling), as they are almost always planned and operated separately from each other, in a sort of “silo-like” approach. This approach prevents energy utilities and city planners from identifying synergic opportunities among the networks, for example to increase reliability and robustness of the energy supply, and to optimally plan heavy infrastructure investments, thus taking into account future energy demand evolutions while avoiding oversizing. The overall aim of project IntegrCiTy is to foster energy networks interoperability either in existing or future urban infrastructures, thus overcoming the afore mentioned “silo-like” approach and by developing a dedicated decision-support tool that will be applied and tested/validated in three Swiss and Swedish cities (Geneva, Vevey and Stockholm).