[Requests] Comment to SOS 2.0 (OGC 10-037) from GWIE

Boisvert, Eric Eric.Boisvert at RNCan-NRCan.gc.ca
Tue Nov 30 06:33:03 EST 2010

Part A to be completed once.  Iterate Part B as needed.


1. Evaluator:
        Eric Boisvert (on behalf of the GWIE)
 Geological Survey of Canada
 eboisver at nrcan.gc.ca
 +01 418 654-3705
2. Submission: OGC® SOS 2.0 Interface Standard, OGC 10-037, 2010-09-02

1. Requirement: General

2. Implementation Specification Section number: General

3. Criticality: Minor

4. Comments/justifications for changes: [Comments]
 In dealing with large datasets, the SOS operations GetObservations, GetResults, GetObsevationById, and GetFeatureOfInterest can return many results (for example, there are time series in USGS groundwater data with 30000+ measurements). Clients which naively make routine queries of large datasets can be overwhelmed by the size of the response document. We think that there needs to be mechanisms in SOS that allow the client to query the SOS to get an estimate of the size of the dataset and to adopt a different workflow if the size is large.

Proposed Solution
The WFS specification uses a resultType parameter with a value of "result" or "hits" in 09-025r1 section We feel this is a good feature to add to SOS 2.0 to deal with large datasets, as it allows a client to get a count of the number of results returned before deciding whether or not it wants to deal with the entire result set. We think we should further expand this functionality to add more result level information, including the number of observations.  A smart client, using resultType (in concert with another proposal to add @maxObservations and @maxResults) can then decide to make a limited query rather than a full one.

We propose to include a "metadata" result type where the server would have the opportunity to report on several aspects of the result collection.  The content of that metadata section is to be refined in future work.
As for the parameter name, however, we cannot directly import the resultType functionality directly into SOS 2.0 because the resultType parameter is already taken in SOS 2.0. Thus, we have two choices: 

* Associate the WFS resultType functionality with a different parameter in SOS 2.0.
* Move the current SOS 2.0 resultType to a different parameter to allow resultType to be used as in WFS.

We consider that it was a mistake for SOS to reuse a parameter name that already existed in another specification and assign it a different behavior.  Therefore, we think that the second choice is better, as it maintains consistency with WFS. The first choice is potentially confusing to those less familiar with OGC standards because it results in the resultType parameter meaning different things in WFS and SOS.

Proposed Specification Modification: SOS 2   

* Change the current SOS 2.0 functionality which uses the "resultType" parameter to use the "responseResultType" parameter instead.
* Add an optional "resultType" parameter with two values -- "result" or "metadata" -- with "result" being the default if unspecified.
* Specify the behavior of SOS response to the "resultType" parameter as "A SOS can respond to a query operation in one of two ways (excluding an exception response). It may either generate a complete response document containing resources that satisfy the operation or it may simply generate an empty response container including a metadata section containing various parameters of interest, including the total number of resources that the operation would return. Which of these two responses a SOS generates is determined by the value of the optional resultType parameter. 

More information about the Requests mailing list