OGC 3D-IoT Platform for Smart Cities Engineering Report

SensorThings API also enables the continuous processing of Observations from multiple Datastreams to generate a higher-level Observation. Conceptually it can be described as follows:

For example, dew point temperature can be calculated with observed air temperature and relative humidity.

In many cases, a higher-level Observation is derived from one set of Observation, i.e., from the same Datastream. For example, the speed of a moving feature can be derived from the moving feature’s location_observation1 in t1 and location_observation2 in t2.

In practice, higher-level Observations can be derived through the chaining of multiple SensorThings API implementations through the publish/subscribe-based MQTT protocol. The following diagram Figure 4 describes the concept.

The facility manager uses a web-based system to monitor the current air quality. The air quality is measured by a number of sensors distributed in the Sejong area, for example in the lamp posts along the main streets. The measurements are visualized in real time in a 3D environment together with a 3D city model to get a better understanding of the air quality in along the streets and the built environment. In the pilot, only fine dust PM_2.5 is taken into account as an indicator of air quality for reasons of simplicity. As air quality is a continuous phenomenon, the sensor measurement is interpolated in real time to get a distribution of the air quality in space. The air quality distribution is simplified by using an Inverse Distance Weighted (IDW) interpolation. The facility manager can get access to the current and historic measurements of every single sensor. The historic measurements are then shown as a line chart diagram in the 3D viewer.

The administrator of the web-based service - the 3D GeoPortal - has to prepare the 3D model for web-based 3D visualization. In addition, the sensors have to be registered and integrated into the 3D model to ensure that the sensor readings are visualized in the correct 3D location.

The facility manager uses a web-based system to monitor the occupancy of interior spaces. On an abstract level, this use case is similar to Use Case 1-1. However, the interactive visualization of the building interior is an additional challenge. Location based Augmented Reality shall be used in addition to a virtual reality 3D globe. Another challenge is the use of sensors to observe the occupancy of an interior space. A virtual sensor gives the number of people in a given space. However, this is the result of a cascading sensor system, for instance one sensor measures the CO₂ in ppm and a set of camera sensors observe the space. Based on an algorithm, the number of people can be derived from these measurements. In this pilot, the virtual sensor generated synthetic data. Consequently, the architecture took the cascading sensor system into account, as it is an interesting use case for the use of the SensorThings API.

The administrator of the web-based service - the 3D GeoPortal - has to prepare the 3D model for web-based 3D visualization. In addition, the sensors have to be registered and integrated into the 3D model to ensure that the sensor readings are visualized in the correct 3D space. The occupancy is measured not at a 3D location, but in a space such as a room. The observed space in represented with a 3D geometry in IndoorGML. The sensor and the observed space have to be linked in this use case.

Air quality index data getting from the OGC SensorThings API, which include all components which will affect AQI like Carbon Monoxide (CO), Sulphur Dioxide (SO₂), Ozone (O₃) …​ etc, along with location details (latitude, longitude, height). In the same way occupancy data also works.

IndoorGML was converted into tileset data which is supported by FME (feature manipulation engine) or Cesium Command-line interface (CLI). In IndoorGML, all layers were separated depending upon data, like roof surface, floor surfaces, wall surface …etc. Then on and off layers also possible. CityGML was also converted into tileset data through FME, and visualized on a portal as well, with minor adjustments like terrain, offset.

In the portal tilesets of IndoorGML and CityGML were visualized. On the top of tileset data serialized as CityGML AQI data, other data obtained from the SensorThings API was displayed, with devices color-coded based upon thresholds of individual parameters and AQI as well. Inside the tileset serialized as IndoorGML, occupancy sensor data was displayed. On and off control of IndoorGML layers was controlled through the portal.

The steps illustrated in Figure 16 are explained as follows and indicated through parenthesis. The IndoorGML model was parsed for the geometry and the attribute of the CellSpace of IndoorGML was saved at the local(1). After parsing, the indoor geometry was visualized using Gaia3D – a globe platform based on 3D WebGL (2). With parsed data, we calculate the middle point of the CellSpace geometry to use the point as the position for visualizing indoor occupancy data(5) later.

A query was sent to the SensorThings API with the following API path (3) to get the location of the sensors, the phenomenon time of the observation and the result value of the observation to track the progress history of the sensor’s value.

Per every 10 seconds the query was sent to refresh the data of the sensor. With the location data and the result value of sensor’s observation, the sensor’s position and value on the globe was visualized (4). The User can then review the history of the sensor data from the graph.

At (1) is IndoorGML’s data was parsed into two parts: the geometry and the data of CellSpace. Through GML ID of CellSpace, the Indoor occupancy data was requested from WPS server (5). Indoor occupancy data is then presented at the position that was calculated at (1). Pre-processed data in JSON was used for visualization(6) and statistical analysis. The workflow is similar to that of sensor data visualization.

At the 3D GeoPortal, the geometry of the IndoorGML including the network and the location of the occupancy is visualized. For intuitive sight, each room of the building is colored to represent the value of the occupancy. Visualization of the occupancy value history graph is supported on the portal.

The position of the Property Estimator API within the architecture of the pilot is potentially a complex one. The API could be designed to support a range of implementations and use cases to supplement the SensorThings API readings.

For the purposes of this Pilot, the Property Estimator API can be considered an "aggregation model" sensor to support four identified use cases. The functionality of these four use cases ranges from standard request-response client-server interactions to purely server-to-server interactions. These are listed below from simple to complex.

The technical implementation for this pilot covered the first two of these approaches, with the technical architecture in place to satisfy the third approach. In order to do so the implementation was flexible, light weight and only focused on the necessities. This prioritized the end utilization rather than the need to produce a full production ready implementation. Hopefully given the results of this implementation a number of decisions can then be made regarding which is the most appropriate use case(s) to support going forward.

The Property Estimator API component can be broken down into 3 parts:

The API structure took inspiration from the Routing Pilot work conducted in 2019, which extended the draft OGC API – Processes standard. This is the most recent implementation of an OpenAPI inspired processing service, and is the closest the pilot participants had to a proto-standard processing service, along-side the draft OGC API - Common specification and OGC API - Features standard. That said, the scope of this pilot may not allow for a full HATEOAS (Hypermedia as the Engine of Application State) implementation given the flexibility required to support all of the other components. The API components exposed to the client should be sufficient to support the first two use cases. From the client perspective this is fairly straight forward. Only a few endpoints need be exposed to allow for the client to request an aggregation. This satisfied the client aspects of approaches 1 and 2, and the same endpoints could be used for approach 3.

The request JSON payload structure depended on the type of estimation required, either air quality or occupancy. The proposed example structure for air quality is below, for location estimate.

The proposed example structure for air quality is below, for GMLID Feature estimate.

The proposed example structure for occupancy is below.

Two methods for property estimation were required:

(1) Simple property estimation: This provided an estimation for a single point given the input parameters in the request payload. This single point was either chosen by the user or derived from the users chosen GMLID. The air quality estimation used the centroid x,y,z, the radius from centroid, start and stop times and a sensor type defining the particulate. This information was then used to take an average through time, retrieving information from all of the sensors that fall within the chosen 3D spherical radius. For the occupancy estimation all of the ID elements within the chosen GML ID element were checked to see which elements have associated sensors. These sensors were then used to take an average number of people in the chosen element. This satisfied the simple asynchronous processing component.

(2) Persisted property estimation: This estimation created a persisted spatiotemporal model. The model was represented by raster data sets, each representing an area and height range (or bin) for a specific day. In order to create these raster datasets the persisted model accepted a configuration POSTed to the 'administer' endpoint of the API. This configuration provides information required by the model, including the chosen STAPI from which to build the model, the sensor type to base the model on and the minimum and maximum bounding box coordinates for the model extent. Once this configuration is received, the process checked that there were sensors for the chosen sensor type, on the chosen STAPI in the chosen area. If this is confirmed an MQTT client connection was made between the Processes API and the chosen SensorThings API, to observe all FeatureOfInterest updates. When an observation is received the process checked that the response matched the configuration criteria and if so added the data to the appropriate point dataset. Every time a data set was updated and had more than 3 point values, the IDW Interpolation was run to create the interpolated raster for that specific point dataset. Once the model had been running for a while successfully retrieving regular MQTT updates from the chosen STAPI, a catalog of raster datasets was generated. When an estimate request is made by the user specifying the "aggregation type" as "persisted" the user receives a link to a resource on the estimate endpoint. This JSON resource contains a list of links to the raster data sets that satisfy their estimate request. The user can then choose to download all or a subset of these raster data sets to display or interrogate on the client side. This satisfied the persisted model processing component and such a model could be drawn upon by any of the above approaches. Due to the scope of this pilot, this estimation process was constrained to just air quality.

These estimation processes relied on the SensorThings API storing a GML ID within either the FeatureOfInterest elements or Thing elements to associate sensors with parts of buildings. The result of the estimation request was stored as a resource at the estimation endpoint of the API, with the client being given the location of this resource in the 'Location' header of the POST response.

The implementation of the above approach is outlined in section 7.