Revision as of 12:35, 21 April 2016

Toolbox

Home

Toolbox

Usage examples

About us

The Citi-Sense-MOB toolbox

Screenshot of the CitySense app

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:-

Sensor platform	Vendor	Web site
DunavNET	DunavNET, Serbia	http://www.dunavnet.eu/
UrVaMM	Ingenieros Asesores, Spain	http://www.ingenierosasesores.com/index.php
Cairpol	Cairpol, France	http://www.cairpol.com/index.php?lang=en
AQMesh	AQMesh, UK	http://www.aqmesh.com/
LEO	Ateknea	http://citisense.ateknea.com/

In case that the user want to visualize sensor with CSM mobile app, s/he needs to contact UNIK to add sensor to mobile app visualized sensor. Thus, user could send email to one of the following emails address:- seraj@unik.no or josef@unik.no

Inclusion of existing information

Fixed stations
Pollen information for

App development

Mobile app code

In CSM project a mobile app called Sense City Air was developed. This mobile app provide a set of services described in D 4.6. This section gives an overview about the code of the mobile app. At the beginning, its goes through used libraries within this app. Later it provides brief description about used functions within this app. The code described in this section could reachable online as open sources code using Github (https://github.com/unikdrift/Oslo-AirQuality)

Mobile app libraries

Libraries used in the development of City Sense Air mobile app could be classified based on its resources as follow:-

Phonegap: The application CSM is built upon Cordova framework which is the main technology for hybrid mobile development. It helped the development of UI components to be in common between Android and iOS platforms. However, in order to develop and improve some OS specific functionalities cordova plugins were a must to benefit from.

Imported cordova plugins (for Android OS);

- com.darktalker.cordova.screenshot 0.1.1 "Screenshot" : The Screenshot plugin allows your application to take screenshots of the current screen and save them into the phone.

- com.sama.wifigps 0.2.11 "WifiGPS-Plugin”: Provides the application with wi-fi and GPS status. - cordova-plugin-whitelist 1.0.0 "Whitelist" : implements a whitelist policy for navigating the application webview on Cordova 4.0. - de.appplant.cordova.plugin.email-composer 0.8.3dev "EmailComposer" : provides access to the standard interface that manages the editing and sending an email message. - nl.x-services.plugins.socialsharing 4.3.19 "SocialSharing" : allows you to use the native sharing window of your mobile device. - org.apache.cordova.camera 0.3.6 "Camera" : defines a global navigator.camera object, which provides an API for taking pictures and for choosing images from the system's image library. - org.apache.cordova.device 0.3.0 "Device" : defines a global device object, which describes the device's hardware and software. Although the object is in the global scope, it is not available until after the deviceready event. - org.apache.cordova.file 1.3.3 "File" : implements a File API allowing read/write access to files residing on the device. - org.apache.cordova.geolocation 0.3.12 "Geolocation" : provides information about the device's location, such as latitude and longitude. - org.apache.cordova.globalization 0.3.4 "Globalization" : obtains information and performs operations specific to the user's locale, language, and timezone. - org.apache.cordova.network-information 0.2.15 "Network Information": provides an implementation of an old version of the Network Information API. It provides information about the device's cellular and wifi connection, and whether the device has an internet connection. - org.apache.cordova.splashscreen 1.0.0 "Splashscreen" : displays and hides a splash screen during application launch. - org.apache.cordova.vibration 0.3.13 "Vibration" : aligns with the W3C vibration specification http://www.w3.org/TR/vibration/

Please note that these plugins may need maintenance when new APIs are released or a new technology emerges because of the reason that some methods get deprecated, or they may not be supporting the new features of the emerging technology. In maintenance phase, this should be taken into consideration that the plugins should be working and always supported.

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

Register your sensor

EmailForm is only active on protected pages.

Search

Main

Applied Research for

List of

Forms (create or edit)

Help

Difference between revisions of "CSM:Toolbox"

From its-wiki.no

Revision as of 12:35, 21 April 2016

Contents

The Citi-Sense-MOB toolbox

Server infrastructure

CSM Servers

Mobile app data format

Sensor data

Inclusion of existing information

App development

Mobile app code

Mobile app libraries

Github repository of App code

Supported Sensors

Step-by-step procedure to add your sensor

Register your sensor

Register your sensor

Tools