deegree 3 sensorObservationService
NOTE: This deegree 3 component is currently unmaintained and the documentation may be out-of-date. If you're interested to become the maintainer of this module, please contact the deegree-devel list. |
1. Features of the implementation
- Implementation of the SOS 1.0.0 specification
Officially certified to be OGC compliant
Supports the core profile operations (GetCapabilities, DescribeSensor, GetObservation) plus GetFeatureOfInterest
- In addition to the official XML request specification, it contains the not-yet-released KVP spec
- Supports both SQL and binary data backends
- The database backend is comprised by either simple and continuous observation storages. The latter applies for regularly frequent observation times.
2. See a demo installation
TBD
3. Get it up and running in 5 minutes
TBD
4. Configuration basics
Like every other deegree 3 application, the configuration of the deegree sensorObservationService is based on the common deegree3/WorkspaceConfiguration concept.
The configuration of the sensorOvservationService is in src/main/webapp/WEB-INF/conf/:
- the main configuration file can be found at services/sos.xml
- auxiliary metadata and sensor information is placed in services/metadata.xml and services/utah-sensorml.xml (for the concrete utah sensor available in this demo) respectively.
- the observation stores can be found in datasources/observation
4.1. Service Configuration
In services/sos.xml, the ServiceConfiguration element lists the available offerings (that shall be concretely listed in datasources/observation). The <name> element inside an <Offering> shall reference the name of datastore offering, "<name>.xml". Further in the <Offering>, a procedure usually introduces a sensor, whose complete description shall be specified in the href attribute of the <Sensor> element.
4.2. Observation Offering Stores
Please take note that currently we only support Simple Observation stores. We acknowledge that Continuous and binary stores are also essential to the sensorObservatioNService and we are working towards making them available.
4.2.1. SimpleObservationDatastore
This datastore can be used if all observations are in one table and each observation is stored with a timestamp. You should set the name of the timestamp column with an Column element. If the timestamps are stored in another timezone than your locale one, you can change that with the db_timezone option.
4.2.2. ContinuousObservationDatastore
This datastore should be used if your observations have no timestamps, but are stored in a fixed interval (e.g. every hour). Each observation needs a unique id that increments with each observation. You configure the date of the first observation and its ID and the time interval between each observation. The date and interval are in ISO8601 format. If the IDs begin with 1, the option can be omitted.
4.2.3. BinarySQLObservationDatastore
In some use cases you need to store a large amount of measurements, e.g. one measurement every 10ms for each sensor. The other datastores require one database insert per measurement. In this case it would quickly sum up to thousands of inserts per second. The BinarySQLObservationDatastore can group multiple measurements into one database record. Each DB record needs a time stamp that corresponds to the time of the first measurement in this group. With ms_sampling_period you set the time between every measurement and with number_of_measurements the number of measurements that each group (DB record) contains. For correct filter behavior the groups should align in an interval of a second, minute, hour or day. The example below aligns to an interval of a second (ms_sampling_period * number_of_measurements = 1000ms = 1s).