September 2010 Volume 13 - Webtraders

ArticleFigure 3: Schematic illustration of the SOS deploymentWhen exchanging sensordata a common data format is a core requirement. Such a data formatis provided by the O&M standard. It allows encoding of the measuredvalues and also related information such as the observed property, timeand location of a measurement.For interpreting sensor data theprovision of corresponding metadata is essential. Such sensor metadatacan be encoded using the SensorML standard. A SensorML descriptionof a sensor allows clients to understand the underlying measurementprocesses, gather information about data quality and assess thesuitability of a certain data set for a specific task. As well, metadata isan essential requirement for enabling the discovery of sensors and sensordata.TML is an additional data formatwithin the SWE framework offering a means of encoding sensor data aswell as metadata that is optimized for streaming data. In practice, however,TML is only rarely used.Based on this information model, SWE incorporates a service modelconsisting of specifications for web service interfaces which provide therequired functionality for accessing, tasking and alerting. It comprisesthe following parts:Sensor Observation Service (SOS): The most fundamental functionalitywithin the SWE framework is the access to sensor data and metadatawhich is offered by the SOS. It includes operations to request the datasets a user is interested in (i.e., based on thematic, temporal and spatialfilter criteria). The returned data is encoded using the data formatsof the SWE information model, usually O&M for the sensor data andSensorML for the corresponding metadata.Sensor Planning Service (SPS): Several sensors can be configured tomatch the needs of a user. This can comprise simple settings (e.g. thesampling rate of a thermometer) but also more complex parameters(e.g. the field of view of a surveillance camera). Providing a commonmechanism for controlling the measurement process is the core functionalityof the SPS.Sensor Alert Service (SAS) and Sensor Event Service (SES): In manycases sensors are used for building monitoring systems that dispatchalert notifications in the case of predefined conditions. The SWE frameworkcontains a means for defining such alert criteria and for subscribingto these alerts. The specification process for an alerting mechanismis not yet finished but the SAS and SES specifications represent thecurrent state of discussion on this topic.Web Notification Service (WNS): In several SWE applications there is aneed for asynchronous communication patterns. A common example isalerting: a user subscribes to a certain kind of alert and as soon as acorresponding condition occurs (potentially months after the subscription)an alert message must be delivered to the subscriber. Such functionalityfor asynchronous message delivery on various kinds of transporttechnology (e.g. e-mail, FAX, or SMS) is provided by the WNS.In summary, the SWE framework offers several basic data formats andweb service interface specifications that allow the full integration of sensorsand their data into spatial data infrastructures.The amount of open source as well as closed source software supportingthe SWE standards is continually growing. The SWE applicationsdescribed below were built using the implementations of the opensource initiative 52° North (www.52north.org). The 52° North SWE frameworksupports all SWE specifications with server as well as client implementations.Sensor Web in HydrologyThe conceptual background of SWE architecture was introduced in theprevious section; the following paragraphs describe how SWE componentsare deployed in practice in order to build productive systems.To illustrate the use of the SWE framework, three different use casesfrom the hydrology domain are described in detail. It should be notedthat these use cases possess a high degree of domain independencyso the deployment patterns can easily be transferred to other applicationareas.The presented system was first deployed in practice for theWupperverband, a public authority responsible for water managementin the area of the Wupper River in North Rhine-Westphalia, Germany. Anextended version of this system is currently in development for a projectundertaken by 52° North together with the Information TechnologyService Centre of the German Federal Ministry of Transport, Building andUrban Development at the Federal Waterways Engineering and ResearchInstitute (DLZ-IT) and the Wupperverband.In their daily business, both the Wupperverband and the DLZ-IT dealwith a broad range of sensor data. However, the structure of these sensornetworks is very heterogeneous which makes their integration intothe internal spatial data infrastructures and application systems a cumbersometask. To overcome the difficulties created by this heterogeneitythe SWE framework was applied.In particular, the following three use cases had to be resolved:1. Access to sensor data (i.e., time series data) and visualization of thisdata2. Dispatching of notifications (via e-mail or SMS) if certain user-definedmeasurement value combinations occur3. Controlling the sensors (in the specific case the focus was on thecontrol of pan-tilt-zoom surveillance cameras)The next three paragraphs illustrate how these requirements wereaddressed, relying on the different elements of the SWE framework.The first requirement, access to sensor data, was realized using theSensor Observation Service (SOS). Using the SOS, a common accessmechanism to the existing sensor data archives was established. This isa core benefit of using standardized access mechanisms: as soon as asensor is accessible through an SOS it can be linked to every SWE-compliantclient application without needing further customization. The practicallink to the sensor data archives is use-case specific. In the case ofLatest News? Visit www.geoinformatics.com43September 2010