Document Actions
org.gvsig.sensors.mobile
SOS-T analysis
Introduction
Description
The most common use with a mobile device is field data collection. Nowadays gvSIG Mobile allows read some services like WFS, but only can read small layers. Read the heavy SML and O&M sensor data files from SOS server with gvSIG Mobile, which runs in devices with low memory isn’t very handy. This is the reason why is not recommended the use of gvSIG Mobile like a sensor data consumer .
On the other hand, the SOS protocol includes the transactional profile, with register and insert operations, adding new sensors and observations in SOS services. This profile is called SOS-T, used by sensor data producers in order to add the given measures. Next sequence diagram shows a typical sequence of operations:
Both RegisterSensor and InsertObservation requests are simple XML's, therefore upload them from gvSIG Mobile to SOS server is possible and very useful, as the mobile device can publish sensor data right away from field.
This document analyses gvSIG Mobile SOS-T project. The goal is add the capability of using gvSIG Mobile as a sensor, allowing upload sensor data directly from gvSIG Mobile to SOS services.
But this sensor data can be get from different sensors that are integrated in the device. The list of supported sensor data providers must be extensible and we are only going to provide an implementation for the GPS, that can generate waypoints every time in a configured period. This data could be sent to a SOS server, which can stores waypoints as positions or just a single data value.
The user will choose the SOS server to publish through a GUI. Then, gvSIG will register the sensor into the SOS server if it didn’t exist yet. Once configured the time interval and selected the right sensor which provides the measures, the program will begin uploading observations every time automatically.
Requisites
New plug-in (stand alone jar and/or bundle) for gvSIG Mobile which allows publish sensor data (example: GPS positions) from PDA.
Development Following OGC SOS standard in order to connect to a SOS server with transactional extension implemented (example: 52º North).
Allow register new sensor in a SOS server. (add new offering, insert sensor operation)
Also allow insert observations into a registered sensor instance. (insert observations into procedure from an offering)
The time between observations have to be configured by the user.
GPS data source have to be supported as data source from gvSIG Mobile sensor input.
Source Code compatible with gvSIG Desktop.
The system uses simple templates in order to send the requests to the server. The goal is not the creation of a complex system to edit all the possible requests.
- Simple GUI for gvSIG Mobile, allowing the user to:
- Configure period time observations and sensor to publish.
- Insert/Choose SOS server URI to insert the observations.
- Select the (procedure) sensor ID from a server to add new observation data.
- Tests.
Context
Next context diagram shows the gvSIG Mobile components with the new sensor components with the suffix. The GPS sensor provides the data and time information to the sensor library component, then the SOS remote service provider give to gvSIG the communication channel, there are one sensor ui and the osgi bundle extension too, for give user interface and configure the SOS server.
- org.gvsig.mobile.remoteclient.sos: client for remote clients that manage the SOS-T protocol allowing register new sensors and upload new observations.(only transactional operations)
- org.gvsig.mobile.extension.sensor: wrapper component (osgi bundle) to manage user gui and add SOS transactions configuration.
- org.gvsig.mobile.sensor.ui: new graphics components added to manage sensor configuration.
- org.gvsig.mobile.sensor.lib: standalone library which manage sensor functionality.
General Overview
The sensor project contains different components that can be studied independently. This components provides their own interface that can be used by the consumer. One of these components can be classified as libraries, others as a extensions and finally as user interfaces.
org.gvsig.mobile.remoteclient.sos will be used by a implementation of org.gvsig.mobile.sensor.lib.api.
Libraries
- org.gvsig.mobile.sensor.lib: Standalone sensor library.
- org.gvsig.mobile.sensor.lib.api: Application programing interface that is used by other component to select a sensor provider and start to upload data. It has methods to retrieve all the registered sensor data providers, to retrieve all the previous used SOS servers, and to create a Service that is the responsible to upload data to the server.
- org.gvsig.mobile.sensor.lib.spi: Programing interface to add sensor data providers. It has methods to register providers and methods to retrieve the list of registered providers. It defines the sensor data provider API.
- org.gvsig.mobile.remoteclient.sos: The SOS protocol manager. It contains utilities to create a SOS request as using templates. created for every configured sensor and to parse the SOS replies (ID Sensor returned). The GPS provider uses it to connect to the server, send sensor data and retrieve server responses.
- org.gvsig.mobile.sensor.prov: Providers implementations using org.gvsig.mobile.sensor.lib.spi.
- org.gvsig.mobile.sensor.prov.gps: GPS sensor provider implementation of org.gvsig.mobile.sensor.lib.spi methods adding gps registering, GPS offering, procedure and insert new positions as observations.
Extension
- org.gvsig.mobile.extension.sensor: This component let the user select the server, register the sensor on it and start to upload data every time configured.
UI Components
- org.gvsig.mobile.sensor.ui: User Interface components.
- org.gvsig.mobile.sensor.ui.api: New methods to add the graphics components to show sensor configuration.
Detailed View
org.gvsig.mobile.remoteclient.sos
gvSIG Mobile will receive sensor measures, due to upload them to the SOS server, the data have to be formatted as a XML file. In order to build the answer there will be several templates with some wildcards characters, these wildcards allow be substituted with the sensor data, time, server or sensor id.
First of all the Sensor have to be registered by the SOS server. In order to do that, the SOS-T Library will try to register the sensor to the server. Next the insert sensor operation are explained.
InsertSensor Operation
The InsertSensor operation allows a client to register a new sensor system at the SOS. The operation is part of the Sensor Insertion requirements class. Sensor observations can only be inserted for sensors that have first been inserted in the SOS.
InsertSensor XML Example
52º North it’s the most complete implementation of the OGC SOS standard, because implements the transactional profile. If we take a look to the examples can think out the minimum useful template.
<?xml version="1.0" encoding="UTF-8"?>
<RegisterSensor service="SOS" version="1.0.0"
xmlns="http://www.opengis.net/sos/1.0"
xmlns:swe="http://www.opengis.net/swe/1.0.1"
xmlns:ows="http://www.opengeospatial.net/ows"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:gml="http://www.opengis.net/gml"
xmlns:ogc="http://www.opengis.net/ogc"
xmlns:om="http://www.opengis.net/om/1.0"
xmlns:sml="http://www.opengis.net/sensorML/1.0.1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/sos/1.0
http://schemas.opengis.net/sos/1.0.0/sosRegisterSensor.xsd
http://www.opengis.net/om/1.0
http://schemas.opengis.net/om/1.0.0/extensions/observationSpecialization_override.xsd">
<SensorDescription>
<sml:SensorML version="1.0.1">
<sml:member>
<sml:System xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<sml:identification>
<sml:IdentifierList>
<sml:identifier>
<sml:Term definition="urn:ogc:def:identifier:OGC:uniqueID">
<sml:value>urn:ogc:object:feature:Sensor:### SENSOR IDENTIFIER WILDCARD ###</sml:value>
</sml:Term>
</sml:identifier>
</sml:IdentifierList>
</sml:identification>
<sml:capabilities>
<swe:SimpleDataRecord>
<swe:field name="status">
<swe:Boolean>
<swe:value>true</swe:value>
</swe:Boolean>
</swe:field>
<swe:field name="mobile">
<swe:Boolean>
<swe:value>true</swe:value>
</swe:Boolean>
</swe:field>
</swe:SimpleDataRecord>
</sml:capabilities>
<sml:position name="### SENSOR NAME WILDCARD ###">
<swe:Position referenceFrame="urn:ogc:def:crs:EPSG:4326">
<swe:location>
<swe:Vector definition="urn:ogc:def:vector:OGC:location">
<swe:coordinate name="latitude">
<swe:Quantity axisID="Y" definition="urn:ogc:def:phenomenon:latitude">
<swe:uom code="deg" />
<swe:value>### LATITUDE VALUE WILDCARD ###</swe:value>
</swe:Quantity>
</swe:coordinate>
<swe:coordinate name="longitude">
<swe:Quantity axisID="X" definition="urn:ogc:def:phenomenon:longitude">
<swe:uom code="deg" />
<swe:value>### LONGITUDE VALUE WILDCARD ###</swe:value>
</swe:Quantity>
</swe:coordinate>
<swe:coordinate name="altitude">
<swe:Quantity axisID="Z" definition="urn:ogc:def:phenomenon:altitude">
<swe:uom code="m" />
<swe:value>### ALTITUDE VALUE WILDCARD ###</swe:value>
</swe:Quantity>
</swe:coordinate>
</swe:Vector>
</swe:location>
</swe:Position>
</sml:position>
<sml:outputs>
<sml:OutputList>
<sml:output name=”### OFFERING NAME WILDCARD ###”>
<swe:Quantity definition="urn:ogc:def:phenomenon:OGC:1.0.30: ### PHENOMENON ID WILDCARD ###/">
<gml:metaDataProperty>
<offering>
<id>### OFFERING IDENTIFIER WILDCARD ###</id>
<name> ### OFFERING NAME WILDCARD ###</name>
</offering>
</gml:metaDataProperty>
<swe:uom code="grades"/>
</swe:Quantity>
</sml:output>
</sml:OutputList>
</sml:outputs>
</sml:System>
</sml:member>
</sml:SensorML>
</SensorDescription>
<ObservationTemplate>
<om:Measurement>
<om:samplingTime/>
<om:procedure/>
<om:observedProperty/>
<om:featureOfInterest></om:featureOfInterest>
<om:result uom=""></om:result>
</om:Measurement>
</ObservationTemplate>
</RegisterSensor>
InsertObservation Operation
The InsertObservation operation allows clients to insert new observations for a registered sensor system.
Workflow of Observation Insertion
A sensor data producer first requests the service metadata before new observations can be inserted into an SOS.
- The service metadata is retrieved by invoking the GetCapabilities operation. The returned Capabilities document contains, within the Contents section, the procedures which are registered at the SOS. The InsertionCapabilities section lists the observation types and result types which are supported by the SOS for insertion.
- If it has not been registered at the SOS, the InsertSensor operation is called to insert the procedure description of the observation procedure. The SOS returns the ObservationOffering to which the procedure has been assigned.
- Finally, the observation can be inserted using the InsertObservation operation, by specifying the ObservationOffering to which it shall be uploaded.
Next are shown the minimum working XML templates that works with 52º North server.
<?xml version="1.0" encoding="UTF-8"?>
<InsertObservation xmlns="http://www.opengis.net/sos/1.0"
xmlns:ows="http://www.opengis.net/ows/1.1"
xmlns:ogc="http://www.opengis.net/ogc"
xmlns:om="http://www.opengis.net/om/1.0"
xmlns:sos="http://www.opengis.net/sos/1.0"
xmlns:sa="http://www.opengis.net/sampling/1.0"
xmlns:n52="http://www.52north.org/1.0"
xmlns:gml="http://www.opengis.net/gml"
xmlns:swe="http://www.opengis.net/swe/1.0.1"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/sos/1.0
http://mars.uni-muenster.de/sosmobile/trunk/sos/1.0.0/sosInsert.xsd
http://www.opengis.net/sampling/1.0
http://schemas.opengis.net/sampling/1.0.0/sampling.xsd
http://www.opengis.net/om/1.0
http://schemas.opengis.net/om/1.0.0/extensions/observationSpecialization_override.xsd"
service="SOS" version="1.0.0">
<AssignedSensorId>urn:ogc:object:feature:Sensor:### SENSOR IDENTIFIER WILDCARD ###</AssignedSensorId>
<om:Measurement>
<om:samplingTime>
<gml:TimeInstant>
<gml:timePosition>2008-04-01T19:44:15+00</gml:timePosition>
</gml:TimeInstant>
</om:samplingTime>
<om:procedure xlink:href="urn:ogc:object:Sensor:### SENSOR IDENTIFIER WILDCARD ###" />
<om:observedProperty xlink:href="urn:ogc:def:phenomenon:OGC:1.0.30: : ### PHENOMENON ID WILDCARD ###" />
<om:featureOfInterest>
<n52:movingObject gml:id="human1"/>
</om:featureOfInterest>
<om:result>
<!--
The position of one tracking point. (Unfortunately, we do not
support 3d coordinates, yet)
-->
<gml:Point srsName="urn:ogc:def:crs:EPSG:4326">
<gml:coordinates>### SENSOR VALUES TO INSERT ###</gml:coordinates>
</gml:Point>
</om:result>
</om:Measurement>
</InsertObservation>
org.gvsig.mobile.sensor.lib.api
This component has to provide an API to the library consumer for upload sensor data. This API includes a Locator that is the entry point to the library that is used to get the Manager instance, following the project structure defined in gvSIG 2.0. In this case we have the SensorLocator, that can be used to register or get the instance of the SensorManager that is used by the library consumer to manage the library.
The SensorManager offers to the library consumer the possibility to retrieve all the sensor data providers that has been previously registered using the SPI interface. It offers the functionality to retrieve the list of servers that can be used for a concrete provider. And it also can be used to create an instance of a service that can be used to upload sensor data that is called SensorDataUploadService.
This service needs a sensor data provider, a server URL and a time period. When this service starts, it sends a RegisterSensor request to the server using a template (optional, because it could be previously registered) and if the reply is ok it gets the measurements for the provider and creates a InsertObservation request using this measurement and the template. This last request is send every time that the time period finish.
Next sequence diagram shows how the system works:
In order to manage the different templates defined for the SOS operations configured for every sensor defined in every server. This task it’s resolved building new XML files to relate the different wildcards with their values and the container SOS server. Then the gvSIG Mobile SOS-T plug-in can get persist the sensors configured values.
Next XML is an approximation to these files. This is just an example to understand the object model. The final XML could be different and it could be created using the standard gvSIG persistence.
<SensorLibrary>
<SensorProvider name="GPS">
<Templates>
<RegisterSensor>RegisterSensorGPSGenericTemplate.xml</RegisterSensor>
<InsertObservationTemplate>InsertObservationGPSGenericTemplate.xml</InsertObservationTemplate>
</Templates>
<Servers>
<Server url="http://www.myserver1.com/sos" id="GPS Server1" registered="true">
<Templates>
<RegisterSensor>RegisterSernsorGPSForServer1Template.xml</RegisterSensor>
<InsertObservationTemplate>InsertObservationGPSForServer1Template.xml</InsertObservationTemplate>
</Templates>
</Server>
<Server url="http://www.myserver1.com/sos" id="Temperature Server1" registered="true">
<Templates>
<RegisterSensor>RegisterSernsorTemperatureForServer1Template.xml</RegisterSensor>
<InsertObservationTemplate>InsertObservationTemperatureForServer1Template.xml</InsertObservationTemplate>
</Templates>
</Server>
<Server url="http://www.myserver2.com/sos" id="GPS Server 2" registered="false">
<Templates>
<RegisterSensor>RegisterSernsorGPSForServer2Template.xml</RegisterSensor>
<InsertObservationTemplate>InsertObservationGPSForServer2Template.xml</InsertObservationTemplate>
</Templates>
</Server>
</Servers>
</SensorProvider>
</SensorLibrary>
org.gvsig.mobile.sensor.lib.spi
This component provides the API necessary to manage the sensor data providers. It has a SensorProviderLocator that is the entry point to the library and it is used to get the instance of the SensorProviderManager. This object is a singleton that can be used for:
- Register all the implementations of sensor data providers in loading time. These implementations are registered using the standard Library mechanism. The registered object is a Factory called SensorProviderFactory that is able to create a concrete SensorProvider.
- Retrieve a list of all the provider names that ara registered in the system.
- Create a SensorProvider using a name.
- Return the list of variables that the provider is able to create (they are used to replace the wildcards in the template)
The SensorProviderFactory is the responsible to create a SensorProvider. It knows the sensor name and it provides a basic template for both RegisterSensor and InsertObservation that are used if the templates are not find in the file system.
There are different implementation of SensorProvider's. Every implementation is the responsible to get data from a physical sensor (or from other mechanism like a web server, other library...) and return a list ok key-value pairs with the retrieved values. This list of key-value pairs is used by the consumer (the SensorDataUploadService in this case) to replace the values in the template that is sent to the server.
Next sequence diagram shows how the system works:
org.gvsig.mobile.sensor.prov.gps
This component is just a provider for a GPS device. It uses the libLocation library that has been depeloped for gvSIG Mobile. I gets the Latitude, Longitude and Altitude from the GPS and returns this three values that can be used by the consumer to create a InsertObservation request and send it to the server.
org.gvsig.mobile.sensor.ui.api
This component is the API that has to be used for the application to get a graphical component that is the responsible to comunicate the user actions with the API of the library.
org.gvsig.mobile.extension.sensor
This module contains the bundle activator to and links the user interface which adds the new user actions. wrap all the dependencies in a gvSIG Mobile extension.
