Copyright © 2006 Open Geospatial Consortium – All rights reserved
81 location information. This seems inconsistent with OGC since location information is
key to most, if not all, of the current services being developed.
17.3 Implementation Comments
17.3.1 Intergraph Corporation
The Intergraph client uses a component designed to build request and format the responses. Specific properties are set on the object then either a GetCapabilities or
GetObservation request is made. The response is processed and formatted into a list that can be easily traversed.
The user simply supplies the SOS endpoint and the integrated client makes a GetCapabilities request as the initial communication to the service. Then the user is
presented with a list of offerings available from the given endpoint. The user selects the desired offering and supplies a timeframe in the form of a time instance or time range. A
GetObservation request is then constructed and a list of observations is returned detailing the phenomenon. The observation data is stored in the GeoMedia environment in the
form of a data query. By storing the data this way, the user can then view the information in a data window or plot the location in a MapView window.
17.4 Recommendations
Whether it is for military, local governments, or emergency response, the direct use of Sensor Observation Services will become an increasing part of the open web service
environments. It is for this reason that the interfaces for sensor observations must become more consistent. The response formats need to express location information
consistent with one another. This is especially true when it comes to the observation response. When a client wants to see if location information is included in the
phenomenon, it should be easy to locate by identifying a particular property or a particular phenomenon name.
It is understood that implementers may provide information back in different formats similar to the way a WMS can return an image as a jpeg or png format. However, a
client should be able to expect the responses from a GetCapabilities and GetObservation requests to be consistent to the point that both can be easily parsed and a determination
made as to its ability to handle the returned information. This involves more than simply informing the client of the format, but also where to obtain the location of the observation
and more consistency in the tags that are used to reference particular information.
82
Copyright © 2006 Open Geospatial Consortium – All rights reserved
18 Sensor Planning Service SPS
A Sensor Planning Service is used to task a particular sensor in order to get the desired observation. This can involve tasking a wind sensor to take a reading at a given time or
tasking a camera to zoom in for a better view through its video feed. This section documents the process of using a Sensor Planning Service directly from an Integrated
Client.
18.1 Direct Access to a Sensor Planning Service
Direct communication with a Sensor Planning Service allows an integrated client to control and task a given sensor.
A Sensor Planning Service Example In the following example, an integrated client is used to connect to and request
information published in a Sensor Planning Service.
Intergrated Client SOS
getCapabilities CapabilitiesDocument
DescribeCollection Sensor ID Taskable Properties Response
GetFeasibility Properties Feasible Not Feasible Response
Submit Request Task ID
Copyright © 2006 Open Geospatial Consortium – All rights reserved
83
Figure 25 Planning Service Interface
In this example a integrated client is provided with a URL of a Sensor Planning Service. The CapabilitiesDocument is retrieved via a GetCapabilities request. The
CapabilitiesDocument provides information detailing the available offerings. This information includes the type of phenomenon measured and the general location of the
sensor. Given a sensor id from the list of offerings, a DescribeCollection request is made to retrieve the phenomenon available for tasking on the sensor. The user enters the
information detailing the desired task and submits a GetFeasibility request to see if it is feasible to ask the sensor to perform the task. If it is, the user can then make a Submit
request to task the sensor. Although not available on all taskable sensors, many will communicate back to the user that the task has completed through a notification service.
18.2 Issues and Tradeoffs with Sensor Planning Service Communication
