Implementation Plan: Sensor Planning Service (spec. version 2.0)
Documentation is in progress and will be updated step-by-step during development (see Implementation Plan for details).
52North currently is doing an implementation for the new SPS specification
version 2.0 which became an official standard in March 2011. In context of OGC's OWS-9
a first reference implemention shall be developed. This site intends to give you information about the current implementation status. Furthermore, you can find some information summarized from the specification.
- 52n-sps-1.0.0 (OGC SPS interface standard 1.0.0)
SPS development plan will have several implementation cycles. In each cycle more and more SPS components are developed matching the conformance classes defined by the specification. Following table gives an overview which conformance classes the SPS shall match after current implementation cycle is done:
Within the first implementation cycle SPS core will be developed.
The 52North SPS implemention is separated in several Maven modules. In combination with Spring technology you will be able to orchestrate functionality via loose coupling of SPS profiles and other components needed in the technology stack, e.g. database, communication binding (GET, POST, SOAP), etc.
Implementation will go partially go hand-in-hand with 52North OxFramework
version 2.0 (refactoring to get a collection of middleware components for the Sensor Web). The OxFramework
refactoring is in a very early state of development it evolves over time, and still provides the same functionality and API of its first version. However, the API will change over time achieving a more modular way in (re-)using Sensor Web functionality. This will help to create focused applications with small footprint.
Using the SPS
Why sometimes an OwsExceptionReport contains a collection of several OwsExceptions and sometimes it contains just one, even when a request provokes more than one (e.g. MissingParameterValue, InvalidParameterValue, ExtensionNotSupported,...)
During processing a request several things can fail. It is not always possible to collect all exceptions which may occur as in some point the logic will break and further processing makes no sense. However, sometimes it makes sense, for example when validating a set of parameter values. Obvisously it is an implementation issue if exceptions can either be collected and returned within an exception report or not. The 52°North SPS provides interfaces to let actual implementation decide if to collect OwsExceptions
Where do I start?
Which classes shall I implement?
This work is licensed under a Creative Commons Attribution 3.0 Unported License