Copyright © 2006 Open Geospatial Consortium – All rights reserved
79 B TML Observations
In the next example, the response to the request is an endpoint to a TML stream. An integrated client is provided with a URL of a Sensor Observation 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 GetObservation request is made to
retrieve the endpoint to the TML stream provided by the sensor. The integrated client connects to the TML stream and reads the latest sensor readings.
Intergrated Client SOS
getCapabilities CapabilitiesDocument
GetObservation Sensor ID, Query TML Stream endpoint
TML Stream Connection TML
TML Stream
Figure 24 Observation Retrieval TML
17.2 Issues and Tradeoffs with Sensor Observation Service Communication
17.2.1 Observation Response Types
One of the difficulties encountered during the integration of the client with the Sensor Observation Service was the variety of response types. There are two ways in which
responses can affect a client:
80
Copyright © 2006 Open Geospatial Consortium – All rights reserved
A The format of the observation response The format of the observation response can vary in many different ways. The common
observation model allows this by providing a “header” that describes the format of the content. Although this “header” provides a mechanism for interpreting the data, it leaves
the format very open for the implementer to create a customized response. This can be good in that it is open enough to allow for the many types of sensor data. But it places a
lot of burden on the integrated client to be able to understand and process a number of formats.
B The format of the response Another issue with the SOS response is seen in the format of the response itself. The
integration of the client and the SOS began by examining the responses from different service providers. What was discovered was that one provider’s response was in the
form of the Common Observation Model while the other was in the form of a TML stream. It is understood that this provides mechanisms to “snapshot” the sensor’s
observation as well as “stream” its data continually. However, from a client’s perspective, this seems to be two different implementations and requires a client to
develop software to handle the responses through differing paths.
17.2.2 Geolocation Information
Due to the variety of sensor types, it can be difficult to determine the location of the sensors. Part of the reason for this is the software’s need to differentiate between the
location of the sensor and the location of the observation. For example, an in-situ sensor that represents a weather station measuring temperature would be represented as a point
with its geo-location information identified in the Capabilities response. Although the sensor can measure a number of phenomena, it is still a single sensor at a single location.
However, a group of systems can be built such that they are represented as a single offering but are treated as multiple sensors. In this case, the geo-location is represented
as a bounding box showing the complete area covered by all sensors in the offering. It appears that these types of sensors identify their geo-location as part of the phenomenon
in the GetObservation response. However, there is no requirement for location to be part of that list of phenomenon and if it is included, the format could take a number of
formats.
An integrated client must first determine if geo-location information is available from the GetCapabilities response. If it is available, does it actually represent the location of the
observation? To answer that question, the client must then access the available phenomena and determine if the observation includes location information. This is
currently being accomplished by looking for phenomenon with names resembling Latitude, Longitude, Height, Altitude, etc. However, again there is no required way to
represent geo-location information. The burden of determining this is placed on the client software with no help in determining what or how should be searched to find the
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
