SensorObservationService development overview
Contents
1. Introduction
This page contains information about the implementation progress of the SOS. There is also a first draft of the main SOS documentation.
2. TODO list
(1) Integrate nightly cite-tests
(1) integrate current datastore configuration/implementation into core datasource (as for FeatureStore, CoverageStore, etc.) as ObservationDatastore
(1) use the core filter subsystem for parsing/representing expressions. Can everything be mapped to the ObservationDatastore model?
(2) implement PostgisObservationDatastore
- (2) BUG: after service reload (in tomcat) the derby database is locked for the first request. (Markus)
- (2) consistent exception handling (ogc exceptions): during xml parsing, sql exceptions,... (mostly done)
(2) make offering gml:id configurable?! (is generated from name (urn:::offering:1 -> ID_1))
(3) better documentation (esp. developer docs for the ObservationDatastore)
(3) check whether ovewriting the metadata from sos_configuration is done. ServiceProvider and ServiceIdentification
(3) om:result and swe:DataArray//swe:TextBlock format is not configurable (decimalSeparator, etc)
3. Shortbacks/ideas for improvements
The SOS standard is not perfect, the following list contains some points that are not well thought-out. These points are mostly relevant for client developers, since they restrict how to use the SOS.
- No real filter expressions. An SOS request contains multiple parts where you can apply filters,
namely eventTime, featureOfInterest and result. The problem is that the filters are restricted to the context. That means a eventTime only accepts temporalOps, a result comparsionOps and featureOfInterest spatialOps. As a result you can't use multiple property filter or even express statments like property is not null!
A measurement result can only hava one result value. Each result for each observedProperty must be encoded in a separate Observation -> lots of redundant information. As a result you can not encode measurements with multiple values in a 'lightweight' xml response. Requests that expect multiple result values should set the resultModel to Observation, which will return the data in a CSV style format.
- No restriction of the number of values, no sort order, no paging, no interpolation, etc. Thereby you can't control with how much data the server will respond. Depending on the offering it could be between zero or millions of results. Also you can't request the latest observation of an offering.
4. SOS Service
The SOS consist of two parts. The service (not web service!) that is independent of the OGC formats and the web service part. org.deegree.services.sos contains the non-web service part. New SOSServices are created by the SOSServiceBuilder that reads the SOS configuration (see SOS documentation). The service encapsulates multiple ObservationOfferings. These two classes define the main API of the SOS. To get a result from an offering you have to create some filters and query the ObeservationOffering with these. The model package contains classes that will be used to compose the results.
4.1. filter
The filters are simple beans for the arguments of a filter. That is, a DurationFilter only contains two Dates. This package must be harmonized with the org.deegree.model.filter package when the commons module further progressed. The comparsion filter (PropertyFilter) already wraps the ComparsionOperator from d3_commons.
4.2. model
Here are all classes that form a result that you will get from an ObservationOffering. A single measurement, values (Result) for one or more observed properties (Property) from a single time instant, is stored in a Measurement. Multiple Measurements for a single Procedure are stored in a MeasurementCollection. An Observation then collects these MeasurementCollections for multiple Procedures. The two collections take over the transition from one single datasource (table) to the output, grouped by procedures and properties.
4.3. storage
The storage module contains all database related classes. There are two ObservationDatastore implementations (see SOS documentation). The SQLFilterConverter translates the filter beans into SQL querys. The SQL statements are built with PreparedStatements to support different types of SQL databases. To allow the incremental creation of the statements a simple QueryBuilder is used.
A design target for the first SOS implementation was to support simple observation tables, without complex database models (with joins etc.) and to to keep the implementation simple. A later version may be based on the deegree features and datastores, but these parts are still to be implemented in deegree 3.
5. SOS Controller
The org.deegree.services.controller.sos package contains the web part of the service. The SOSController implements the OGC SOS service and translates between incoming requests (in XML or KVP) and the internal SOSService API. The XML parsing and export in implemented in XMLAdapter classes that exists for all request types.
6. Tests
If you improve the SOS and add something to the output you should check if the output is still a valid SOS response. The d3_test module contains some integration tests that will do this for you. They will issue some requests against an SOS service and validates the XML responses against the SOS schema and some simple XPath tests. See ogcvalidator.properties for configuration.