[FrontPage] [TitleIndex] [WordIndex

SensorObservationService development overview

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

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.

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.


2018-04-20 12:05