CityThings: An integration of the dynamic sensor data to the 3D city model

Abstract

Devices from the Internet of Things are being increasingly used in everyday life, and they provide a massive amount of data in various formats. While implementing the Smart Cities initiative, these data are integrated and utilized together with the 3D city model for further applications. Based on Open Geospatial Consortium standards, heterogeneous sensor data can be integrated with the Open Geospatial Consortium SensorThings Application Programming Interface. Similarly, the 3D city model data can be stored and exchanged with the Open Geospatial Consortium CityGML format. However, currently, there is no concrete model to integrate these sensor data with the 3D city model using the Open Geospatial Consortium standards. The existing solution for integrating the sensor data into the 3D city model requires an extension or plug-in for adding the data to the CityGML model. In this paper, we introduce the concept of “CityThings” to integrate dynamic sensor data from the Open Geospatial Consortium SensorThings API into the CityGML 3D city models. We demonstrate the implementation of the CityThings concept in the Smart Villages project in the study area of Wüstenrot, Germany, by integrating dynamic sensor data from several systems including solar panels, agro-thermal plants, and weather monitoring sensors to visualize the sensor data with the 3D city model on the web platform. In the future, this concept can be applied to interconnect dynamic sensor data and 3D city model data in other Smart Cities applications.

Keywords

Smart Cities urban informatics sensors 3D city model

Introduction

The initiative of Smart Cities has been adopted by many cities around the world. This concept encompasses the utilization of the right hardware, software, technology platforms, and data from various sources to solve urban development challenges and establish a tool for managing natural resources, urban mobility, urban energy, buildings, government administration, and the economy (Calvillo et al., 2016; Mosser et al., 2013). However, there is a need for obtaining data from various sources to develop the Smart Cities initiative. The advancement in the Internet of Things (IoT) technologies allows sensors to be controlled through remote networks. Thus, data streams from the sensors or IoT devices are important data sources for the Smart Cities initiative (Perera et al., 2014; Liang, 2016). Apart from IoT devices and sensors, many modern smart city projects have successfully used 3D city models in urban platforms, not only for visualization purposes but also as sources of information for tools to conduct analysis in cities, such as urban energy management and noise management simulation (Nouvel et al., 2013; Prandi et al., 2013).

Accordingly, both IoT datastreams and 3D city models play an important role as sources of data in the development of modern Smart Cities. However, it is important to consider several prerequisites to deal with these data sources including the scalability to handle massive heterogeneity, data privacy and security, and data access with an open interface (Balakrishna, 2012). Thus, open-standard tools for dealing with these data are required. For this purpose, the Open Geospatial Consortium (OGC), the leading organization for geospatial standardization, has provided open standards including SensorThings for managing dynamic IoT data and the CityGML format for managing and exchanging 3D city models. However, there is still a lack of research on the connection between these two standards. In this paper, we study and propose a concept named “CityThings” to utilize and connect these two standards in the Smart Cities initiative.

The remainder of this paper is structured as follows. In Section “State of the art,” the state of the art focusing on dynamic sensor data and 3D city model management is discussed. Section “The CityThings concept” describes the working of the concept “CityThings.” Section “Implementation” describes the requirements and implementation stages regarding CityThings. In Section “Use case examples,” the use case of CityThings by connecting sensor data to the 3D web platform in the Smart Villages project in the study area of Wüstenrot is presented. This is followed by an evaluation of the CityThings concept in Section “Discussion.” Section “Conclusion” presents the conclusion of this study and the future implications of this research.

State of the art

Recently, the OGC introduced the SensorThings Application Programming Interface (API) standard specification to interconnect data from various sensor sources to the application layer (Liang, 2016). The SensorThings API follows the representational state transfer principles, which allow developers to perform Create-Read-Update-Delete operations through the HTTP methods—POST, GET, PATCH, and DELETE, respectively, to interact with the heterogeneous sensor data in JSON encoding by following the OASIS OData protocol and URL conventions. The foundation of this standard is designed based on the OGC Observations and Measurements model and allows IoT devices and applications to create, read, update, and delete IoT data and the corresponding metadata in a SensorThings service. The advantage of this standard over other IoT standards is that it supports a comprehensive conceptual model and query functionalities. This standard is also extended to manage the tasking capabilities that provide a mechanism to command the IoT devices (Huang and Wu, 2016). SensorThings API is used to manage the heterogeneous data and offer interoperable services to facilitate access to data via the application platform (Soto et al., 2016; Trilles et al., 2015). In addition, SensorThings supports dynamic data, for example, it was used in a study implementing a system for monitoring dynamic e-bike usages and user fitness levels (Santhanavanich et al., 2018). All the aforementioned characteristics prove that SensorThings API is an effective and efficient tool for monitoring irregular time-series data from various sensor types and maintaining the interoperability of the sensor and IoT data from the different development layers. In addition, it was shown that the SensorThings API is more efficient in terms of bandwidth efficiency and is more suitable for real-time applications than other existing IoT standards (Jazayeri et al., 2015; Santhanavanich, 2018).

Regarding the 3D city models, OGC provided the CityGML standard to store and exchange 3D city model data effectively (Gröger et al., 2012). It collects geometric and semantic attributes of city-level objects along with their interrelationships with other objects. Accordingly, there are many cities in the world using the CityGML standard for representing their 3D city models, for example, Berlin, Cambridge, Dresden, Espoo, Hamburg, Helsinki, etc.¹ A study on storing and exchanging sensor or time-series data in the CityGML model was conducted by using the concept of “Dynamizers” introduced by Chaturvedi and Kolbe (2015). The Dynamizers concept is used to model and implement dynamic variations of properties of city objects for semantic 3D city models. It allows injecting dynamic and time-varying attributes directly into the 3D city model in the CityGML format, for example, the building electricity usage or the traffic density of a road. In addition, Dynamizers have been proposed to be included in the next major version of the CityGML standard (version 3.0) (Kutzner et al., 2020). However, the following are some of the limitations regarding the utilization of Dynamizers: (i) as the sensor systems and IoT devices are used in every location in the city, to implement the concept of Dynamizers, there needs to be a complete representative model including all CityGML models of the city to connect to all available sensor systems; and (ii) in most cases, the CityGML provider and the sensor system provider are from different parties or organizations, which makes it difficult for the CityGML maintainer to handle the dynamic sensor data. Accordingly, we propose an effective and efficient way of managing dynamic sensor data in the 3D Smart Cities platform by using the concept of CityThings.

The CityThings concept

The CityThings concept proposes an approach to manage streams of sensor data related to a 3D city model based on the SensorThings and CityGML standards. We use the SensorThings API to manage the data of sensors or IoT devices along with the connection of the data to the 3D city model. The information collected by sensors of IoT devices is collected in the SensorThings API entity types including Thing, Sensor, Datasteam, Location, HistoricalLocation, ObservedProperty, Observation, and FeatureOfInterest, as shown in Figure 1. The Thing entity defines a physical object or sensor system in the real world. The Location entity represents the location of a Thing. Each Thing has one or more Datastreams. Each Datastream has one ObservedProperty and one Sensor. In addition, each Observation has one Datastream with one specified FeatureOfInterest and is used to collect the real-time or historical measured time-series data (Liang, 2016).

Figure 1.

UML diagram showing SensorThings entities.

In the SensorThings API, the properties of the sensors or physical objects are stored in the properties array in the Thing entity. According to the standard definition, all the data are maintained in JSON format, which gives developers the flexibility to add and store several pair values or arrays in the properties array. For example, Figure 2 shows the JSON for the Thing entity of the room sensor monitoring system, which has several properties.

Figure 2.

An example JSON showing a Thing entity with several properties.

For the 3D city models, components of buildings in the CityGML standard are identified with the gml-id. As the gml-id is unique according to the CityGML standard (Gröger et al., 2012), the gml-id links to a specific part of the CityGML model. We propose to add this identification to link with the sensor system in the SensorThings standard by loading it as one of the properties of the Thing entity of SensorThings API. For example, in the case of the sensor system in a specific room in the CityGML model, the gml-id of the room is collected in the Thing’s properties in the SensorThings API (see example in Section “Connection of SensorThings and CityGML”). Later, users can query the gml-id directly from each Thing in the SensorThings API with the Thing’s properties. With the gml-id, users can retrieve information of the 3D city model in the CityGMLformat.

For example, Figure 3 illustrates the connection of the Things entity in the SensorThings API to different components of the city buildings in the CityGML model. It is also possible to apply this concept to other parts of the city model, such as roads, trees, and river bodies. When sensor systems are established in an area without any corresponding CityGML model, the absolute location of sensors can always be stored and retrieved by users with the Location entity. Later, the connection to the CityGML model can be updated to the Thing entity.

Figure 3.

A diagram showing a simplified example of the connection between the SensorThings API and CityGML city model.

The CityThings concept also supports sensor movement or relocation, which is handled by the SensorThings API with the Things and Location entity. For example, when the sensor system is moved, the new location is updated to the Location entity. Later, users can track the system’s path in the HistoricalLocation entity. In the case of relocation to a new building part in the city model, the data maintainer can manually register an updated link to the city model in the Thing’s property or automatically update the Things entity by matching the location of the sensor to the 3D city model.

From the user perspective, users can retrieve the sensor measurement data and metadata from the SensorThings API together with the gml-id as a key to obtain additional building information from the CityGML model. Users can also use the SensorThings API to query a list of building models from a specified sensor system and vice versa. It is recommended that the CityThings concept be used with the CityGML model. To address this, the 3D City Database (Yao et al., 2018) is an open-source software that provides a method to easily import a CityGML model to the PostgreSQL or Oracle database.

Implementation

This section explains the implementation of the CityThings concept. The overall system architecture is shown in Figure 4. To apply this concept, the data from the physical sensor system is registered to the SensorThings API (Figure 4(a)), and the 3D city models are stored on the server-side with the CityGML format (Figure 4(b)), which is explained in Section “Server-side preparation.” Subsequently, the connection between the SensorThings API and the CityGML format (Figure 4(f)) is explained in Section “Connection of SensorThings and CityGML.” Section “Retrieval of sensor and 3D city model data” explains how to retrieve sensor and city model data by using the CityThings concept. Finally, Section “Time-series data aggregation” explains how to use SensorThings Aggregator (Figure 4(e)) to retrieve the preprocessed aggregated sensor data.

Figure 4.

System architecture of the CityThings concept.

Server-side preparation

Sensor data management

To implement the CityThings concept, the first step is to set up the SensorThings server (Figure 4(a)). The Fraunhofer Opensource SensorThings (FROST)² was used to set up the API server in this study. The system is set up together with the PostgreSQL database with PostGIS extension. After the sensor server is set up, all the sensor systems must be registered to the SensorThings API server in all required entities, as mentioned in Section “The CityThings concept.” Subsequently, the measured data from the sensor systems are transferred to the SensorThings API server. In this step, a script regarding the sensor systems or intermediate servers must be created in order to: (i) process the sensor data to the specified structure in JSON format according to the SensorThings standard; (ii) assign the measured data from each sensor system to the correct Datastream-id; and (iii) transfer the preprocessed data to the SensorThings API server with the HTTP or MQTT methods. In order to make the SensorThings API friendlier to researchers in different areas, the authors in their previous study developed an open-source tool called “SensorThings Importer” (Figure 4(d)) to easily import historical time-series data from several formats such as CSV, JSON, and GPX to the SensorThings API (Santhanavanich, 2019b). In conclusion, the dynamic time-series sensor data are handled in the SensorThings server and are independent of the CityGML model. The connection between the sensor system and the city model is explained in Section “Connection of SensorThings and CityGML.”

3D city model data management

Today, an increasing number of cities in Europe have their own digital 3D city model in the CityGML format (Figure 4(b)), and there are many existing tools to manage this data format. For example, the 3D City Database allows users to efficiently store, represent, and manage a huge CityGML model. The web-based 3D visualization plays an important role in delivering the 3D city model contents to a large audience. To support these tools, some open-source API frameworks such as Cesium and NASA WorldWind have been introduced to render and deliver 3D content on the 3D virtual globe through the web. However, there is no direct way to visualize the CityGML-based model on the web browser. According to the OGC, the 3D Tiles format has been introduced as a standard defining a spatial data structure and designed for optimized 3D streaming and rendering (Open Geospatial Consortium, 2019a). Although there is currently no open source tool for converting the CityGML-based city model to the 3D Tiles format, there are many commercial tools that are available for academic use such as Cesium ION or Feature Manipulation Engine (FME) that accomplish this task efficiently.Additionally, to manage the availability of the 3D Tiles content, the 3D Portrayal Service (Open Geospatial Consortium, 2019b) is introduced by the OGC for a geospatial 3D content delivery implementation specification. The 3D Portrayal Service helps the data manager to specify how geospatial 3D content is described, selected, and delivered through the web. The authors of this study have also implemented the 3D Portrayal Service (Figure 4(c)) running on the NodeJS runtime to access the converted 3D Tiles data set.

Connection of SensorThings and CityGML

This section presents a method to connect the sensor systems from the SensorThings API to the CityGML-based 3D city model. Each element of the city model contains a gml-id as its unique identity. In the concept of CityThings, the gml-id must be registered as a property of the Things entity in the SensorThings API. This can be achieved by generating an array called CityThings in the Things entity’s properties array. This array contains the key-pair-value of the gml-id of the city model. When the data maintainer knows the specified building element wherein the sensor is installed, only the gml-id from the deeper level in the CityGML city model is necessary to be stored in the SensorThings API. To demonstrate this, Figure 5 shows an example of a building in the city model in the CityGML format with the specified building gml-id (Figure 5: row 5) which is “DENW24ALG00003YF.” In addition, it contains the wall surface with the specified gml-id (Figure 5: row 11) which is “GML_50-155-aa175.”

Figure 5.

An example building in the CityGML format.

For example, when a new sensor system is installed in this building from Figure 5, and no particular location of the building part is specified, the gml-id of the building “DENW24ALG00003YF” is registered to the properties array of the Things entity in the SensorThings API as shown in Figure 6: row 9. In the case where the sensor’s location is specified, for instance, at the outer wall in the southwest, the gml-id of “GML_50155-aa175” needs to be registered. Later, the information on the outer level of the CityGML hierarchy can be retrieved from the 3D City Database.

Figure 6.

An example JSON showing a Things entity in the SensorThings API, which connects to a building in the CityGML format in Figure 5.

Retrieval of sensor and 3D city model data

We can retrieve the sensor data in the 3D city model efficiently with the HTTP GET request to the SensorThings API. With the request URI, the SensorThings API supports the query option, which allows users to filter a specified collection of entities, including building information and sensor information, as shown in Table 1. Example a. in Table 1 shows a simple request to obtain a list of sensor systems that are operational in a specified building. In Example b., a more complex query is shown for searching a set of Datastreams that measure the specified ObservedProperty of a sensor system operational in a specified building. The example result from Example b. is shown in Figure 7. With the expand query option, the response shows users the city model gml-id (Figure 7, row 7) and the Observation time-series result (Figure 7, row 13:29) from a single request directly.

Table 1.

Examples of the HTTP GET request for retrieving sensor and 3D city model data.

Ex.	Request URI	Description
a.	http://<STA-Base>/Things? $filter=Things/properties/citythings/gml_id eq ‘xx1’	Request all physical systems (Things) from the building with gml-id “xx1”
b.	http://<STA-Base>/Datastreams? $expand=Thing&	Request for all Datastreams of the sensor system that is registered to building gml-id xx1 and which measures room temperature with the unit of measurement in Celsius
	$expand=ObservedProperty&
	$filter=Things/properties/ citythings/gml_id eq ‘xx1’&
	$filter=ObservedProperty/name eq ‘room-temperature’&
	$filter=Datastream/unitOfMeasurement eq ‘Celsius’

Figure 7.

An example JSON shows the request result of an example request b. stated in Table 1.

In this way, we can easily retrieve the observation data from the sensor server based on a gml-id from the CityGML format. We can also obtain the information of the city model from the SensorThings API response by the gml-id in the Things entity’s property array. CityThings also supports the request for sensor data based on city model attributes. Users can easily search and query the gml-id of the buildings with the specified attributes from the city model database. Subsequently, the result of gml-id can be used to query sensor data from the SensorThings API.

Time-series data aggregation

CityThings provides users access to sensor data sets through SensorThings API as time-series in JSON format, which can be utilized in many application domains. However, the SensorThings standard does not contain an aggregation feature. In the case of managing a huge data set of spatiotemporal data, there is a need for a data cleaning process, including aggregating the data to a specified time range. Many times, the aggregation method is executed while importing data into the database, for example, the temperature data collected in hourly intervals from the one-minute interval temperature sensor. However, this causes data loss. As different sensor data intervals are needed for different purposes, we stored all raw data from sensors to the SensorThings API server and developed a tool “SensorThings Aggregator” (Figure 4(e)) for processing and delivering aggregated sensor data from the SensorThings API on the server side (Santhanavanich, 2019a). This tool is used together with the SensorThings API server by considering the SensorThings observation URI, aggregation type, and time interval as input parameters. This tool allows several aggregated methods, including mean, sum, min, max, first, and last. With this tool, users benefit by obtaining the processed time-series data in the desired time interval, freeing the space that would have been used if all data were retrieved, and reducing the bandwidth used over the network.

For example, the line chart in Figure 8(a) shows the data of the specific yield from one solar panel in the Wüstenrot area with a size of 11,090 Bytes while the chart in Figure 8(b) shows the aggregated monthly average result with a size of 434 bytes, which reduces the size of the data by 96%. In many applications, there is no need to use and visualize all raw values. In this example, the monthly aggregated data also provide users with an insight into the specific yield over the year. This proves that the SensorThings Aggregator significantly helps in the application development by speeding up the execution of visualizing and analytical processes by reducing the size of transferred data and decreasing the complexity of the computations.

Figure 8.

Aggregated time-series data.

Use case examples

In this research, we demonstrate the use of the CityThings concept as a part of the Smart Villages project implemented in cooperation between the University of Applied Sciences, Stuttgart (HFT-Stuttgart) and the State Office for Geoinformation and Land Development (LGL). The project aims to transfer the “Smart Cities” concept to small- and medium-sized municipalities by the development of a 3D web platform that links the 3D building model with sensors and real-time visualization, thus making the 3D city models useful to science, administration, and citizens.

The area of interest in this use case is Wüstenrot, a residential district located in a forested area in the southeast of the district of Heilbronn and has approximately 6800 inhabitants. For the implementation of the Smart Villages project, the CityGML model of Wüstenrot is provided by the LGL. The city model is converted to a 3D Tiles format for visualizing building models on the 3D Cesium-based application and supporting the semantic information of the models. The converted data set is then imported into the implemented 3D Portrayal Service for delivering the 3D Tiles content to the web. After taking these steps, the interactive “Smart Villages: Wüstenrot” 3D web platform was developed with virtualcitySYSTEMS software,³ and the CesiumJS-based application as shown in Figure 9.

Figure 9.

Smart Villages: Wüstenrot web platform.

To demonstrate the CityThings concept, we integrated the sensor data from several systems including the solar energy system, the agro-thermal system, and the weather sensor system via CityThings to visualize the sensor data with the 3D city model and share it with the public through the Smart Villages: Wüstenrot web platform. Different organizations maintain these sensor systems, and it is a challenge to integrate these heterogeneous sensor data. The sensor data sources are listed as follows:

The solar energy sensor system from the iPlon GmbH measures hourly electric generation (kWh) and daily specific yield (kWh/kWp) from public buildings in the Wüstenrot area. The data were collected at hourly intervals and published to the SensorThings server.⁴

The energy meter sensor managed by Enisyst GmbH measures energy demand (kWh) and energy production (kWh) of the public buildings in the Wüstenrot area. The data were collected at hourly intervals and published to the SensorThings server.⁴

The agro-thermal system managed by Enisyst GmbH measures the ground temperature (°C) at multiple ground depth levels at one-minute intervals to illustrate the efficiency of heat generation from the ground over different seasons of the year. The hourly interval data are published to the SensorThings server.⁵

The weather sensor system from OpenWeatherMap⁶ measures weather data such as temperature (°C), wind speed (m/s), wind direction (°), and cloudiness (%). The hourly interval data are published to the SensorThings server.⁷

The weather sensor system from the German Meteorological Service (Deutscher Wetterdienst) measures weather data including air temperature (°C), cloudiness (%), precipitation (yes/no), pressure (hPa), soil temperature (°C), and hourly sunshine duration (min). The hourly interval data are published to the SensorThings server.⁷

We connect all sensor datasets to the SensorThings API server with the STA Importer tool (Figure 4(d)) developed by the authors of their previous study. Subsequently, the city model information of each sensor is registered to the properties array of the Thing entity in the SensorThings API, as mentioned in Section “Connection of SensorThings and CityGML.”

After the CityThings concept was implemented for the Smart Villages: Wüstenrot web platform, users were able to visualize the sensor data directly from an interactive 3D building on the platform as an example depicted in Figure 10. In this example, the interactive window visualizes building information, sensor information, and sensor measurement data from the solar energy systems and the weather sensor systems at daily intervals. The building information is based on the data from the attributes of the CityGML model, which are also stored in the 3D Tiles model for web-based visualization. In addition, the sensor information is retrieved from the Thing and Sensor entities of the SensorThings API database. For the line chart displaying the measured data, we used the Apexcharts.js open-source JavaScript library to create an interactive chart by taking the sensor data from the SensorThings API Observations entity. Similarly, the Smart Villages: Wüstenrot web platform also supports visualizing the underground agro-thermal plants in 3D with the interactive chart window showing the plant information, sensor information, and temperature data from different ground levels. In this use case, raw data from all sensor systems are stored irregularly in the database at several time intervals ranging from one-minute intervals to daily intervals; therefore, the SensorThings Aggregator developed by the authors is used to aggregate the sensor data on the server-side and to deliver lightly-processed data in uniform time intervals to the client. With the integration of CityThings, the Smart Villages web platform offers an insight into the eco-friendly energy generation of solar panels and agro-thermal plants in the Wüstenrot village. By doing so, it may influence the public to be more interested in such eco-friendly energy sources. This Smart Villages web platform is in an early phase of development and the next phase of development aims at incorporating more sensor systems. For future work, we plan to develop more application functionalities for specific academic user groups for further data analysis, such as solar energy potential, heat demand, refurbishment suggestion for improving energy efficiency, etc. Furthermore, the sensor measurement and city model data set up for this developed platform can be retrieved and used in many different domains or applications without worrying about heterogeneous and irregular non-uniform data.

Figure 10.

Smart Villages: Wüstenrot web platform integrated with CityThings for visualizing sensor data of a selected building.

Discussion

The CityThings concept shows how to connect dynamic sensor data to the 3D city model effectively based on the SensorThings standard specification. From our study, we find several advantages of using CityThings. First, this concept avoids storing or injecting the sensor data directly into the CityGML city model file or database, which is already huge in itself. Instead, it stores the sensor data in separate databases. In this way, the sensor and city model data management can be handled by different parties, which leads to an easier maintenance of a 3D city model. The sensor manager is only responsible for the sensor systems, and vice versa. In addition, whenever a change is made to the sensor systems or city models such as a sensor relocation, an update to the sensor system and city model can be made in a straightforward manner.

Second, CityThings is implemented based on several OGC standards and utilizes the advantages of these standards. The CityGML format is used for storing and maintaining the 3D city model, while the SensorThings API is used for managing heterogeneous sensor systems and providing an interface to interact with the sensor data. With the SensorThings API, users and application developers benefit from accessing the sensor data and its metadata in JSON format, which is compact and can be easily used in several applications. However, with the SensorThings API alone, users must load all data from the observation results over the network because of a lack of the data aggregation feature. To address this, we developed the SensorThings Aggregator tool to overcome this limitation of the SensorThings API, which helps the aggregation of sensor data on the server side.

For web analytics and visualization, the CityGML model can be converted to the 3D Tiles format and practically delivered to users with the 3D Portrayal Service. Finally, CityThings supports data query by using both sensor information and city model information. Users can make a query based on the city model information of the CityGML model through the 3D City Database or its exported spreadsheet. The resulting gml-id can then be used to query the sensor system information and its observation through the SensorThings API, and vice versa.

Additionally, the CityThings concept can be implemented in other different applications in the city area, and it is not limited in being achieved with CesiumJS- or virtualcitySYSTEMS-based applications. Other 3D web-based applications such as ArcGIS, Deck.gl, and Three.js, also support the building model semantic information. In addition, CityThings is not limited to its use with building models but also supports other city model objects such as trees, roads, rivers, etc. The mandatory requirements for using the CityThings concept are: (i) CityGML be used as a city model format, and the gml-id of the model must be unique; (ii) the SensorThings standard should be used for sensor data management; and (iii) the SensorThings manager has access to the CityGML model and registers the correct gml-id for each property in the Thing entity.

Conclusion

The CityThings concept simplifies the connection between the sensor systems and the 3D city model in the Smart Cities web platform by using the SensorThings API and the CityGML model. With the utilization of CityThings, researchers and developers can retrieve dynamic time-series observation data from heterogeneous systems and attribute information from a 3D city model, which can be used in many different domains and applications in a convenient and efficient way. In addition, the system can be extended to 3D web-based applications by converting the CityGML format to the 3D Tiles format and delivering the 3D content to the client with the 3D Portrayal Services. In this paper, we demonstrated the utilization of the CityThings concept in the Smart Villages project, which integrates sensor data from many sources and links them to the existing 3D city models in the CityGML format. In the future, we will: (i) include more sensor devices to the Smart Villages platform; (ii) add features for interactive data analysis, such as building solar-energy potential or refurbishment recommendations according to the building model and sensor data; (iii) conduct a study on applying the CityThings concept to other building model formats such as CityJSON and ESRI I3S; and (iv) carry out research for designing an automated algorithm to link the sensor system to the building models according to their location.

Footnotes

Acknowledgements

The authors would like to thank the Geoinformatics Department of the State Office for Spatial Information and Land Development (LGL) Baden Württemberg and the software team from Enisyst GmbH and iPLON GmbH for their fruitful long-term collaboration.

Declaration of conflicting interests

The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.

Funding

The author(s) disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: This work was supported by subsidies from the Digitization Strategy Baden-Württemberg (digital@bw).

ORCID iD

Thunyathep Santhanavanich

Notes

Thunyathep Santhanavanich is a Researcher in the Department of Geoinformatics and Computer Science at the University of Applied Sciences Stuttgart. His research interests primarily centre on GIScience and the applications, especially on the topics of 3D Spatial Data Infrastructure and Spatial Data Visualization.

Volker Coors is a Professor in the Department of Geoinformatics and Computer Science at the University of Applied Sciences Stuttgart and a director of the Institute for Applied Research Stuttgart. His research interests include 3D Spatial Data Infrastructure, Spatial Data Visualization, and Urban Analytics.

References

Balakrishna

(2012) Enabling technologies for smart city services and applications. In: 6th international conference on next generation mobile applications, services and technologies (NGMAST) (ed K Al-Begain), pp. 223–227. Piscataway, NJ: IEEE.

Calvillo

Sánchez-Miralles

Villar

(2016) Energy management and planning in smart cities. Renewable and Sustainable Energy Reviews 55: 273–287.

Chaturvedi

Kolbe

(2015) Dynamizers – Modeling and implementing dynamic properties for semantic 3D city models. In: Biljecki

Tourre

(eds) Eurographics Workshop on Urban Data Modelling and Visualisation. Norrköping, Sweden: The Eurographics Association.

Gröger

Kolbe

Nagel

, et al. (2012) OGC city geography markup language (CityGML) encoding standard. Available at: www.opengis.net/spec/citygml/2.0 (accessed 20 November 2018).

Huang

(2016) Design and implement an interoperable internet of things application based on an extended OGC SensorThings API standard. Isprs – International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences 263–266. DOI: 10.5194/isprs-archives-XLI-B4-263-2016.

Jazayeri

Liang

SHL

Huang

C-Y

(2015) Implementation and evaluation of four interoperable open standards for the internet of things. Sensors (Basel, Switzerland) 15(9): 24343–24373.

Liang S, Huang C-Y and Khalafbeigi T (2016) OGC Sensor Things API Part 1: Sensing. Available at: http://docs.opengeospatial.org/is/15-078r6/15-078r6.html (accessed 20 November, 2018).

Kutzner

Chaturvedi

Kolbe

(2020) CityGML 3.0: New functions open up new applications. PFG – Journal of Photogrammetry, Remote Sensing and Geoinformation Science 88(1): 43–61.

Mosser

Logre

Ferry

, et al. (2013) From sensors to visualization dashboards: Need for language composition. In: Globalization of modeling languages workshop (GeMOC’13), Miami, FL, USA.

10.

Nouvel

Schulte

Eicker

, et al. (2013) CityGML-based 3D city model for energy diagnostics and urban energy policy support. IBPSA World 2013: 1–7.

11.

Open Geospatial Consortium (2019a) 3D tiles specification 1.0. Available at: http://docs.opengeospatial.org/cs/18-053r2/18-053r2.html (accessed 28 May 2019).

12.

Open Geospatial Consortium (2019b) 3D portrayal service 1.0. Available at: http://docs.opengeospatial.org/is/15-001r4/15-001r4.html (accessed 28 May 2019).

13.

Perera

Zaslavsky

Christen

, et al. (2014) Sensing as a service model for smart cities supported by internet of things. Transactions on Emerging Telecommunications Technologies 25(1): 81–93.

14.

Prandi

De Amicis

Piffer

, et al. (2013) Using CityGML to deploy smart-city services for urban ecosystems. Isprs – International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences 4: 87–92.

15.

Santhanavanich T, Schneider S, Rodrigues P, et al. (2018) Integration and Visualization of Heterogeneous Sensor Data and Geospatial Information. ISPRS Annals of Photogrammetry, Remote Sensing and Spatial Information Sciences IV-4/W7: 115–122.

16.

Santhanavanich

(2018) Visualization and analysis of E-bike usage in 3D city model by integration of heterogeneous sensor data. Master Thesis, University of Applied Sciences Stuttgart, Germany.

17.

Santhanavanich

(2019a) SensorThings Importer: A Tool for Importing Data from Several Formats to SensorThings Server. Geneva, Switzerland: Zenodo.

18.

Santhanavanich

(2019b) SensorThings-Aggregator: A Tool for Aggregating Time-Series Data from SensorThings API Observation Entity. Geneva, Switzerland: Zenodo.

19.

Soto

JAC

Werner-Kytölä

Jahn

, et al. (2016) Towards a federation of smart city services. In: Proceeding of international conference on recent advances in computer systems. Amsterdam, The Netherlands: Atlantis Press.

20.

Trilles

Luján

Belmonte

, et al. (2015) SEnviro: A sensorized platform proposal using open hardware and open standards. Sensors (Basel, Switzerland) 15(3): 5555–5582.

21.

Yao

Nagel

Kunde

, et al. (2018) 3DCityDB – A 3D geo-database solution for the management, analysis, and visualization of semantic 3D city models based on CityGML. Open Geospatial Data, Software and Standards 3(1): 5.