[Requests] SOS 2.0 request: nonstandard Offering properties
ilinkuo at usgs.gov
Tue Nov 30 17:29:18 EST 2010
Part A to be completed once. Iterate Part B as needed.
David Blodgett <dblodgett at usgs.gov>
I-Lin Kuo <ilinkuo at usgs.gov>
2. Submission: OGC 10-037 SOS 2.0 Candidate standard
1. Requirement: Allow SOS GetCapabilities Offering to advertise additional
"procedure"-related properties and adjust search parameters appropriately.
One of the major changes from SOS 1 to SOS 2 was the elimination
of multiple procedures per Offering to just a single procedure per
Offering. Another was the clarification of the ambiguity in SOS 1.0's
usage of procedure "often an instrument or sensor [NRC1995] but may be a
process chain, human observer, an algorithm, a computation or simulator"
to an unambiguous "Pointer to a sensor system for which observations are
requested. It defines a filter for the procedure property of the
observations". This is a vast improvement from the point of view of
However, this restriction also removes the ability for the
Offering to advertise other important properties such as method (for
example, "stratified sampling"), instrument class (for example, "stream
gauge"), or algorithm (for example, "Monte Carlo") that was possible in
Also, the current design seems to lack consideration for the
situation when the observations dataset is a large system consisting of
tens of thousands of sensors/sites such as NWIS. In that case, how should
the dataset be advertised? There seem to be two alternatives given the
current specification, neither of which are satisfactory:
1) Advertise as a single ObservationOffering and use the
name of the sensor system, "NWIS", as the procedure.
2) Advertise as tens of thousands of ObservationOfferings,
one for each sensor/site, using the site id as the procedure value.
Alternative 1 renders the procedure parameter useless in
operations such as GetObservation, GetResult, and GetFeature because all
observations have the same value of procedure. Alternative 2 creates an
enormous GetCapabilities document.
In our ideal scenario, we'd like to advertise NWIS as one or two
ObservationOffering with many methods that would allow queries of the
"Get all observations of water level from NWIS that were measured
using a velocimeter on a stream"
"Get all NWIS observations of atrazine in water from a well via
Implicit in these two examples are sampledMedium (water), method
(velocimeter, gas chromatography), siteType (well, stream) that are
important metadata associated to an observation that currently do not fit
in ObservationOffering but clearly serve to characterize it. There are a
number of alternatives to handle this:
1) Add these properties as named children of
2) Add these properties as children of procedure
3) Provide an extensible mechanism to add
community-defined properties to ObservationOffering and add a way to query
these properties to the GetXXX operations.
The approach of 1 is unsatisfactory because while some of
these properties are general enough to be added to the list of named
properties of ObservationOffering, others are not. Also, this approach is
likely to open a Pandora's box of change requests to add elements to
The approach of 2 is unsatisfactory because these
properties are multiple and do not logically belong as children of
"procedure" = sensor system. These are properties of the
ObservationOffering. Also, this approach doesn't really solve the problem
but rather just moves the problem elsewhere into specifying an
implementation specific schema for "procedure", subject to the same danger
of Pandora's box above. Most importantly, the procedure parameter in
GetObservation and other similar observations do not allow querying on the
children of the "procedure" -- they only allow querying on exact match of
"procedure". That is a fatal problem when the sensor system is large.
Thus, our implementation proposal below is based on
2. Implementation Specification Section number: [General, #]
i) Add a <PropertyGroups> child to ObservationOffering
ii) The <PropertyGroups> element has <PropertyGroup> children
iii) The <PropertyGroup> element has a @name attribute
iv) The <PropertyGroup> element has either
a) <Value> children, or
b) it has an xlink:href attribute with a resolvable http
url to point to an xml document consisting of <PropertyGroup> with <Value>
children, and an human-readable descriptive xlink:title. This xlink:href
mechanism is preferred when the list of property values is long and
impractical to include in the GetCapabilities document directly
name="sampledMedium" xlink:title="media types" xlink:href="
v) Add an <offeringProperty> element to the request for SOS
operations GetObservation, GetResult, GetFeatureOfInterest which takes
multiple parameters of name-value pairs.
<sos:GetObservation version="1.0.0" service="SOS"
3. Criticality: [Major, Minor, Editorial, etc.]
4. Comments/justifications for changes: [Comments]
IT Specialist, Center for Data Analytics (CIDA)
USGS WI Water Science Center
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Requests