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:

Sensor Data Consumer Sequence Diagram. Copyright © 2007 Open Geospatial Consortium, Inc. All Rights Reserved

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

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.

images/context_diagram_mobile.png

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.

images/ComponentesSOS-T.png

org.gvsig.mobile.remoteclient.sos will be used by a implementation of org.gvsig.mobile.sensor.lib.api.

Libraries

Extension

UI Components


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.

  1. 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.
  2. 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.
  3. 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:

images/SequenceDiagram.png

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:

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:

images/SequenceDiagramSPI.png

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.

Cached time 11/21/13 18:01:40 Clear cache and reload