Database Reference
In-Depth Information
SensorML,
Sensor Model Language
: An XML Schema to describe sensors
and sensor platforms. SensorML provides a functional description of
detectors, actuators, filters, operators, and other sensor systems.
O&M,
Observations & Measurements
: A specification for encoding ob-
servations and measurements from sensors.
TransducerML,
Transducer Markup Language
: A specification that sup-
ports real-time streaming of data to and from transducers and other sen-
sor systems. Besides being used to describe the hardware response char-
acteristics of transducers, TransducerML provides a method for trans-
porting sensor data.
SOS,
Sensor Observation Service
: This Web service interface is used to
request and retrieve metadata information about sensor systems as well
as observation data.
SPS,
Sensor Planning Service
: Using this Web interface, users can con-
trol taskable sensor systems and define tasks for the collection of obser-
vations and the scheduling of requests.
SAS,
Sensor Alert Service
: Through this Web service interface, users
are able to publish and subscribe to alerts from sensors.
WNS,
Web Notification Service
. This Web service interface allows the
asynchronous interchange of messages between a client and one or more
services (e.g., SAS and SPS).
In accordance with the philosophy of Web services in general, and the SWE
initiative in particular, data consumers should be concerned only with reg-
istries and service interfaces. For example, an SOS provider needs to be “dis-
covered” first through a registry mechanism, which is the OGC Catalog Ser-
vices (see Section 10.3.3) in the SWE context. Section 10.4 describes specific
elements from SensorML, O&M, and SOS that have been included in a proto-
type to chain data stream processing services. The general sequence of steps
to obtain sensor metadata and data is shown in Figure 10.4.
As an SOS service, the provider first provides a
capabilities
document as
a response to a GetCapabilities request by a client. This document includes
the identification of the provider and the description of the offered services,
that is, the available streams in the system, which are organized in the form
of
observation offerings
. An offering includes information about the period of
time for which observations can be requested, the phenomena being sensed,
and the geographic region covered by the observations. A schematic example
of a capabilities document is shown in Figure 10.5. (We use a simplified struc-
ture style to illustrate XML documents in this section; we use
symbols to
indicate relevant XML elements, and example values are shown in cursive.)
Once a client is interested in a particular geospatial data stream, it will
submit a DescribeSensor request to the provider. The response is a document
describing the sensor that generates the data stream. This response takes the
