Latest revision as of 19:44, 7 November 2017

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

CSM data platform

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 about CSM servers, later it describes the accepted XML format for data posted from mobile app or sensors platform to CSM sever.

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, 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.

The interaction between these components is modeled within below figure:-

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. Below figure shows the SEDS data model.

As it shown above figure, the SEDS platform offers two types of observations to be received and stored on the storage, being:-

• Measurement
• Questionnaire

The measurement object is used for storing less complex observations with values as decimals. An example for XML format used to send measurements observations from a sensor to the SEDS platform is provided here.

Inclusion of existing information

• Fixed stations
• Pollen information for

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 libraries for Android and iOS applicability
• Google Map API for showing the map
• Web API for location, visualisation and design issues

A detailed list of all libraries is available here...

List of Functions

Before the checking of functions, it is recommended to have an overview of mobile app provided services. This overview could be by running the app and checking this services directly, or by checking its description within related deliverables, such as D 4.6. Used functions within CSM mobile app could be classified based on its purposes and hosted file name, as it appears below. Most of hosted code files, mentioned below, are available in code repository within www/js folder. An example of apps include:

• settings: Wifi, GPS, ..
• feedback: feelings, comments,...
• graphs: heat map, tracking, ...

A list of all function is available here...

Github repository of App code

https://github.com/unikdrift/Oslo-AirQuality

Supported Sensors

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

• DunavNET, http://www.dunavnet.eu/, measures: NO, NO2, O3, CO, CO2, Temperature, Relative humidity, atmospheric pressure

• UrVaMM Ingenieros Asesores, http://www.ingenierosasesores.com/index.php, measures: CO, NO2, temperature, relative humidity, speed, fuel consumption, GPS

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

• AQMesh, http://www.aqmesh.com/, measures: NO, NO2, O3, CO, PM10, PM2.5, temperature, relative humidity, atmospheric pressure, and noise

• LEO, http://citisense.ateknea.com/, measures: NO, NO2, O3

Register your sensor

Before sending of measurements or questioners to Citi-Sense-MOB cloud (SEDS) platform, sending device needs to be registered on this 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, in case stakeholder needs to make many registration for many sensors. s/he should contact Snowflake to agree with them on user name and password. Then S/he could make these registration by posting device data using XML format shown above to WFST. This posting could be done in different ways, such as using browser based tool, like REST console or via embedded code. Another option user could send sensor data to Snowflake and they make the registration on SEDS platform (http://www.snowflakesoftware.com/)

Since CSM project used a particular set of AQ sensors 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 within below table. :-

Sensors Monitoring using CSM APP

If the user wants to monitor his/her sensor measurements with CSM mobile app, s/he needs to contact UNIK or Movation to add sensor to visualized sensors set by mobile app , via below email addresses:-

seraj@movation.no or josef.noll@its.uio.no