SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 216 of 233
In the context of SensorSA, the combination of EO and in-situ data is best performed using a Web Processing Service WPS see section 8.4 or Sensor Planning Service SPS see section
8.2.3 to access EO and in-situ data stored in Sensor Observation Services SOS and store the processed fused results also in a SOS as illustrated in Figure 10-29.
10.9.3.2 Approach
The typical steps needed to deploy a SOS containing EO derived data are as follows: 1. First, EO images EO data products covering the area of interest and period of interest
have to be orderedpurchased from a satellite or air-borne image provider. These images are in a certain format and are the result of instrument specific processing performed by
the EO image provider to reformat, time re-order, calibrate, and geo-locate the raw data.
2. The EO images are then submitted to thematic processing manual or semi-automatic to extract the observations related to the desired phenomenon with the appropriate level of
quality. 3. Finally, these observations are stored in an SOS server along with the associated quality
meta-information and SensorML descriptions.
In the geo-hazard example considered above, high resolution ASAR images produced by
the ENVISAT satellite and covering the area of interest e.g. city of Barcelona can be purchased from Spot Image. Using rather complex interferometry processing, ground displacements maps
interferograms can be generated by comparing all the images to one of those images chosen as a reference and by making topographic adjustments using a digital elevation model DEM.
Stable reflector points permanent scatterers presenting a good signalnoise ratio reflectivity can then be extracted and their displacements can be stored along with the associated quality
metada and SensorML description resulting from all the above processing in a database that is directly accessed by a SOS server.
The typical steps needed to deploy a SOS containing in-situ data are as follows:
-
Acquire in-situ data in the area of interest for the period of interest and, after possible sensor specific processing, store this data in a database along with its quality parameters.
This data is geo-located either directly or indirectly through the location of the sensors.
-
Publish the in-situ data with the associated quality meta-information and SensorML descriptions in a SOS server by accessing the acquisition database directly or by
feedinginserting the data into the SOS data store.
In the geo-hazard example considered above, automated monitoring systems, combining a theodolite measuring angles and a distance measuring device aiming at prismatic optical
targets attached to structures e.g. buildings to be monitored, can be used to measure the movement in X, Y, and Z directions of the targets on a cyclic basis e.g. every 30 minutes.
After filtering for night and day structure breathing and vibrations due to traffic, the acquired target displacement data can be stored in a database along with the location of these targets.
This database can be accessed directly by a SOS server supporting two result models: one for temporal coverages and one for spatial point coverages.
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 217 of 233
Once the EO and in-situ data is available from SOS services, a WPS or SPS based data processing e.g. fusion service can be used to implement the processing chain shown above in
Figure 10-29. The processing service will typically use the quality meta-information found in both EO and in-situ SOS services to judiciously combine their observations and produce new
observations with better spatial andor temporal coverage and quality. These new observations can be stored in an SOS could be one of the input SOS services along with uncertainty
information which is essential for decision making.
In the geo-hazard example considered above, inverse distance interpolation spatial fusion limited to a given radius e.g. 30 m can be applied to improve the accuracy of the EO
derived vertical displacement observations at the selected stable reflector points. Statistical information uncertainty related to the interpolated displacements can also be generated and
published along with the updated observations in a Fused SOS server with the same structure as the EO and in-situ SOS servers.
10.10. Integration of Mobile Sensors
Of the sensor network scenarios shown in Table 4-1 in section 4.5, all but one involve mobile sensors:
no. 2. Mobile sensors and fixed or mobile data logger
no. 3. Mobile sensors moving in different service networks
no. 4. Mobile sensor cluster on vehicles e.g. on ships - block data transfer on demand
no. 5. Mobile earth observation sensors satellite, airborne
no. 6. Mobile sensors with their own IP address
For a mobile sensor the location of the sensor is time dependent. In addition, the associated sampled feature and or sampling point of a feature of interest are normally time dependent.
For scenarios 2- 4, observation data is transferred from the sensor to a “data logger”. For
simplicity, it is assumed that each data logger has exactly one associated SOS instance where the observations are published. The protocol between the sensors and data logger is proprietary and
outside the scope of SensorSA. The data logger shall register its SOS instance with a catalogue service. The result of a SOS getCapabilities request to the data logger provides a list of sensors
associated with the data logger and for what sampling or result times observations are available. The catalogue service can subsequently use describeSensor operations to acquire information
about the sensors associated with a data logger. The data logger may have no or only partial knowledge about which sensors are still alive. A catalogue service may compile information as
to the location of sensors in order to support network management.
Scenario 3 differs from scenario 2 in that a sensor may transfer its observation data to several different data loggers, and hence to several SOS instances. If the observations of a given
sensor relate to the same feature of interest, then there are two approaches to dealing with this in applications requiring all data for this feature:
-
A cascading SOS may be employed to merge the observations from the different SOS instances of the data loggers. Thus applications may need to access only the cascading
SOS. This assumes that the cascading SOS has the necessary knowledge of relevant underlying SOS instances.
