Bernd Resch, Rex Britter, Christine Outram, Xiaoji Chen and Carlo Ratti *Massachusetts Institute of Technology, USA*

### **1. Introduction**

512 Environmental Monitoring

Wan, Chieh-Yih; Campbell, A.T. & Krishnamurthy, L. (2002). PSFQ: A Reliable Transport Protocol for Wireless Sensor Networks, *ACM WSNA'02*, Atlanta, Georgia, USA Stann, F. & Heidemann, J. (2003). RMST: Reliable Data Transport in Sensor Networks, *IEEE*

Intanagonwiwat, C.; Govindan, R.; Estrin, D. & Heidemann, J. (2003). Directed Diffusion for

Xu, N.; Rangwala, S.; Chintalapudi, K.K.; Ganesan, D.; Broad, A.; Govindan, R. & Estrin, D.

Polastre, J.; Hill, J. & Culler, D. (2004). Versatile Low Power Media Access for Wireless

Tolle, G.; Polastre, J.; Szewczyk, R.; Culler, D.; Turner, N.; Tu, K.; Burgess, S.; Dawson, T.;

Shnayder, V.; Hempstead, M.; Chen, Bor-rong; Allen G.W.; & Welsh, M. (2004). Simulating

Lin, S.; Zhang, J.; Zhou, G.; Gu, L.; He, T. & Stankovic, J.A. (2006). ATPC: Adaptive

Stoyanova, T.; Kerasiotis, F.; Prayati, A. & Papadopoulos, G. (2007). Evaluation of Impact

Srinivasan, K.; Dutta, P.; Tavakoli, A. & Levis, P. (2006). Understanding the Causes of Packet

USA

February 2003

Baltimore, Maryland, USA

*SenSys'05*, November 2005

Baltimore, Maryland, USA

*MobiWac'07*, October 2007

*SING-06-00*, Stanford University

Colorado, USA

Sensor Networks, *SenSys'04*, November 2004

*International Workshop on Sensor Net Protocols and Applications (SNPA)*, Anchorage,

Wireless Sensor Networking, *IEEE/ACM Transactions on Networking*, Vol.11, No.1,

(2004). A Wireless Sensor Network for Structural Monitoring, *ACM SenSys'04*,

Buonadonna, P.; Gay, D. & Hong, W. (2005). A Macroscope in the Redwoods,

the Power Consumption of Large-Scale Sensor Network Applications, *SenSys'04*,

Transmission Power Control for Wireless Sensor Networks, *SenSys'06*, Boulder,

Factors on RSS Accuracy for Localization and Tracking Applications, *In*

Delivery Success and Failure in Dense Wireless Sensor Networks, *Technical Report*

*'In the next century, planet earth will don an electronic skin. It will use the Internet as a scaffold to support and transmit its sensations. This skin is already being stitched together. It consists of millions of embedded electronic measuring devices: thermostats, pressure gauges, pollution detectors, cameras, microphones, glucose sensors, EKGs, electroencephalographs. These will probe and monitor cities and endangered species, the atmosphere, our ships, highways and fleets of trucks, our conversations, our bodies – even our dreams.' (Gross, 1999)*

Following this comprehensive vision by Neil Gross (1999), it can be assumed that sensor network deployments will increase dramatically within the coming years, as pervasive sensing has recently become feasible and affordable. This enriches knowledge about our environment with previously uncharted real-time information layers.

However, leveraging sensor data in an ad-hoc fashion is not trivial as ubiquitous geo-sensor web applications comprise numerous technologies, such as sensors, communications, massive data manipulation and analysis, data fusion with mathematical modelling, the production of outputs on a variety of scales, the provision of information as both hard data and user-sensitive visualisation, together with appropriate delivery structures. Apart from this, requirements for geo-sensor webs are highly heterogeneous depending on the functional context.

This chapter addresses the nature of this supply chain; one overarching aspect is that all elements are currently undergoing both great performance enhancement combined with drastic price reduction (Paulsen & Riegger, 2006). This has led to the deployment of a number of geo-sensor networks. On the positive side the growing establishment of such networks will further decrease prices and improve component performance. This will particularly be so if the environmental regulatory structure moves from a mathematical modelling base to a more pervasive monitoring structure.

Of specific interest in this chapter is our concern that most sensor networks are being built up in monolithic and specific application-centred measurement systems. In consequence, there is a clear gap between sensor network research and mostly very heterogeneous end user requirements. Sensor network research is often dedicated to a long-term vision, which tells a compelling story about potential applications. On the contrary, the actual implementation is mostly not more than a very limited demonstration without taking into account well-known issues such as interoperability, sustainable development, portability or the coupling with established data analysis systems.

Standardised Geo-Sensor Webs for Integrated Urban Air Quality Monitoring 515

web services. The web portal implementation, called SensorMap (Nath et al., 2006), uses the Sensor Description Markup Language (SDML), an application-specific dialect of the OGC

A GIS mash-up for environmental data visualisation is presented in the nowCOAST application (National Oceanic and Atmospheric Administration, 2011). Data from providers such as National Oceanic and Atmospheric Administration (NOAA), U.S. Geological Survey (USGS), Department of Defence (DOD) or local airports, are integrated in a web-based graphical user interface. nowCOAST visualises several types of raw environmental parameters and also offers a 24-hour sea surface temperature interpolation plot with 0.5 degree spatial resolution, produced using a two-dimensional variation interpolation scheme. The system does not make use of open standards for sensor measurements and data

The second related research area is real-time data integration and **sensor fusion** for geospatial analysis systems. Harrie (2004) and Lehto & Sarjakoski (2005) present web services based on the classic request/response model. Although both methods widely use open GIS standards, they are not suitable for the integration of real-time data for large volumes of data. Sarjakoski et al. (2004) establish a real-time spatial data infrastructure (SDI), which performs several application-specific steps, such as coordinate transformation, spatial data generalisation, query processing or map rendering and adaptation. However, the implemented system accounts neither for event-based push mechanisms nor for the

Other approaches for real-time data integration try to tackle the issue from a database perspective. Oracle's system, presented by Rittman (2008), is essentially a middleware between (web) services and a continuously updated database layer. Like Sybase Inc. (2008), the Oracle approach is able to detect database events in order to analyse heterogeneous data sources and trigger actions accordingly. Rahm et al. (2007) present a more dynamic method of data integration and fusion using on-the-fly object matching and metadata repositories to

The third related research area is the development of **an open data integration system architecture** in a non-application specific infrastructure. Srivastava et al. (2006) and Balazinska et al. (2007) present general concepts in a systems architecture and data integration approach but there are no concrete conclusions as to how the final goal of establishing such an infrastructure could be achieved. A more technical approach for ad-hoc sensor networks is described by Riva & Borcea (2007), where the authors discuss challenges to making heterogeneous sensor measurements combinable through the creation of highly flexible middleware components. The method is application-motivated and thus very

The *Common Scents* project aims at developing an interoperable open standards based infrastructure for providing fine-grained air quality data to allow users to assess environmental conditions instantaneously and intuitively. The goal is to provide citizens with unseen up-to-date information layers in order to support their short-term decisions. To achieve this vision, we utilise the CitySense sensor testbed and technologically build our system upon the *Live Geography* approach presented by Resch et al. (2009a). It should be stated that the term 'real-time' in our case is not defined by a pre-set numerical time

SensorML standard.

provision.

integration of sensor data.

create a flexible data integration environment.

detailed as far as specific implementation details are concerned.

**3. Common Scents measurement infrastructure**

Therefore, the availability of geo-sensor networks is growing but still limited. Deborah Estrin pointed out in 2004 that no real sensor network applications exist, apart from shortlived prototypical and very domain-specific demos (Xu, 2004). Recently, some examples of urban geo-sensor networks arose, but the clear social, health and economic benefits have not been demonstrated or described in a manner that would compel this sort of investment in particular for urban environments.

The goal of the Common Scents project is that its highly flexible architecture will bring sensor network applications one step further towards the realisation of the vision of a 'digital skin for planet earth' and have particularly far-reaching impacts on urban monitoring systems through the deployment of ubiquitous and very fine-grained sensor networks. In other words, the broad goal of the project is to develop an overarching infrastructure for various kinds of sensor network applications.

After this brief introduction the chapter provides a discussion of related work. Thereafter, we present the Common Scents approach and implementation for urban monitoring applications. Then, we illustrate some possible application areas for the system. We treat challenges for the deployment of sensor networks that are specific to the city and analyse how such systems can change the city as the functional context by adding new unseen information layers. We conclude with a short summary, discussion and future outlook.

#### **2. Related work**

The first domain of related work is **sensor network** development for environmental monitoring. The Oklahoma City Micronet (University of Oklahoma, 2009) is a network of 40 automated environmental monitoring stations across the Oklahoma City metropolitan area. The network consists of 4 Oklahoma Mesonet stations and 36 sites mounted on traffic signals. At each traffic signal site, atmospheric conditions are measured and transmitted every minute to a central facility. The Oklahoma Climatological Survey receives the observations, verifies the quality of the data and provides the data to Oklahoma City Micronet partners and customers. One major shortcoming of the system is that it is a very specialised implementation not using open standards or aiming at portability. The same applies to CORIE (Center for Coastal and Land-Margin Research, 2009), which is a pilot environmental observation and forecasting system (EOFS) for the Columbia River. It integrates a sensor network, a data management system and advanced numerical models.

Paulsen (2008) presents a sensing infrastructure called PermaGIS that attempts to combine sensor systems and GIS-based visualisation technologies. The sensing devices, which measure rock temperature at ten minute intervals, focuses on optimising resource usage, including data aggregation, power consumption, and communication within the sensor network. In its current implementation, the infrastructure does not account for geospatial standards in sensor observations. The visualisation component uses a number of open standards (OGC WMS, WFS) and open-source services (UMN Map Server, Mapbender).

There are a number of approaches to **leveraging sensor information in GIS** applications. Kansal et al. (2007) present the SenseWeb project, which aims to establish a Wikipedia-like sensor platform. The project seeks to allow users to include their own sensors in the system and thus leverage the 'community effect', building a dense network of sensors by aggregating existing and newly deployed sensors within the SenseWeb application. Although the authors discuss data transformation issues, data fusion, and simple GIS analysis, the system architecture is not based on open (geospatial) standards, only standard

Therefore, the availability of geo-sensor networks is growing but still limited. Deborah Estrin pointed out in 2004 that no real sensor network applications exist, apart from shortlived prototypical and very domain-specific demos (Xu, 2004). Recently, some examples of urban geo-sensor networks arose, but the clear social, health and economic benefits have not been demonstrated or described in a manner that would compel this sort of investment in

The goal of the Common Scents project is that its highly flexible architecture will bring sensor network applications one step further towards the realisation of the vision of a 'digital skin for planet earth' and have particularly far-reaching impacts on urban monitoring systems through the deployment of ubiquitous and very fine-grained sensor networks. In other words, the broad goal of the project is to develop an overarching

After this brief introduction the chapter provides a discussion of related work. Thereafter, we present the Common Scents approach and implementation for urban monitoring applications. Then, we illustrate some possible application areas for the system. We treat challenges for the deployment of sensor networks that are specific to the city and analyse how such systems can change the city as the functional context by adding new unseen information layers. We conclude with a short summary, discussion and future outlook.

The first domain of related work is **sensor network** development for environmental monitoring. The Oklahoma City Micronet (University of Oklahoma, 2009) is a network of 40 automated environmental monitoring stations across the Oklahoma City metropolitan area. The network consists of 4 Oklahoma Mesonet stations and 36 sites mounted on traffic signals. At each traffic signal site, atmospheric conditions are measured and transmitted every minute to a central facility. The Oklahoma Climatological Survey receives the observations, verifies the quality of the data and provides the data to Oklahoma City Micronet partners and customers. One major shortcoming of the system is that it is a very specialised implementation not using open standards or aiming at portability. The same applies to CORIE (Center for Coastal and Land-Margin Research, 2009), which is a pilot environmental observation and forecasting system (EOFS) for the Columbia River. It integrates a sensor network, a data management system and advanced numerical models. Paulsen (2008) presents a sensing infrastructure called PermaGIS that attempts to combine sensor systems and GIS-based visualisation technologies. The sensing devices, which measure rock temperature at ten minute intervals, focuses on optimising resource usage, including data aggregation, power consumption, and communication within the sensor network. In its current implementation, the infrastructure does not account for geospatial standards in sensor observations. The visualisation component uses a number of open standards (OGC WMS, WFS) and open-source services (UMN Map Server, Mapbender). There are a number of approaches to **leveraging sensor information in GIS** applications. Kansal et al. (2007) present the SenseWeb project, which aims to establish a Wikipedia-like sensor platform. The project seeks to allow users to include their own sensors in the system and thus leverage the 'community effect', building a dense network of sensors by aggregating existing and newly deployed sensors within the SenseWeb application. Although the authors discuss data transformation issues, data fusion, and simple GIS analysis, the system architecture is not based on open (geospatial) standards, only standard

infrastructure for various kinds of sensor network applications.

particular for urban environments.

**2. Related work**

web services. The web portal implementation, called SensorMap (Nath et al., 2006), uses the Sensor Description Markup Language (SDML), an application-specific dialect of the OGC SensorML standard.

A GIS mash-up for environmental data visualisation is presented in the nowCOAST application (National Oceanic and Atmospheric Administration, 2011). Data from providers such as National Oceanic and Atmospheric Administration (NOAA), U.S. Geological Survey (USGS), Department of Defence (DOD) or local airports, are integrated in a web-based graphical user interface. nowCOAST visualises several types of raw environmental parameters and also offers a 24-hour sea surface temperature interpolation plot with 0.5 degree spatial resolution, produced using a two-dimensional variation interpolation scheme. The system does not make use of open standards for sensor measurements and data provision.

The second related research area is real-time data integration and **sensor fusion** for geospatial analysis systems. Harrie (2004) and Lehto & Sarjakoski (2005) present web services based on the classic request/response model. Although both methods widely use open GIS standards, they are not suitable for the integration of real-time data for large volumes of data. Sarjakoski et al. (2004) establish a real-time spatial data infrastructure (SDI), which performs several application-specific steps, such as coordinate transformation, spatial data generalisation, query processing or map rendering and adaptation. However, the implemented system accounts neither for event-based push mechanisms nor for the integration of sensor data.

Other approaches for real-time data integration try to tackle the issue from a database perspective. Oracle's system, presented by Rittman (2008), is essentially a middleware between (web) services and a continuously updated database layer. Like Sybase Inc. (2008), the Oracle approach is able to detect database events in order to analyse heterogeneous data sources and trigger actions accordingly. Rahm et al. (2007) present a more dynamic method of data integration and fusion using on-the-fly object matching and metadata repositories to create a flexible data integration environment.

The third related research area is the development of **an open data integration system architecture** in a non-application specific infrastructure. Srivastava et al. (2006) and Balazinska et al. (2007) present general concepts in a systems architecture and data integration approach but there are no concrete conclusions as to how the final goal of establishing such an infrastructure could be achieved. A more technical approach for ad-hoc sensor networks is described by Riva & Borcea (2007), where the authors discuss challenges to making heterogeneous sensor measurements combinable through the creation of highly flexible middleware components. The method is application-motivated and thus very detailed as far as specific implementation details are concerned.

#### **3. Common Scents measurement infrastructure**

The *Common Scents* project aims at developing an interoperable open standards based infrastructure for providing fine-grained air quality data to allow users to assess environmental conditions instantaneously and intuitively. The goal is to provide citizens with unseen up-to-date information layers in order to support their short-term decisions. To achieve this vision, we utilise the CitySense sensor testbed and technologically build our system upon the *Live Geography* approach presented by Resch et al. (2009a). It should be stated that the term 'real-time' in our case is not defined by a pre-set numerical time

Standardised Geo-Sensor Webs for Integrated Urban Air Quality Monitoring 517

 *Sensor Model Language (SensorML)* – This standard provides an XML schema for defining the geometric, dynamic and observational characteristics of a sensor. Thus, SensorML assists in the discovery of different types of sensors, and supports the processing and analysis of the retrieved data, as well as the geo-location and tasking of

 *Observations & Measurements (O&M)* – O&M provides a description of sensor observations in the form of general models and XML encodings. This framework labels several terms for the measurements themselves as well as for the relationship between them. Measurement results are expressed as quantities, categories, temporal or

 *Transducer Model Language (TML)* – Generally speaking, TML can be understood as O&M's pendant or streaming data by providing a method and message format

*Sensor Observation Service (SOS)* – SOS provides a standardised web service interface

 *Sensor Planning Service (SPS)* – SPS offers an interface for planning an observation query. In effect, the service performs a feasibility check during the set up of a request

 *Sensor Alert Service (SAS)* – SAS can be seen as an event-processing engine whose purpose is to identify pre-defined events such as the particularities of sensor measurements, and then generate and send alerts in a standardised protocol format. *Web Notification Service (WNS)* – The Web Notification Service is responsible for delivering generated alerts to end-users by E-mail, over HTTP, or via SMS. Moreover, the standard provides an open interface for services, through which a client may

 *Sensor Web Registry* – The registry serves to maintain metadata about sensors and their observations. In short, it contains information including sensor location, which phenomena they measure, and whether they are static or mobile. Currently, the OGC is pursuing a harmonisation approach to integrate the existing CS-W (Web Catalogue Service) into SWE by building profiles in ebRIM/ebXML (e-business Registry

It should be mentioned that the OGC is currently establishing the so-called *SWE Common* namespace specification, which aims at grouping elements that are used in more than one standard of the SWE family. In effect, this will minimise redundancy, and optimise reusability and efficiency of the standards. SWE Common will mainly comprise very general elements such as counts, quantities, time elements or simple generic data representations. More information on the Sensor Web Enablement initiative, the incorporated standards and the efforts to embed it into the OGC standard service development can be found on the

Aside from the SWE standard family, which is used throughout the sensor network process chain, other OGC standards are employed to build up the overall infrastructure. At first, the Web Processing Service (WPS) is used for integrating measurement data with thematic process models in order to generate contextual information layers. WPS (Schut, 2007) basically allows for the implementation and execution of pre-defined analysis processes

geometrical values as well as arrays or composites of these.

allowing access to sensor observations and platform descriptions.

exchange asynchronous messages with one or more other services.

The functional connections between the SWE standards are illustrated in Figure 2.

describing how to interpret raw transducer data.

for data from several sensors.

Information Model).

1 http://www.opengeospatial.org

OGC web site1.

sensors.

constant, but more by qualitative expressions such as 'immediately' or 'ad-hoc', i.e. information layers have to be created in a timely manner to serve application-specific purposes. (Resch et al., 2009b)

### **3.1 Design principles**

In the conception of our technical infrastructure we accounted for different design principles (Service Oriented Architectures – SOA, modular software infrastructures etc.) to ensure flexibility, reusability and portability of the components and the overall infrastructure. Figure 1 shows the modular architecture and the standardised service interfaces that are used to connect the different components in the workflow.

Fig. 1. Common Scents – Modular Standardised Infrastructure

According to principles of SOA and sustainable infrastructure development, we conceived data collection, processing and information provision architecture, which covers the whole process chain from sensor network development via measurement integration, data analysis and information visualisation, as shown in Figure 1. Thus, our approach builds the architectural bridge between domain-independent sensor network development and use case specific requirements for end user tailored information output for environmental monitoring purposes.

#### **3.2 Standardised measurement infrastructure**

The modules of the workflow shown in Figure 1 are separated by several interfaces, which are defined using open standards. The first central group of standards is subsumed under the term Sensor Web Enablement (SWE), an initiative by the OGC that aims to make sensors discoverable, query-able, and controllable over the Internet (Botts et al., 2007). Currently, the SWE family consists of seven standards comprising data models and service interfaces:

constant, but more by qualitative expressions such as 'immediately' or 'ad-hoc', i.e. information layers have to be created in a timely manner to serve application-specific

In the conception of our technical infrastructure we accounted for different design principles (Service Oriented Architectures – SOA, modular software infrastructures etc.) to ensure flexibility, reusability and portability of the components and the overall infrastructure. Figure 1 shows the modular architecture and the standardised service interfaces that are

According to principles of SOA and sustainable infrastructure development, we conceived data collection, processing and information provision architecture, which covers the whole process chain from sensor network development via measurement integration, data analysis and information visualisation, as shown in Figure 1. Thus, our approach builds the architectural bridge between domain-independent sensor network development and use case specific requirements for end user tailored information output for environmental

The modules of the workflow shown in Figure 1 are separated by several interfaces, which are defined using open standards. The first central group of standards is subsumed under the term Sensor Web Enablement (SWE), an initiative by the OGC that aims to make sensors discoverable, query-able, and controllable over the Internet (Botts et al., 2007). Currently, the SWE family consists of seven standards comprising data models and service interfaces:

purposes. (Resch et al., 2009b)

used to connect the different components in the workflow.

Fig. 1. Common Scents – Modular Standardised Infrastructure

**3.2 Standardised measurement infrastructure**

**3.1 Design principles**

monitoring purposes.

The functional connections between the SWE standards are illustrated in Figure 2.

It should be mentioned that the OGC is currently establishing the so-called *SWE Common* namespace specification, which aims at grouping elements that are used in more than one standard of the SWE family. In effect, this will minimise redundancy, and optimise reusability and efficiency of the standards. SWE Common will mainly comprise very general elements such as counts, quantities, time elements or simple generic data representations.

More information on the Sensor Web Enablement initiative, the incorporated standards and the efforts to embed it into the OGC standard service development can be found on the OGC web site1.

Aside from the SWE standard family, which is used throughout the sensor network process chain, other OGC standards are employed to build up the overall infrastructure. At first, the Web Processing Service (WPS) is used for integrating measurement data with thematic process models in order to generate contextual information layers. WPS (Schut, 2007) basically allows for the implementation and execution of pre-defined analysis processes

<sup>1</sup> http://www.opengeospatial.org

Standardised Geo-Sensor Webs for Integrated Urban Air Quality Monitoring 519

around the city of Cambridge measuring different environmental parameters such as CO2 concentrations, air temperature, wind speed and direction, or precipitation. The final CitySense deployment will comprise up to 100 sensing nodes to build the basis for pervasive

Another pilot experiment, which aimed at the deployment of a mobile sensor network, was conducted in the city of Copenhagen, Denmark. Ten bicycle mounted sensors2 were used to collect environmental data (CO, NOx, noise, air temperature and relative humidity) together with time and the geographic location using GPS – from which velocity and acceleration can be calculated. In this experiment of ubiquitous mobile sensing, we used the Sensaris City Senspod3, a relatively low-cost sensor pod. The deployment in Copenhagen was a combined effort of the MIT SENSEable City Laboratory, and Københavns Kommune, Denmark. To comply with the standardised infrastructure described in sub-section 3.1, we implemented several standardised services on top of these sensor networks, in accordance with the Live Geography approach (Resch et al., 2009a). For data access, we developed a Sensor Observation Service (SOS), which supplies measurement data in the standardised O&M format. It builds the O&M XML structure dynamically according to measured parameters and filter operations. To generate alerts e.g. in case of exceedance of a threshold, we implemented an XMPP (Extensible Messaging and Presence Protocol) based Sensor Alert Service (SAS). It is able to detect patterns and anomalies in the measurement data and generate alerts and trigger appropriate operations such as sending out an email or a text

Within the workflow described in sub-section 3.1, event recognition and processing happens in two different stages: 1.) at sensor level, Complex Event Processing (CEP) is used to detect errors in measurement values by applying different statistical operations such as standard deviations, spatial and temporal averaging, or outlier detection. Thus, it can be considered a mechanism for quality control and error prevention. To be able to detect condition changes in measurement values, we enhanced CEP and Event Stream Processing (ESP) techniques by the location parameter. Thus, these methods can also serve for the federal organisation of predefined geographical domain violations like geo-fences, and for tracing and analysing spatial patterns. 2.) after the data harmonisation process, CEP serves for spatio-temporal pattern

recognition, anomaly detection, and alert generation in case of threshold exceedance.

Figure 3 shows the components of the CEP-based event processing component, which is

Generally speaking, the event processing component serves as a connection between the data layer (sensor measurements) and the data analysis and data visualisation components, i.e. it prepares raw data in order to be process-able in the analysis and the visualisation layers. The first module is the data transportation, which connects different real-time and non-real-time data sources, i.e. it serves as an entry point into the event processing layer. Next, the retrieved data is passed on to the data transformation module, which prepares the data to be further processed. This 'processing' shall not be seen as data analysis, but more as data preparation. Basically, the transportation module converts the byte input stream to

urban monitoring. (Resch et al., 2009b)

message, or to start a pre-defined GIS analysis operation.

**3.4 Event-based alerting**

built up in a modular structure.

2 http://senseable.mit.edu/copenhagenwheel

3 http://www.sensaris.com

objects.

with dedicated input and output parameters. It supports synchronous and asynchronous data processing to enable sophisticated processing of large amounts of vector and raster data. The WPS standard has been discussed by Resch et al. (2010a) including issues such as input/output data definition, WPS profiling, asynchronous processing, and others.

Fig. 2. Functional Connections Between the SWE Standards. (adapted from Botts et al., 2006)

The OGC developed a set of service interfaces for standardised data provision and visualisation dealing with various kinds of GIS data types. The Web Feature Service (WFS), the Web Map Service (WMS) and the Web Coverage Service (WCS) standards allow for access to geo-data such as vectors (point, line, polygon), raster images, and coverages (surface-like structures). More information about these standards and service implementations can be found on the OGC web site.

The essential benefit of using the OGC processing and data provision services mentioned above is the wide variety of standardised (GML, KML etc.) and custom output formats (GeoRSS, PDF etc.). This allows for the integration of the OGC service outputs into other processing, visualisation or decision support services including legacy COTS and opensource GIS analysis tools.

#### **3.3 Data source: Geo-sensor web**

In the Common Scents project, two pilot studies have been conducted. The first one used the *CitySense* sensing network (Murty et al., 2008) as the underlying sensing and data collection infrastructure. The main goal of the ongoing CitySense project is to build an urban sensor network to measure environmental parameters and is thus the data source for further data analysis. The project focuses on the development of a city-wide sensing system using an optimised network infrastructure. Currently, the network consists of 16 nodes deployed around the city of Cambridge measuring different environmental parameters such as CO2 concentrations, air temperature, wind speed and direction, or precipitation. The final CitySense deployment will comprise up to 100 sensing nodes to build the basis for pervasive urban monitoring. (Resch et al., 2009b)

Another pilot experiment, which aimed at the deployment of a mobile sensor network, was conducted in the city of Copenhagen, Denmark. Ten bicycle mounted sensors2 were used to collect environmental data (CO, NOx, noise, air temperature and relative humidity) together with time and the geographic location using GPS – from which velocity and acceleration can be calculated. In this experiment of ubiquitous mobile sensing, we used the Sensaris City Senspod3, a relatively low-cost sensor pod. The deployment in Copenhagen was a combined effort of the MIT SENSEable City Laboratory, and Københavns Kommune, Denmark.

To comply with the standardised infrastructure described in sub-section 3.1, we implemented several standardised services on top of these sensor networks, in accordance with the Live Geography approach (Resch et al., 2009a). For data access, we developed a Sensor Observation Service (SOS), which supplies measurement data in the standardised O&M format. It builds the O&M XML structure dynamically according to measured parameters and filter operations. To generate alerts e.g. in case of exceedance of a threshold, we implemented an XMPP (Extensible Messaging and Presence Protocol) based Sensor Alert Service (SAS). It is able to detect patterns and anomalies in the measurement data and generate alerts and trigger appropriate operations such as sending out an email or a text message, or to start a pre-defined GIS analysis operation.

#### **3.4 Event-based alerting**

518 Environmental Monitoring

with dedicated input and output parameters. It supports synchronous and asynchronous data processing to enable sophisticated processing of large amounts of vector and raster data. The WPS standard has been discussed by Resch et al. (2010a) including issues such as

Fig. 2. Functional Connections Between the SWE Standards. (adapted from Botts et al., 2006) The OGC developed a set of service interfaces for standardised data provision and visualisation dealing with various kinds of GIS data types. The Web Feature Service (WFS), the Web Map Service (WMS) and the Web Coverage Service (WCS) standards allow for access to geo-data such as vectors (point, line, polygon), raster images, and coverages (surface-like structures). More information about these standards and service

The essential benefit of using the OGC processing and data provision services mentioned above is the wide variety of standardised (GML, KML etc.) and custom output formats (GeoRSS, PDF etc.). This allows for the integration of the OGC service outputs into other processing, visualisation or decision support services including legacy COTS and open-

In the Common Scents project, two pilot studies have been conducted. The first one used the *CitySense* sensing network (Murty et al., 2008) as the underlying sensing and data collection infrastructure. The main goal of the ongoing CitySense project is to build an urban sensor network to measure environmental parameters and is thus the data source for further data analysis. The project focuses on the development of a city-wide sensing system using an optimised network infrastructure. Currently, the network consists of 16 nodes deployed

implementations can be found on the OGC web site.

source GIS analysis tools.

**3.3 Data source: Geo-sensor web**

input/output data definition, WPS profiling, asynchronous processing, and others.

Within the workflow described in sub-section 3.1, event recognition and processing happens in two different stages: 1.) at sensor level, Complex Event Processing (CEP) is used to detect errors in measurement values by applying different statistical operations such as standard deviations, spatial and temporal averaging, or outlier detection. Thus, it can be considered a mechanism for quality control and error prevention. To be able to detect condition changes in measurement values, we enhanced CEP and Event Stream Processing (ESP) techniques by the location parameter. Thus, these methods can also serve for the federal organisation of predefined geographical domain violations like geo-fences, and for tracing and analysing spatial patterns. 2.) after the data harmonisation process, CEP serves for spatio-temporal pattern recognition, anomaly detection, and alert generation in case of threshold exceedance.

Figure 3 shows the components of the CEP-based event processing component, which is built up in a modular structure.

Generally speaking, the event processing component serves as a connection between the data layer (sensor measurements) and the data analysis and data visualisation components, i.e. it prepares raw data in order to be process-able in the analysis and the visualisation layers. The first module is the data transportation, which connects different real-time and non-real-time data sources, i.e. it serves as an entry point into the event processing layer. Next, the retrieved data is passed on to the data transformation module, which prepares the data to be further processed. This 'processing' shall not be seen as data analysis, but more as data preparation. Basically, the transportation module converts the byte input stream to objects.

<sup>2</sup> http://senseable.mit.edu/copenhagenwheel

<sup>3</sup> http://www.sensaris.com

Standardised Geo-Sensor Webs for Integrated Urban Air Quality Monitoring 521

We are currently facing a drastic increase in the availability of geospatial real-time data sources, and this applies especially to rapid developments and price reduction in sensing technologies. To make use of this immense amount of data within environmental monitoring systems, real-time data integration mechanisms have to be developed, which harmonise and fuse the different kinds of data. Furthermore, these data have to be provided in standardised formats in order to allow interoperability and collaboration between

Most current data integration systems make use of a temporary database to combine different kinds of raw data, as stated in section 2. This approach has two distinctive disadvantages. Firstly, it manifests data into a physical structure and thus severely limits real-time capabilities. Secondly, the laborious operation of creating and filling a database table adds another step in the overall workflow, which decreases performance and expands

To overcome these shortcomings, we implemented the real-time data integration component in a custom data store for the open-source server GeoServer. This solution offers two main advantages: at first, data are fused on-the-fly in a highly dynamic, fast and parallelised process. At second, GeoServer provides standardised WFS, WMS and WCS outputs, as described above, which allows for simple integration into analysis and visualisation

Using the sensor web deployments described in section 3, we implemented two spatio-

The first pilot deployment has been carried out in the course of the *Copenhagen Wheel* project. This project was unveiled in Copenhagen on 15 December 2009 as part of 15th Conference of the Parties during the 2009 United Nations Climate Change Conference meeting. The Copenhagen Wheel is capturing information about carbon monoxide (CO), NOx (NO + NO2), noise, ambient temperature, relative humidity in addition to position, velocity and

The environmental sensors were originally intended to be placed within the hub of the bicycle wheel however due to logistical pressure they were placed on bicycles ridden by couriers in Copenhagen going about their normal daily routine. Thus the testing was essentially a proof-of-concept. Ten cycles were instrumented and tested over 2 December 2009. It is believed that this was the first time multiple mobile sensors had been used in the

The analysis component, which processes the collected data, performs a spatial Inverse Distance Weighting (IDW) interpolation (for a comparison with Kriging interpolation, s. Zimmermann et al., 1999) on temperature measurements, which will be used in further research efforts for correlation operations with emission distribution or traffic emergence,

Moreover, the processing module analyses the CO distribution throughout the city of Copenhagen. The basic CO map containing the GPS traces and the output of the

The second geo-processing component uses ArcGIS's Tracking Analyst tool to perform spatio-temporal analysis on measurement data over a period of time. In order to achieve a coarse overview of pollutant variability, we used CO2 data captured by the CitySense

software. More about implementation details can be found in Resch et al. (2009a).

**3.5 Real-time sensor fusion**

different institutions and data providers.

implementation complexity and costs.

temporal data analysis modules.

acceleration.

**4. Results of spatio-temporal data analysis**

field with such a large variety of environmental sensors.

interpolation process – a navigable 3D map – are shown in Figure 4.

and for the detection of urban heat islands.

Fig. 3. CEP-based Event Processing Component Architecture

These objects can then be used by two higher-level components; firstly, by the data persistence component, which establishes a static data structure from the source data; secondly, by an event processing engine, which processes a real-time stream, identifies/selects events and pushes them to the user-defined processing module. The latter performs a kind of 'event filtering' and sends the resulting message to the service components.

One particularity, which shall be mentioned at this point, is the connection between the processing and the data persistence modules. The idea behind this functional link is that data, which have been prepared by the processing components, can either be pushed to the service components or they can be temporarily stored to be accessed by OGC services.

The two service-related components in Figure 3 (Web Service and Non-standard Service) serve as the direct interfaces to the data integration and data analysis layers. They offer the pre-processed raw data via a defined data structure, e.g. in a standardised output format such as GML, KML, geoTIFF etc. or in a custom output format.

For the OGC service component, all data are served over well-established open and standardised interfaces (OGC WFS, WMS and WCS). These XML web interfaces enable standardised data access and guarantee combinability of the various kinds of used data for further automated processing, as described in sub-section 3.2. In this way, pre-defined aggregation services can be implemented in the data analysis layer offering the results to a range of different users, i.e. platforms.

In addition to the standardised interfaces, also a non-standard service has to be created as existing OGC services don't support push mechanisms per se. A longer term option will be to replace these non-standard interfaces by push-capable standard services. More detailed information about the event processing component can be found in Resch et al. (2010b).

#### **3.5 Real-time sensor fusion**

520 Environmental Monitoring

These objects can then be used by two higher-level components; firstly, by the data persistence component, which establishes a static data structure from the source data; secondly, by an event processing engine, which processes a real-time stream, identifies/selects events and pushes them to the user-defined processing module. The latter performs a kind of 'event filtering' and sends the resulting message to the service

One particularity, which shall be mentioned at this point, is the connection between the processing and the data persistence modules. The idea behind this functional link is that data, which have been prepared by the processing components, can either be pushed to the service components or they can be temporarily stored to be accessed by OGC services. The two service-related components in Figure 3 (Web Service and Non-standard Service) serve as the direct interfaces to the data integration and data analysis layers. They offer the pre-processed raw data via a defined data structure, e.g. in a standardised output format

For the OGC service component, all data are served over well-established open and standardised interfaces (OGC WFS, WMS and WCS). These XML web interfaces enable standardised data access and guarantee combinability of the various kinds of used data for further automated processing, as described in sub-section 3.2. In this way, pre-defined aggregation services can be implemented in the data analysis layer offering the results to a

In addition to the standardised interfaces, also a non-standard service has to be created as existing OGC services don't support push mechanisms per se. A longer term option will be to replace these non-standard interfaces by push-capable standard services. More detailed information about the event processing component can be found in Resch et al.

Fig. 3. CEP-based Event Processing Component Architecture

such as GML, KML, geoTIFF etc. or in a custom output format.

range of different users, i.e. platforms.

components.

(2010b).

We are currently facing a drastic increase in the availability of geospatial real-time data sources, and this applies especially to rapid developments and price reduction in sensing technologies. To make use of this immense amount of data within environmental monitoring systems, real-time data integration mechanisms have to be developed, which harmonise and fuse the different kinds of data. Furthermore, these data have to be provided in standardised formats in order to allow interoperability and collaboration between different institutions and data providers.

Most current data integration systems make use of a temporary database to combine different kinds of raw data, as stated in section 2. This approach has two distinctive disadvantages. Firstly, it manifests data into a physical structure and thus severely limits real-time capabilities. Secondly, the laborious operation of creating and filling a database table adds another step in the overall workflow, which decreases performance and expands implementation complexity and costs.

To overcome these shortcomings, we implemented the real-time data integration component in a custom data store for the open-source server GeoServer. This solution offers two main advantages: at first, data are fused on-the-fly in a highly dynamic, fast and parallelised process. At second, GeoServer provides standardised WFS, WMS and WCS outputs, as described above, which allows for simple integration into analysis and visualisation software. More about implementation details can be found in Resch et al. (2009a).

### **4. Results of spatio-temporal data analysis**

Using the sensor web deployments described in section 3, we implemented two spatiotemporal data analysis modules.

The first pilot deployment has been carried out in the course of the *Copenhagen Wheel* project. This project was unveiled in Copenhagen on 15 December 2009 as part of 15th Conference of the Parties during the 2009 United Nations Climate Change Conference meeting. The Copenhagen Wheel is capturing information about carbon monoxide (CO), NOx (NO + NO2), noise, ambient temperature, relative humidity in addition to position, velocity and acceleration.

The environmental sensors were originally intended to be placed within the hub of the bicycle wheel however due to logistical pressure they were placed on bicycles ridden by couriers in Copenhagen going about their normal daily routine. Thus the testing was essentially a proof-of-concept. Ten cycles were instrumented and tested over 2 December 2009. It is believed that this was the first time multiple mobile sensors had been used in the field with such a large variety of environmental sensors.

The analysis component, which processes the collected data, performs a spatial Inverse Distance Weighting (IDW) interpolation (for a comparison with Kriging interpolation, s. Zimmermann et al., 1999) on temperature measurements, which will be used in further research efforts for correlation operations with emission distribution or traffic emergence, and for the detection of urban heat islands.

Moreover, the processing module analyses the CO distribution throughout the city of Copenhagen. The basic CO map containing the GPS traces and the output of the interpolation process – a navigable 3D map – are shown in Figure 4.

The second geo-processing component uses ArcGIS's Tracking Analyst tool to perform spatio-temporal analysis on measurement data over a period of time. In order to achieve a coarse overview of pollutant variability, we used CO2 data captured by the CitySense

Standardised Geo-Sensor Webs for Integrated Urban Air Quality Monitoring 523

Figure 6 illustrates a time series representation of the measured parameters ambient temperature, CO, NOx and noise. These measurements were taken in Copenhagen over a period of five hours on 2 December 2009. A first assessment shows that there are strong

Preliminary findings show that both CO and CO2 are characterised by very high temporal and spatial fluctuations, which are induced by a variety of factors including temperature variability, time during the day, traffic emergence or 'plant respiration' – the fact that plants release major amounts of CO2 over night. Also, CO is a measure of the efficiency of combustion in vehicles and may be used to reflect changing driving patterns and the sensitivity of air quality to larger scale environmental features such as the wind speeds over the city. However, the detailed interplay of these parameters still has to be investigated in a next step. Especially CO values measured in the Copenhagen pilot have to be normalised over humidity and temperature to perform further quantitative (absolute amounts) and

More than ten years ago, Al Gore articulated a vision of 'Digital Earth' as a multi-resolution, three-dimensional representation of the planet that would make it possible to find, visualise, and make sense of vast amounts of geo-referenced information on the physical and social environment (Gore 1998, for a comprehensive discussion see Craglia et al. 2008). Google Earth, NASA World Wind and other geo-browsers brought high resolution imagery to hundreds of millions of internet users and a major industry developed ways to explore data geographically, and visualise overlaid information provided by both the public and private

Generally speaking, fine-grained urban sensing greatly enhances our knowledge of the environment by adding objective and non-visible data layers in real-time (Resch et al., 2008). In other words, these systems help us increase our capacity to observe and understand the city, and the impacts on and by society. This seems to be a very desirable state because more

correlations between ambient temperature, CO and NOx values.

Fig. 6. Time Series Representation of Environmental Measurements.

sectors, as well as citizens who volunteer new data (Goodchild, 2007).

qualitative (impact on public health) analysis.

**5. Potential application areas**

network in Cambridge. This allows for correlating temporal measurement data fluctuation to traffic density, weather conditions or day-time related differences in a very flexible way. The lower left part of Figure 5 shows the temporal gradient of the measurement values. Running the time series then changes symbologies in the map on the right side accordingly in a dynamic manner in real-time.

Fig. 4. Spatial Distribution of CO Values in the City of Copenhagen.

Fig. 5. Spatio-temporal CO2 Data Analysis Using Tracking Analyst.

network in Cambridge. This allows for correlating temporal measurement data fluctuation to traffic density, weather conditions or day-time related differences in a very flexible way. The lower left part of Figure 5 shows the temporal gradient of the measurement values. Running the time series then changes symbologies in the map on the right side accordingly

Fig. 4. Spatial Distribution of CO Values in the City of Copenhagen.

Fig. 5. Spatio-temporal CO2 Data Analysis Using Tracking Analyst.

in a dynamic manner in real-time.

Figure 6 illustrates a time series representation of the measured parameters ambient temperature, CO, NOx and noise. These measurements were taken in Copenhagen over a period of five hours on 2 December 2009. A first assessment shows that there are strong correlations between ambient temperature, CO and NOx values.

Fig. 6. Time Series Representation of Environmental Measurements.

Preliminary findings show that both CO and CO2 are characterised by very high temporal and spatial fluctuations, which are induced by a variety of factors including temperature variability, time during the day, traffic emergence or 'plant respiration' – the fact that plants release major amounts of CO2 over night. Also, CO is a measure of the efficiency of combustion in vehicles and may be used to reflect changing driving patterns and the sensitivity of air quality to larger scale environmental features such as the wind speeds over the city. However, the detailed interplay of these parameters still has to be investigated in a next step. Especially CO values measured in the Copenhagen pilot have to be normalised over humidity and temperature to perform further quantitative (absolute amounts) and qualitative (impact on public health) analysis.