Revision as of 12:25, 21 April 2016

Toolbox
Home Toolbox Usage examples About us

The main goal of the toolbox developed in Citi-Sense-MOB is to provide guidance for the future, to include novel sensors for air quality monitoring. The toolbox addressed the following components

• server side management of sensor data
• user applicability, using apps
• widgets and code-snippets

The Citi-Sense-MOB toolbox

Server infrastructure

In CSM data is collected either from AQ sensors or from mobile app. Collected data will be store later on main server. To enable data sources reusability, this section, gives an overview needed information to use these resources. At the beginning, it gives an overview CSM servers, later it describes the accepted XML format for data posted from mobile app or sensors to CSM sever.

CSM Servers

In CSM, the core of data storage is the Spatial and Environmental Data Services (SEDS) platform (version 2.2) implemented on an Amazon Cloud instance. This SEDS platform provided by Snowflake Software Company (a partner of the CITI-SENSE project). http://www.snowflakesoftware.com/company/

SEDS platform has three fundamental components listed and shown within below figure, being:-

• Data Ingestion – WFS-T services over https to load data into a relation database
• Data Storage- a relation database
• Data Publication – open web services both WFS and web services over https.

Mobile app data format

This subsection describes the format that stakeholders should follow in order to add new data item to data send from mobile app to the server. The Data Ingestion component of the SEDS platform is used to transmit and store the data to a global storage repository. This is done using the secure HTTP protocol`s (HTTPS) POST request containing the data to be stored, which is transmitted from the smartphone and to the server. To be allowed access to the POST request method the stakeholders must retrieve a username and password from the platform provider (http://www.snowflakesoftware.com/company/). The Data Ingestion component has one single endpoint for posting/ingestion data, which is WFST (https://prod.citisense.snowflakesoftware.com/wfst). The data model on the SEDS platform is implemented based on existing ISO and OGC models and this is reflected in the XML used for transmitting the data. Figure 9 shows the SEDS data model.

As it shown in Figure 9, the SEDS platform offers two types of observations to be registered on the storage, being:-

• Measurement
• Questionnaire

The measurement object is used for storing less complex observations with values as decimals. Below an example for XML format to register measurements observation:-

 <?xml version="1.0"?>
<wfs:Transaction version="2.0.0" service="WFS" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:cts="http:www.citi-sense.eu/citisense"
xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gco="http://www.isotc211.org/2005/gco"
xmlns:gss="http://www.isotc211.org/2005/gss" xmlns:gts="http://www.isotc211.org/2005/gts"
xmlns:gsr="http://www.isotc211.org/2005/gsr" xmlns:wfs="http://www.opengis.net/wfs/2.0"
xmlns:ows="http://www.opengis.net/ows/1.1" xmlns:fes="http://www.opengis.net/fes/2.0">
   <wfs:Insert>
       <cts:Observation gml:id="LOCAL_ID_0">
           <cts:sensorID xlink:href="#CITISENSE-Test-00000004"/>
           <cts:contains>
               <cts:Measurement>
                   <cts:measurementID>1</cts:measurementID>
                   <cts:value>10</cts:value>
                   <cts:uom>ppb</cts:uom>
                   <cts:observedProperty>NO2</cts:observedProperty>
                   <cts:measuretime>2001-12-17T09:30:47Z</cts:measuretime>
                   <cts:latitude>3.141</cts:latitude>
                   <cts:longitude>3.1415</cts:longitude>
               </cts:Measurement>
           </cts:contains>
           <cts:contains>
               <cts:Measurement>
                   <cts:measurementID>2</cts:measurementID>
                   <cts:value>16532</cts:value>
                   <cts:uom>ppb</cts:uom>
                   <cts:observedProperty>NO2</cts:observedProperty>
                   <cts:measuretime>2001-12-17T09:30:47Z</cts:measuretime>
                   <cts:latitude>3.141</cts:latitude>
                   <cts:longitude>3.1415</cts:longitude>
               </cts:Measurement>
           </cts:contains>
           <cts:observationID>2</cts:observationID>
           <cts:starttime>2001-12-17T09:30:47Z</cts:starttime>
           <cts:finishtime>2001-12-17T09:30:47Z</cts:finishtime>
           <cts:participantID>test_testID1</cts:participantID>
       </cts:Observation>
   </wfs:Insert>
</wfs:Transaction>

The questionnaire object gives the possibility to store more complex data sets and can contain both question and answer with detailed information about the questionnaire and the questions asked. Table 2 shows XML format to register questionnaire observations with answer.

<?xml version="1.0"?>
<wfs:Transaction version="2.0.0" service="WFS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"    xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:cts="http:www.citi-sense.eu/citisense" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gco="http://www.isotc211.org/2005/gco" xmlns:gss="http://www.isotc211.org/2005/gss" xmlns:gts="http://www.isotc211.org/2005/gts" xmlns:gsr="http://www.isotc211.org/2005/gsr" xmlns:wfs="http://www.opengis.net/wfs/2.0" xmlns:ows="http://www.opengis.net/ows/1.1" xmlns:fes="http://www.opengis.net/fes/2.0">
   <wfs:Insert>
       <cts:Observations gml:id="LOCAL_ID_0">
           <cts:canHave>
               <cts:Questionnaire>
                   <cts:includes>
                       <cts:Question>
                           <cts:has>
                               <cts:Response>
                                   <cts:idresponse>1</cts:idresponse>
                                   <cts:source>xxx</cts:source>
                                   <cts:timestamp>2014-02-14T10:23:00.000</cts:timestamp>
                               </cts:Response>
                           </cts:has>
                           <cts:needs>
                               <cts:Answer>
                                   <cts:idanswer>1</cts:idanswer>
                                   <cts:value>blablablablablabla</cts:value>
                               </cts:Answer>
                           </cts:needs>
                           <cts:idquestion>1</cts:idquestion>
                           <cts:parent_id>1</cts:parent_id>
                           <cts:order>1</cts:order>
                           <cts:type>xxx</cts:type>
                           <cts:label>xxx</cts:label>
                           <cts:maxlength>123</cts:maxlength>
                           <cts:values>xxx</cts:values>
                           <cts:required>123</cts:required>
                           <cts:rtl>123</cts:rtl>
                       </cts:Question>
                   </cts:includes>
                   <cts:idquestionnaire>1</cts:idquestionnaire>
                   <cts:url>http:\/\/citisense.u-hopper.com\/img\/logo.jpg</cts:url>
                   <cts:title>xxx</cts:title>
                   <cts:description>xxx</cts:description>
                   <cts:rlt>123</cts:rlt>
                   <cts:campaign_id>123</cts:campaign_id>
                   <cts:created>2014-02-14T10:23:00.000</cts:created>
                   <cts:updated>2014-02-14T10:23:00.000</cts:updated>
               </cts:Questionnaire>
           </cts:canHave>
           <cts:cityId xlink:href="#5"/>
           <cts:sensorId xlink:href="#3"/>
           <cts:idobservation>4</cts:idobservation>
           <cts:starttime>2014-02-14T10:23:00.000</cts:starttime>
           <cts:finishtime>2014-02-14T10:23:00.000</cts:finishtime>
       </cts:Observations>
   </wfs:Insert>
</wfs:Transaction>

Sensor data

Before any registration of observations a sensor device needs to be registered on the SEDS platform. (An example of xml format for sensor registration is shown in Table 3). As it shown in figure 9 within sensor device data object, sensor device could contain different information about sensor, being:-

• ID of the sensor device
• Type of observations this sensor will contain
• Date when the sensor was registered
• Status, if sensor is active or not and if the sensor is to be defined a static or a mobile sensor.
• Can also include information about the location of the sensor, which can be used to find and combine later to create visualizations and reports of the data using the data publication component of the platform.

<?xml version="1.0"?>
<wfs:Transaction version="2.0.0" service="WFS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:cts="http:www.citi-sense.eu/citisense" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gco="http://www.isotc211.org/2005/gco" xmlns:gss="http://www.isotc211.org/2005/gss" xmlns:gts="http://www.isotc211.org/2005/gts" xmlns:gsr="http://www.isotc211.org/2005/gsr" xmlns:wfs="http://www.opengis.net/wfs/2.0" xmlns:ows="http://www.opengis.net/ows/1.1" xmlns:fes="http://www.opengis.net/fes/2.0">
 <wfs:Insert>
   <cts:SensorDevice gml:id="LOCAL_ID_0">
     <cts:sensorProviderID xlink:href="#1001"/>
     <cts:identifier>id</cts:identifier>
     <cts:description>CityAir Perception sensor</cts:description>
     <cts:registrationDate>2015-02-18T09:30:47.000</cts:registrationDate>
     <cts:type>mobile</cts:type>
     <cts:status>active</cts:status>
     <cts:location>Oslo</cts:location>
   </cts:SensorDevice>
 </wfs:Insert>
</wfs:Transaction>

Based on security concerns, new sensor registration is controlled with password and user name. Thus, for registration of new sensor, stakeholder need to contact Snowflake to agree with them on user name and password, in case s/he needs to make many registration for many sensors. Another option user could contact Snowflake and provide with sensor data, thus, they do the needed registration (http://www.snowflakesoftware.com/)

It is recommended for user who want to buy new AQ sensor and integrate it to CSM sensors network to buy it from one of vendors shown in table 4. Since sensors from listed vendors are supported by CSM platform:-

Inclusion of existing information

• Fixed stations
• Pollen information for

App development

Github repository of App code

https://github.com/unikdrift/air-quality-app

Supported Sensors

This section presents links to sensors platforms being used and tested in the Citi-Sense-MOB project:

• DunavNET, http://www.dunavnet.eu/

 Gases: NO, NO2, O3, CO, CO2, Temperature, Relative humidity, atmospheric pressure

• UrVaMM Ingenieros Asesores, http://www.ingenierosasesores.com/index.php

 Gases: NO2 and CO

• Cairpol, http://www.cairpol.com/index.php?lang=en

 Gases: NO2 and O3

• AQMesh, http://www.aqmesh.com/

 Gases: NO, NO2, O3, CO, PM10, PM2.5

• LEO, http://citisense.ateknea.com/

 Gases: NO, NO2, O3

Step-by-step procedure to add your sensor

The way on how to include a new sensor consists of the following steps

1. Buy a sensor, currently we support the sensors listed in #Supported Sensors

2. With your sensor you will receive a SensorID, e.g. xxxxxx (for Dunavnet sensor)

3. Send us your sensor idea through the #Register your sensor form

4. We will then get in contact with you to explain how the sensors can be integrated

Register your sensor

as soon as we have filled in the page, I will protect it such that we can test CSM_Sensor_Registration