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.
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.
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>
The InsertObservation operation allows clients to insert new observations for a registered sensor system.
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>
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>
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:
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.
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.
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:02:22 
