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.
The first part of this workflow is realised in the software GML-ToolboxFootnote 15 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 HottgenrothFootnote 16 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).
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.
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].Footnote 17
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. InselFootnote 18);
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 CO2 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 libraryFootnote 19 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.
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,Footnote 20 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).
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.
The calculated geometric and load data were formatted and transferred to the network simulation software Stanet,Footnote 21 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,Footnote 22 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 km2, 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.Footnote 23
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).
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,Footnote 24 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 servicesFootnote 25 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.Footnote 26
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.
As previously mentioned, a selection of 14 harmonised datasets were finally published through the GeoSmartCity Data CatalogFootnote 27 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).