Enriching Authoritative Environmental Observations: Findings from AirSensEUR Alexander Kotsev, Michel Gerboles Marco Signorini Sven Schade and Laurent Spinelle Liberaintentio S.r.l and Massimo Craglia Air and Climate Unit Varese, Italy 21100 Digital Economy Unit Joint Research Centre Email: marco.signorini@liberaintentio.com Joint Research Centre European Commission European Commission Ispra, Italy 21027 Ispra, Italy 21027 Telephone: +39 0332 78 5652 Telephone: +39 0332 78 9069 Email: michel.gerboles@jrc.ec.europa.eu Email: alexander.kotsev@jrc.ec.europa.eu Abstract—This short paper1 provides an overview of our Following an introduction, section two provides an overview activities in establishing the AirSensEUR open software/hardware of the architecture of the platform and the results, presented multi-sensor platform for measuring ambient air quality. Partic- from the data-management point of view. The third section ular emphasis is put on the experiences and lessons learned in the implementation of our platform from the point of view of emphasises on the pending challenges. It is followed by a interoperable data management. Following an overview of the conclusion. context, architecture and results, we focus on the challenges we II. A IR S ENS EUR - AN OVERVIEW came across in implementing AirSensEUR, in particular related to (i) existing standards, (ii) open source software, and (iii) clients A. Architecture which are able to consume our observation data. The conclusion AirSensEUR is designed as an open platform based on provides information regarding our future research direction. several pillars ensuring that individual sensor nodes are open I. I NTRODUCTION (both in terms of hardware and software) and interoperable by The Internet of Things (IoT) is changing the traditional ways design. The high level objective that determines the bounding in which geospatial data are collected [1]. For environmental conditions of AirSensEUR, is to design and build a platform research, this is similar to the ’revolution’ caused by the use which is simultaneously: of satellite imagery during the 1970s [2].With the increased • capable under certain conditions of producing indicative availability of technology which is able to collect observation observation data that meet the legal requirements of the data and the establishment of Do-It-Yourself (DIY) communi- EU Air Quality Directive [4], and ties the deployment of sensors is easier and faster than ever. • implements a download service, as required by the EU At the same time the sole fact that a growing number of INSPIRE Directive [5]. sensors broadcast observation data does not inherently mean From a technical point of view the platform consists of that such data becomes discoverable, accessible and usable. a bundle of software and hardware (Figure 1), configured The described growth of the number of devices is associated to work together in a synchronized manner. The hardware with a rapidly increasing number of vendors, heterogeneous (Subsystem A) consists of a sensor shield, development within platforms, architectures and file formats. Furthermore, Citizen the AirSensEUR project (A.1 on Figure 1), and host - Arietta Science and DIY science measure (often local) environments, [6]. The shield is used to connect four amperometric sensors but the results do not fit the purpose of official environmental and an ancillary board, capable of measuring temperature, monitoring - primarily due to issues of accuracy/precision humidity and pressure, have been developed for AirSensEUR, and disconnectivity. That is why, from the perspective of while the host is used to manage, store and push data via GPRS data management, there are many challenges, despite the fact or WiFi. The senor shield can host over 500 different sensors, that the field of environmental sensing is not new to the produced by different providers. The software components research agenda. In other words we still miss interoperability being used are depicted within Figure 1 and consist of a of methods and tools. backend (Subsystem B), and client applications (Subsystem Within this context, our manuscript summarises the findings C). Those are described in detail, inline with the scope of associated with the work on AirSensEUR [3] as an inter- the conference. Further information about the hardware is operable platform for the observation of ambient air quality. provided by Gerboles et. al. [7], [8], as well as by Kotsev 1 The views expressed are purely those of the authors and may not in any et. al. [9]. circumstances be regarded as stating an official position of the European The components that are chained together in AirSensEUR, Commission. in accordance with [9] are briefly described below. Java apps Fig. 1. Architecture of AirSensEUR. manage data from the shield and the onboard GPS. Together big volumes of observation data. We also use the SOS interface with the timestamp, air quality observation data are added to for the implementation of an INSPIRE download service [5], a local SQLite database (A2 in Figure 1), stored on the secure i.e. for exposing observation data in an interoperable manner. digital (SD) card of the hosting hardware platform. Data from It can thus be retrieved and directly re-used by various clients the local database are through a consecutive step encoded as without the necessity to adopt own access protocol(s) and/or JavaScript Object Notation (JSON) and send via GSM/GPRS invent data structures on the consumer-side. Such functionality to an external server. A Sensor Observation Service with a is, for example, fundamental in order to integrate citizen transactional mode (SOS-T) enabled is used to receive the observations with institutional measures on-the-fly. data. This functionality on the server end is provided by the JSON binding of the 52 ◦ North SOS implementation. The use B. Results of SOS-T for exchange of data from the sensor host to the server provides us with significant advantages over a direct A prototype of AirSensEUR was deployed near a working web access to the AirSensEUR database. Those in accordance official/authoritative air quality station (Figure 2), assuming with [9] include (i) high level of security (the sensor host that both are sampling data from the same bubble of air does not provide credentials for access to the database, and with the overall idea to be able to estimate the quality of InsertObservation requests are limited to a predefined number observations from the platform before and after calibration. of IP addresses), as well as (ii) independence from the database We successfully used the implementation and transfer over 7 schema. In addition, the JSON syntax of the request is mini- million observations using the transactional SOS through the malistic in terms of size, and is well suited for transmission of JSON binding. The technological lessons learned and issues that we discovered are further discussed in Section 3. Fig. 2. AirSensEUR deployed at JRC, Ispra, Italy. 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 impor- tant 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 From the perspective of citizen science the benefits from between sensor nodes and our SOS, (ii) serve our observation our developments are twofold. On the one hand it provides data in an interoperable manner. We are currently working on a solution for the combined handling of citizens contribu- calibration in ”R” through the SOS4R plugin [13] which works tions and public sector information so that administrations very well with the current 52 ◦ North technological stack. at different geographic scales can start investigating potential We however also envisage a scenario where, apart from implications and enhancements of traditional environmental consuming data in a synchronous manner, we would be able to monitoring. AirSensEUR thus feeds debates and reflections handle subscriptions to our sensor infrastructure, e.g. to issue in the public sector. On the other hand, citizen scientists and alerts if the thresholds for pollutants, e.g. as described within DIY scientists might assume that the data that they collect the EU Air Quality Directive [4] are reached. We consider can contest officially published information. It might lead to a that such functionality would be beneficial, particularly if loss of trust in projects about public participation in scientific enabling users to create apps which make sense of observation research if they found out that this assumption does not hold. data through social media, smartphones and other channels. The platform provides one option to resolve these issues. Following an initial investigation of the Sensor Event Service It has the ambition to provide a balance between accurate (SES) implementations we were not able to come across a measurements and the costs of the solution that would fit the working solution. SES is therefore, for pragmatic reasons, not purpose of European-level quality standards. a planned feature for the AirSensEUR platform. B. 52 ◦ North SOS implementation III. C HALLENGES 1) Moving sensor nodes: The version of 52 ◦ North SOS The implementation of AirSensEUR shows that OGC’s which we used (version 4.3) supports the OM Sampling Sensor Web Enablement (SWE) suite of standards, and the Geometry as defined in ISO19156 [14]. Through that we are 52 ◦ North implementation of SOS in particular, are mature able to deploy moving sensors. It is however still not possible enough and capable of handling huge quantities of observation to consume such data through the 52 ◦ North REST API, or data. As discussed above, in a setting where our platform take advantage of the existing clients. Furthermore, a smart was deployed as a static sensor node we successfully used way of distinguishing between actual movement in space, the implementation in order to transfer huge volumes of and differences in coordinates coming from the onboard GPS observations (using the transactional SOS through the JSON has to be identified. For example the point cloud shown in binding). However, within this process we identified several Figure 3 represents a time series of AirSensEUR observations challenges that, if addressed, would enable a far more flexible where the sensor is stationary, but the location data which is and applicable software stack. encoded and sent to the server through SOS-T is different for Due to the scope of the conference we focus on the technical each observation. The concept of tracks, implemented for the challenges that we faced in the particular case of implementing EnviroCar API [15], and support to specialised observation the platform. The following section gives an overview of our types as defined in INSPIRE [5] would be particularly useful. findings with respect to (i) standardization, and the SWE suite Still, quantification of the spatial accuracy and the quality of standards in particular, (ii) the 52 ◦ North SOS bundle of of observation data for moving sensor nodes, together with products, and (iii) the availability and maturity of clients. their effect on different air-quality related use cases need to Organizational and possibly also legal challenges will be be further investigated. discussed with other audiences. Fig. 3. Observation data with ’fake’ movement 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. C ONCLUSIONS Following the successful deployment of AirSensEUR, we consider that it provides an opportunity for DIY and Citizen 2) Semantic issues: We used 52 ◦ North SOS, REST API Scientists to measure the quality of ambient air. It adds to and restful-timeseries-proxy. The former helped us to meet the set of solutions that address a different trade-off between INSPIRE obligations, while the rest we used to process data costs and quality of the measurement results. With a cost of in a faster and more efficient way (when compared to using less than 1 000 Euro, among others depending on the selection XML). That is why we see this bundle of products fit for of sensors, the free and open hardware, platform and quality purpose and well positioned in order to enable access to assurance methods offer not only quality of observation data observation data in a cross-domain setting. The 52 ◦ North better than other Citizen Science projects, but also provides REST API however introduces terminology that is different out-of-the-box interoperability with INSPIRE. Furthermore, from SWE (station, timeseries, etc.). We would welcome the platform comes with a web and mobile client which alignment of the API with OGC terminology, which would provide users with an easy to use interface for interacting with avoid possible confusion, and the unnecessary need of one to data [9]. map between the terminology defined in SWE and the non- Apart from the obvious specificities of the underlying standard REST API. Furthermore, this would very likely help hardware, the data management solution is designed in a way alignment of the latter to OGCs standards as described in that it could be equally applied to other topic areas such as Section 3.1. oceanography, hydrology, agriculture, etc. 3) Cross-implementation interoperability: In our work on Based on this solid ground work, we are now addressing the AirSensEUR we assume that through adopting the standards technical and semantic challenges as introduced in this paper. as describe above, we ensure interoperability between different Organizational and legal investigations are foreseen in parallel. vendors, domains and across borders, in line with initiatives The envisaged way ahead includes activities which would in- such as INSPIRE [5]. It is however still to be proven whether vestigate (i) calibration, (ii) individual’s exposure to pollution, several implementations of the same OGC standard can easily (iii) web-based infrastructural and data management support exchange data among themselves (e.g. an istSOS client [16] to other topic areas in order to investigate generalisability of to consume data from a 52 ◦ North SOS, or vice versa). the solution, and (iv) promoting the uptake of AirSensEUR in This would definitely create a strong case in support of data local and regional contexts. interoperability and standardisation, particularly if built around reuseable demonstrators. R EFERENCES C. Clients [1] M. Swan, “Sensor mania! The Internet of Things, Wearable Computing, Objective Metrics, and the Quantified Self 2.0,” Journal of Sensor and Geospatial technology which is dealing with static geospa- Actuator Networks, vol. 1, no. 3, p. 217, 2012. [Online]. Available: tial data (features) is very well established. Spatio-temporal http://www.mdpi.com/2224-2708/1/3/217 [2] J. K. Hart and K. Martinez, “Environmental Sensor Networks: A data however creates new challenges, where for example a revolution in the earth system science?” Earth-Science Reviews, vol. 78, limited number of sensor nodes might be creating terabytes no. 3, pp. 177–191, 2006. of observation data (with profiles or trajectories). From that [3] “AirSensEur website,” http://www.airsenseur.org, accessed: 2016-07-25. [4] “Directive 2008/50/EC of the European Parliament and of the Council perspective, we consider that the number of clients in the of 21 may 2008 on ambient air quality and cleaner air for Europe.” geospatial domain, which are able to consume interoperable [5] “Directive 2007/2/EC of the European Parliament and of the Council of observation data through the web - even if growing during 14 March 2007 establishing an Infrastructure for Spatial Information in the European Community (INSPIRE).” the past several years - is still limited. Some improvements, [6] “Arietta G25 - Low cost Linux embedded module,” http://www. such as the QGIS ’Time manager’ [17] and the ESRI ArcGIS 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 Measure- ments,” 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.