16. Storing and Visualising Dynamic Data in the Context of Energy Analysis in the Smart Cities

As cities continue the implementation of smart city concepts around the world, a smart city has been defined as a way of continuously optimising traditional services and networks by taking advantage of developments in Information and Communications Technology (ICT) to become more efficient to benefit its inhabitants (European Commission 2020). Smart cities are often associated with the intelligent network of connected objects and machines that continuously transmit data using sensors technology and the cloud (Jawhar et al. 2018). At the same time, the virtual 3D city model has been used predominantly in the past for visualisation (Biljecki et al. 2015). There is a need to visualise and analyse city data alongside the 3D virtual city model since the 3D city model could also contain essential datasets related to individual buildings that can altogether be used in helping municipalities, enterprises, and citizens make better decisions that improve the quality of life in their cities.

While different standards are used to model and manage 3D city models, having a common standard eases the exchange of this data between various partners, thereby making these data reusable. To have a standard definition of the basic entities, attributes, and relationships of a 3D city model, the Open Geospatial Consortium (OGC) CityGML was developed to enable not just the visualisation of the virtual 3D city model but also the management and sharing of these models (Gröger et al. 2012). As one of the popular standards, CityGML has been widely accepted and used for modelling and sharing the 3D city model (Arroyo Ohori et al. 2018).

With CityGML models used to store building energy-related information like building function and year of construction which are vital for building energy simulation, various energy simulation platforms like SimStadt (Schumacher 2020) have adopted CityGML as a definitive source for 3D city model information as data input for performing energy simulations such as energy demand and solar energy potential. These simulation results are usually represented by the visualisation platform as it makes data more comfortable for the human to understand and makes it easier to detect patterns, trends, and outliers in groups of data (Yi et al. 2008). Furthermore, city administrators and agencies can, therefore, use these data visualisations to make important decisions concerning their cities and make changes where needed to improve efficiency.

However, the various data simulation results from CityGML-based building models could lead to the complexity and heterogeneity of the data model. Therefore, a proper way of managing and visualising this information is necessary and needed to trace patterns and place meaning within the data being integrated. In the past, the Application Domain Extension (ADE) had been developed for extending and managing a specific group of environmental data such as energy-related building data to be modelled in connection to CityGML (Biljecki et al. 2018). Still, ADE has some limitations as it needs layers of data conversion, structures, and tools to access, deliver, and visualise on the web client (Lim et al. 2020).

In this article, we study and evaluate alternative approaches for managing energy-related building information with a particular focus on how the 3D city model can be used for collecting, computing, and visualising energy simulations using the following methods: (1) computing and visualising the simulated energy data of 3D building models on-the-fly, (2) using the PostgreSQL database as a datastore for simulated energy data, and (3) using SensorThings for managing the simulated energy data. These methods are, however, not the only methods available, but we intend to compare them to find out which is more efficient when it comes to managing and visualising energy-related building information such as photovoltaic (PV) energy generation potential, heat demand, etc. from CityGML models.

This section explains our concept for managing the simulated energy data of 3D building models using the SimStadt simulation software. Several approaches had been implemented and these are compared and evaluated in turn. These approaches include (1) computing and visualising the simulated data on the fly, (2) using the PostgreSQL database as a datastore for the simulated energy data of 3D building models, and (3) using SensorThings for managing the simulated energy data of 3D building models.

The implementations of this research are based on the 3D city models in the CityGML format. First, the building simulations were performed in the SimStadt simulation platform based on these CityGML building models (see Sect. 16.4.1). Second, three different approaches for managing the energy-related result from SimStadt and distributing to the web clients were conducted (see Sect. 16.4.2). Finally, the 3D building models with energy data were visualised on the web-based clients for each data management approach. The implementations of each approach in this paper are described in Fig. 16.1.

After servers had been implemented according to the three mentioned approaches, a 3D web application had been developed to present the result data by colouring the building roofs using the data and also showing them in an informative table (see Fig. 16.2). This table is displayed when users select a particular roof in the application. The building roofs are symbolised in different colours based on six different result data, where users can switch between to have a more intuitive result, which should help users to interpret the result data. These result data are PV potential yield, PV specific yield, levelised cost of electricity, total investment, discounted payback period, and financial feasibility.

This research evaluates and compares three different approaches for managing the energy-related data of the 3D city models including (1) managing building simulation data on-the-fly (via simulation API), (2) managing building simulation data using a database, and (3) managing building simulation data using OGC SensorThings API standard. Several features in aspects of data visualisation on the web client and data organisation had been conducted (see Table 16.1).

In the first approach, the simulation is done on-the-fly in real time. The main advantage of this approach over other approaches is that users can input the parameters for the building energy simulation every time they use the application. However, as the simulated data is not stored anywhere, the energy simulation process is always triggered every time users visualise the energy data, which costs the server computation and user payload.

In the second approach, the regular database is used for storing and distributing the energy-related data of the building models. This provides an advantage when storing large-scale building data. Also, the simulation data can be loaded to the client in a very short time as the simulation data is pre-calculated on the server-side. However, as there is no interface to get the data from the database, it needs a programming tool to connect a client to the database level, which this process has to be repeated when applying to a new use case. Another obvious drawback is that users cannot input the parameters to calculate specified simulation scenarios on-the-fly. To deal with this, several simulation scenarios can be pre-calculated with a trade-off for the storage requirement on the database.

In the last approach, the SensorThings API specification is implemented on the server-side for managing the energy-related data of the building models in which each Thing entity is linked to the particular CityGML part by the CityThings concept (Santhanavanich and Coors 2021). As the backend of the SensorThings server is the database, it supports large-scale building energy data transaction. In this approach, users can request, add, update, or delete energy data of the building models from the database through the SensorThings interface, which is a standardised specification from OGC (Liang et al. 2016). Accordingly, the data managed by SensorThings can be distributed widely for several client applications with the SensorThings interface without the need for the dynamic web server to access the database. Although it lacks flexibility for user’s specified parameters, several simulation scenarios can be performed and updated to the SensorThings server effectively through the HTTP POST method. Compared to the CityGML ADE, SensorThings manages the energy data independently, and there is no need for modifying the existing CityGML XML schema for the energy data. Moreover, the SensorThings has the JSON-based encoding, and its interface supports queries through the HTTP GET request, which includes result sorting, result filtering, and geolocation filtering. Still, the data modelling of the energy data to the SensorThings schema is not straightforward, since the characteristic of dynamic data from an energy simulation is different from the ones from IoT devices. Therefore, the mapping must be carefully designed in order to reach optimal usage.

CityGML models are used in several domains and locations around the world. In the context of the building energy demand and PV potential simulation, the CityGML ADE had been developed to handle the simulation result. However, there is still a lack of open-source tools and platforms to manage and distribute data efficiently. In this article, we present a way to bridge these gaps by evaluating and comparing three alternative approaches for managing the building energy simulation data, including (1) managing simulation data on-the-fly (via simulation API), (2) managing simulation data using a database, and (3) managing simulation data using OGC SensorThings API standard. The three implementations were assessed comparatively in the use cases of heat demand and PV potential analysis in cities in Germany, including Stöckach-Stuttgart, Ludwigsburg, and Grünbühl. The evaluation of these three approaches is discussed in Chap. 5. In summary, each approach discussed in this research has advantages and disadvantages that can effectively influence which approach will be selected by researchers or application developers.

The first approach would give users the flexibility to simulate the building energy demand and potential with user-specified parameters in which the high-performance computation power is needed on the server-side. However, in the second and third approaches, the database is used to store the simulated result in advance, in which high disk space on the server is required to store several simulation scenarios. Comparing the regular database and the SensorThings for storing the simulated result, the SensorThings shows advantages of flexibility, allowing users with multiple roles to read, add, update, and delete the data with the standardised request protocol. Accordingly, using SensorThings is more efficient and effective in terms of data management and data distribution. In conclusion, the integration of the SimStadt API service for simulating results on-the-fly and the SensorThings API for managing pre-simulated results is recommended to enable most benefits to store and visualise the energy analysed data in the smart cities’ application.