Determine default behavior for observation set returned when no time filter is specified

[GoogleCodeExporter]

Shane:
Previously the IOOS position has been that SOS GetObs requests without a time 
filter should return only the most recent observation for each matching 
procedure.The SOS 1.0 spec was vague on what these requests should return, but 
the SOS 2.0 spec is clear:

Requirement 30 - If an optional parameter of a GetObservation request is not 
specified by the client, the filter (represented by the parameter) shall not be 
applied to the observation set which will be returned by the SOS server.

The 52 North SOS allows the latest observations for each matching procedure to 
be requested using a latest keyword in the time filter:

<eventTime>
    <ogc:TM_Equals>
        <ogc:PropertyName>om:samplingTime</ogc:PropertyName>
        <gml:TimeInstant>
            <gml:timePosition>latest</gml:timePosition>
        </gml:TimeInstant>
    </ogc:TM_Equals>
</eventTime>

I suggest that we go this route, and use the latest keyword to request newest 
observations. Although the SOS 1.0 spec failed to properly specify this 
behavior, the spirit of web services has been to return all records matching a 
users request (although servers reserve the right to employ a result limit and 
throw an error if this limit is exceeded).

Kyle:
+1, we should do what the 2.0 spec says

The return should always be what was requested.  If the resulting request is 
too large for the server to handle, it should return an error, not a subset of 
the data.

Remaining thread is available here:
https://groups.google.com/d/topic/ioostech_dev/kH99E5eIjrI/discussion

Original issue reported on code.google.com by dpsnowde...@gmail.com on 24 Apr 2012 at 1:55

[GoogleCodeExporter]

Original comment by dpsnowde...@gmail.com on 24 Apr 2012 at 1:58

• Added labels: Type-Review

[GoogleCodeExporter]

For future reference, see this discussion thread:
https://groups.google.com/d/topic/ioostech_dev/kH99E5eIjrI/discussion

Original comment by emilioma...@gmail.com on 24 Apr 2012 at 7:57

[GoogleCodeExporter]

The finalized SOS 2.0 spec says the following (pg 35):

Requirement 39: A GetObservation request can result in a huge observation 
result set. If an SOS server implementation needs to prevent the delivery of 
such result sets to the client, since it would result in a response that is too 
big, the SOS server shall return an exception message as specified in Clause 15 
of [OGC 09-001] with exception code, meaning and "locator" value as defined in 
Table 23.

Note: If the client receives a ResponseExceedsSizeLimit exception as response 
to a GetObservation request, it should try to split the set of requested 
observations into smaller chunks and query them via a number of GetObservation 
requests with according parameters. For example, the request could apply a 
temporal partitioning via the GetObservationRequest.temporalFilter property. 
The service may also support additional operations to retrieve metadata about 
the stored observations, for example for which time ranges observations were 
generated by a given procedure.

Table 23 -  ResponseExceedsSizeLimit Exception
exceptionCode value: ResponseExceedsSizeLimit

Meaning of code: The service determined that the requested result set exceeds 
the response size limit of the service and thus cannot be delivered.

Original comment by sh...@axiomalaska.com on 27 Apr 2012 at 12:13

[GoogleCodeExporter]

I suggest that this issue is closed.  There is a place holder in the 
GetObservation page pointing back to this discussion.  As the Interface 
Description Document evolves, the errors for each request should be included in 
addition to information on the data formats.  For now, I think keeping a link 
to this discussion is fine.

This issue opens up a potential can of worms though.  Previously we had 
committed to implementing the SOS  1.0 spec, not SOS 2.0.  We also acknowledged 
that where possible, keeping in line with SOS 2.0 as much as possible was a 
good thing.  Especially, when SOS 2.0 corrected or clarified something that was 
wrong or vague in SOS 1.0.  This is a slippery slope and I hope we can clarify 
exactly which specification we are developing against soon.

Original comment by dpsnowde...@gmail.com on 27 Apr 2012 at 1:23

• Changed state: Done