Enriching Authoritative Environmental Observations: Findings from AirSensEUR

Abstract

-This short paper1 provides an overview of our activities in establishing the AirSensEUR open software/hardware multi-sensor platform for measuring ambient air quality. Particular emphasis is put on the experiences and lessons learned in the implementation of our platform from the point of view of interoperable data management. Following an overview of the context, architecture and results, we focus on the challenges we came across in implementing AirSensEUR, in particular related to (i) existing standards, (ii) open source software, and (iii) clients which are able to consume our observation data. The conclusion provides information regarding our future research direction.

-

I. INTRODUCTION

The Internet of Things (IoT) is changing the traditional ways in which geospatial data are collected [ 1 ]. For environmental research, this is similar to the ’revolution’ caused by the use of satellite imagery during the 1970s [ 2 ].With the increased availability of technology which is able to collect observation data and the establishment of Do-It-Yourself (DIY) communities the deployment of sensors is easier and faster than ever. At the same time the sole fact that a growing number of sensors broadcast observation data does not inherently mean that such data becomes discoverable, accessible and usable. The described growth of the number of devices is associated with a rapidly increasing number of vendors, heterogeneous platforms, architectures and file formats. Furthermore, Citizen Science and DIY science measure (often local) environments, but the results do not fit the purpose of official environmental monitoring - primarily due to issues of accuracy/precision and disconnectivity. That is why, from the perspective of data management, there are many challenges, despite the fact that the field of environmental sensing is not new to the research agenda. In other words we still miss interoperability of methods and tools.

Within this context, our manuscript summarises the findings associated with the work on AirSensEUR [ 3 ] as an interoperable platform for the observation of ambient air quality.

1The views expressed are purely those of the authors and may not in any circumstances be regarded as stating an official position of the European Commission.

Following an introduction, section two provides an overview of the architecture of the platform and the results, presented from the data-management point of view. The third section emphasises on the pending challenges. It is followed by a conclusion.

II. AIRSENSEUR - AN OVERVIEW

A. Architecture

AirSensEUR is designed as an open platform based on several pillars ensuring that individual sensor nodes are open (both in terms of hardware and software) and interoperable by design. The high level objective that determines the bounding conditions of AirSensEUR, is to design and build a platform which is simultaneously: capable under certain conditions of producing indicative observation data that meet the legal requirements of the EU Air Quality Directive [ 4 ], and implements a download service, as required by the EU INSPIRE Directive [ 5 ].

From a technical point of view the platform consists of a bundle of software and hardware (Figure 1), configured to work together in a synchronized manner. The hardware (Subsystem A) consists of a sensor shield, development within the AirSensEUR project (A.1 on Figure 1), and host - Arietta [ 6 ]. The shield is used to connect four amperometric sensors and an ancillary board, capable of measuring temperature, humidity and pressure, have been developed for AirSensEUR, while the host is used to manage, store and push data via GPRS or WiFi. The senor shield can host over 500 different sensors, produced by different providers. The software components being used are depicted within Figure 1 and consist of a backend (Subsystem B), and client applications (Subsystem C). Those are described in detail, inline with the scope of the conference. Further information about the hardware is provided by Gerboles et. al. [ 7 ], [ 8 ], as well as by Kotsev et. al. [ 9 ].

The components that are chained together in AirSensEUR, in accordance with [ 9 ] are briefly described below. Java apps manage data from the shield and the onboard GPS. Together with the timestamp, air quality observation data are added to a local SQLite database (A2 in Figure 1), stored on the secure digital (SD) card of the hosting hardware platform. Data from the local database are through a consecutive step encoded as JavaScript Object Notation (JSON) and send via GSM/GPRS to an external server. A Sensor Observation Service with a transactional mode (SOS-T) enabled is used to receive the data. This functionality on the server end is provided by the JSON binding of the 52 North SOS implementation. The use of SOS-T for exchange of data from the sensor host to the server provides us with significant advantages over a direct web access to the AirSensEUR database. Those in accordance with [ 9 ] include (i) high level of security (the sensor host does not provide credentials for access to the database, and InsertObservation requests are limited to a predefined number of IP addresses), as well as (ii) independence from the database schema. In addition, the JSON syntax of the request is minimalistic in terms of size, and is well suited for transmission of big volumes of observation data. We also use the SOS interface for the implementation of an INSPIRE download service [ 5 ], i.e. for exposing observation data in an interoperable manner. It can thus be retrieved and directly re-used by various clients without the necessity to adopt own access protocol(s) and/or invent data structures on the consumer-side. Such functionality is, for example, fundamental in order to integrate citizen observations with institutional measures on-the-fly.

B. Results

A prototype of AirSensEUR was deployed near a working official/authoritative air quality station (Figure 2), assuming that both are sampling data from the same bubble of air with the overall idea to be able to estimate the quality of observations from the platform before and after calibration. We successfully used the implementation and transfer over 7 million observations using the transactional SOS through the JSON binding. The technological lessons learned and issues that we discovered are further discussed in Section 3.

From the perspective of citizen science the benefits from our developments are twofold. On the one hand it provides a solution for the combined handling of citizens contributions and public sector information so that administrations at different geographic scales can start investigating potential implications and enhancements of traditional environmental monitoring. AirSensEUR thus feeds debates and reflections in the public sector. On the other hand, citizen scientists and DIY scientists might assume that the data that they collect can contest officially published information. It might lead to a loss of trust in projects about public participation in scientific research if they found out that this assumption does not hold. The platform provides one option to resolve these issues. It has the ambition to provide a balance between accurate measurements and the costs of the solution that would fit the purpose of European-level quality standards.

III. CHALLENGES

The implementation of AirSensEUR shows that OGC’s Sensor Web Enablement (SWE) suite of standards, and the 52 North implementation of SOS in particular, are mature enough and capable of handling huge quantities of observation data. As discussed above, in a setting where our platform was deployed as a static sensor node we successfully used the implementation in order to transfer huge volumes of observations (using the transactional SOS through the JSON binding). However, within this process we identified several challenges that, if addressed, would enable a far more flexible and applicable software stack.

Due to the scope of the conference we focus on the technical challenges that we faced in the particular case of implementing the platform. The following section gives an overview of our findings with respect to (i) standardization, and the SWE suite of standards in particular, (ii) the 52 North SOS bundle of products, and (iii) the availability and maturity of clients. Organizational and possibly also legal challenges will be discussed with other audiences.

A. Sensor Web Enablement

1) JSON encoding of O&M data: We see the establishment of a standardised JSON Implementation of OGCs Observations and Measurements (O&M) specification as a critically important step which would ensure that the SWE stack of standards is brought one step closer to the IoT, and better address the demand for standards which are capable of handling heavy loads of spatio-temporal data on/from constrained devices. The elaboration of an OGC Discussion paper proposing a ”JSON implementation of the OGC and ISO Observations and Measurements (O&M)” [ 10 ] is a step in the right direction. In the ideal situation this development should quickly lead to the establishment of a standard, taking into consideration recent work on SensorThings [ 11 ] and the 52 North REST API [ 12 ].

2) Subscriptions: As already discussed, the implementation of an OGC SOS allowed us to successfully (i) exchange data between sensor nodes and our SOS, (ii) serve our observation data in an interoperable manner. We are currently working on calibration in ”R” through the SOS4R plugin [ 13 ] which works very well with the current 52 North technological stack.

We however also envisage a scenario where, apart from consuming data in a synchronous manner, we would be able to handle subscriptions to our sensor infrastructure, e.g. to issue alerts if the thresholds for pollutants, e.g. as described within the EU Air Quality Directive [ 4 ] are reached. We consider that such functionality would be beneficial, particularly if enabling users to create apps which make sense of observation data through social media, smartphones and other channels. Following an initial investigation of the Sensor Event Service (SES) implementations we were not able to come across a working solution. SES is therefore, for pragmatic reasons, not a planned feature for the AirSensEUR platform.

B. 52 North SOS implementation

1) Moving sensor nodes: The version of 52 North SOS

which we used (version 4.3) supports the OM Sampling Geometry as defined in ISO19156 [ 14 ]. Through that we are able to deploy moving sensors. It is however still not possible to consume such data through the 52 North REST API, or take advantage of the existing clients. Furthermore, a smart way of distinguishing between actual movement in space, and differences in coordinates coming from the onboard GPS has to be identified. For example the point cloud shown in Figure 3 represents a time series of AirSensEUR observations where the sensor is stationary, but the location data which is encoded and sent to the server through SOS-T is different for each observation. The concept of tracks, implemented for the EnviroCar API [ 15 ], and support to specialised observation types as defined in INSPIRE [ 5 ] would be particularly useful. Still, quantification of the spatial accuracy and the quality of observation data for moving sensor nodes, together with their effect on different air-quality related use cases need to be further investigated.

2) Semantic issues: We used 52 North SOS, REST API

and restful-timeseries-proxy. The former helped us to meet INSPIRE obligations, while the rest we used to process data in a faster and more efficient way (when compared to using XML). That is why we see this bundle of products fit for purpose and well positioned in order to enable access to observation data in a cross-domain setting. The 52 North REST API however introduces terminology that is different from SWE (station, timeseries, etc.). We would welcome alignment of the API with OGC terminology, which would avoid possible confusion, and the unnecessary need of one to map between the terminology defined in SWE and the nonstandard REST API. Furthermore, this would very likely help alignment of the latter to OGCs standards as described in Section 3.1.

3) Cross-implementation interoperability: In our work on

AirSensEUR we assume that through adopting the standards as describe above, we ensure interoperability between different vendors, domains and across borders, in line with initiatives such as INSPIRE [ 5 ]. It is however still to be proven whether several implementations of the same OGC standard can easily exchange data among themselves (e.g. an istSOS client [ 16 ] to consume data from a 52 North SOS, or vice versa). This would definitely create a strong case in support of data interoperability and standardisation, particularly if built around reuseable demonstrators.

C. Clients

Geospatial technology which is dealing with static geospatial data (features) is very well established. Spatio-temporal data however creates new challenges, where for example a limited number of sensor nodes might be creating terabytes of observation data (with profiles or trajectories). From that perspective, we consider that the number of clients in the geospatial domain, which are able to consume interoperable observation data through the web - even if growing during the past several years - is still limited. Some improvements, such as the QGIS ’Time manager’ [ 17 ] and the ESRI ArcGIS for Desktop support for temporal data [ 18 ] exist. However, those require either offline data, or direct access to a remote database, thus do not take advantage of interoperable services such as SOS and the 52 North REST API. In 2015 and 2016 we tested some of the available SOS plugins for Quantum GIS, but were not able to load our observation data. That is why we consider that those plugins are not mature enough to act as a real client able to take advantage of a service oriented architecture. Finally, regarding the utilisation of data from AirSensEUR we consider that mainstream web and/or mobile technology would benefit from the data collected and served by the platform. This approach, that goes beyond traditional GIS, would provide an opportunity to considerably broaden the potential spectrum of value-added application sitting on top of AirSensEUR.

IV. CONCLUSIONS

Following the successful deployment of AirSensEUR, we consider that it provides an opportunity for DIY and Citizen Scientists to measure the quality of ambient air. It adds to the set of solutions that address a different trade-off between costs and quality of the measurement results. With a cost of less than 1 000 Euro, among others depending on the selection of sensors, the free and open hardware, platform and quality assurance methods offer not only quality of observation data better than other Citizen Science projects, but also provides out-of-the-box interoperability with INSPIRE. Furthermore, the platform comes with a web and mobile client which provide users with an easy to use interface for interacting with data [ 9 ].

Apart from the obvious specificities of the underlying hardware, the data management solution is designed in a way that it could be equally applied to other topic areas such as oceanography, hydrology, agriculture, etc.

Based on this solid ground work, we are now addressing the technical and semantic challenges as introduced in this paper. Organizational and legal investigations are foreseen in parallel. The envisaged way ahead includes activities which would investigate (i) calibration, (ii) individual’s exposure to pollution, (iii) web-based infrastructural and data management support to other topic areas in order to investigate generalisability of the solution, and (iv) promoting the uptake of AirSensEUR in local and regional contexts.

References

[1] M. Swan , “ Sensor mania! The Internet of Things, Wearable Computing, Objective Metrics, and the Quantified Self 2.0,” Journal of Sensor and Actuator Networks , vol. 1 , no. 3 , p. 217 , 2012 . [Online]. Available: http://www.mdpi.com/2224-2708/1/3/217

[2] J. K. Hart and K. Martinez , “ Environmental Sensor Networks: A revolution in the earth system science?” Earth-Science Reviews , vol. 78 , no. 3 , pp. 177 - 191 , 2006 .

[3] “AirSensEur website,” http://www.airsenseur.org, accessed: 2016 -07-25.

[4] “Directive 2008 / 50/EC of the European Parliament and of the Council of 21 may 2008 on ambient air quality and cleaner air for Europe .”

[5] “Directive 2007 / 2/EC of the European Parliament and of the Council of 14 March 2007 establishing an Infrastructure for Spatial Information in the European Community (INSPIRE) .”

[6] “ Arietta G25 - Low cost Linux embedded module ,” http://www. acmesystems.it/arietta, accessed: 2016 -05-02.

[7] M. Gerboles , L. Spinelle , A. Kotsev , and M. Signorini , “ Airsenseur: An Open-Designed Multi-Sensor Platform for Air Quality Monitoring ,” in Proceedings, Fourth Scientific Meeting EuNetAir, Linkoping, Sweden, June 3 - 5, 2015 , published online at AMA-Science.org, DOI by AMA Science, Doi: http://dx.doi.org/10.5162/4EuNetAir2015/03, 2015 .

[8] M. Gerboles , Spinelle, and M. Signorini , “ Airsenseur: an open data/software/hardware multi-sensor platform for air quality monitoring . Part A: Sensor Shield ,” 2015 , Luxembourg: Publications Office of the European Union , 2015 , EUR 27469 EN, EUR Scientific and Technical Research series ISSN 1831 - 9424 ( online ), ISBN 978-92-79-51896-6 ( PDF ), doi: http://dx.doi.org/10.5162/4EuNetAir2015/03.

[9] A. Kotsev , S. Schade , M. Craglia , M. Gerboles , L. Spinelle , and M. Signorini , “ Next Generation Air Quality Platform: Openness and Interoperability for the Internet of Things,” Sensors , vol. 16 , no. 3 , p. 403 , 2016 .

[10] “ Discussion paper . OGC Observations and Measurements: JSON implementation .” https://portal.opengeospatial.org/files/64910, accessed: 2016 -04-11.

[11] “SensorThings API OGC candidate standard ,” http://ogc-iot.github.io/ ogc-iot-api, accessed: 2016 -05-02.

[12] “52North RESTful API ,” https://wiki.52north.org/bin/view/SensorWeb/ SensorWebClientRESTInterface, accessed: 2016 -05-02.

[13] “sensorweb4R GitHub repository ,” https://github.com/52North/ sensorweb4R, accessed: 2016 -04-10.

[14] “ISO 19156:2011 Geographic Information: Observations and Measurements,” http://www.iso.org/iso/catalogue detail. htm?csnumber=32574 , accessed: 2016 -04-10.

[15] “Envirocar project website,” https://envirocar.org/, accessed: 2016 -05-02.

[16] “istSOS OGC SOS implementation ,” http://istsos.org, accessed: 2016 - 05-01.

[17] “QuantumGIS time manager plugin ,” https://plugins.qgis.org/plugins/ timemanager, accessed: 2016 -05-01.

[18] “ESRI support for temporal data ,” http://pro.arcgis.com/en/pro-app/help/ mapping/time/temporal-data.htm, accessed: 2016 -05-02.