[webservices] response given known channel start

[Chad Trabant]

Hi Philip,

The starttime and endtime parameters (and before/after variants) are all applied to channel epoch times.  So even when requesting, for example, metadata at the station level, it is the channels that are used to identify which station epochs to return.  The documentation has been updated to reflect that, thanks for pointing out the error.

We had sketched out an idea where the time limit parameters are applied to various level metadata based on which NSLC parameters are supplied.  This idea was left in the docs and not removed (it has been now).  In practice we figured it would be more confusing than it's worth.  With our current implementation we return the "right" thing the vast majority of the time anyway.

Hopefully that clarifies the responses you were receiving from the service.

Chad

On May 3, 2013, at 2:39 PM, Philip Crotwell <crotwell at seis.sc.edu> wrote:

> 
> Just to make sure I am doing this correctly...
> 
> If I have a known channel start time, say 1995-03-21T17:16:00, then to limit the returned xml to be just the response for that single channel I should use endafter and endtime like this:
> http://service.iris.edu/fdsnws/station/1/query?network=IU&sta=ANMO&loc=--&cha=BHZ&endafter=1995-03-21T17:16:00&endtime=1995-03-21T17:16:00&level=response&nodata=404
> 
> In contrast, if I use starttime andendtime like this:
> http://service.iris.edu/fdsnws/station/1/query?network=IU&sta=ANMO&loc=--&cha=BHZ&starttime=1995-03-21T17:16:00&endtime=1995-03-21T17:16:00&level=response&nodata=404
> 
> then I get both the channel I want, as well as the one that was operational immediately before the time I am interested in.
> 
> But the docs are confusing as they say that:
> 
>       startbefore, endbefore, startafter, endafter
> 
>       These criteria are applied at the station level, regardless of which level is requested or which channel, network, location,    
>        station filters are used.
> 
> Which I think means that my above query should not work, even though it does seem to, as the time restriction I am trying for is on the channel times and there was one station operating over this time that had 5 channels, but both of my above queries return fewer (one or two).
> 
> The fdsn ws specification doesn't make the way time params are interpreted very clear as it only says that these 4 times "Limit to metadata epochs...", but does not say they are limited to the station or in fact what they are applied to. I am guessing that the iris docs are wrong, but the fdsn spec also seems incomplete.
> 
> The other confusing thing to me is that the iris docs talk about how the time criteria apply based on whether there is a channel or location or station parameter and ignores the level parameter, but i dont' see any similar idea in the fdsn spec. Is this an iris implementation detail, or is the spec incomplete? I feel like the most natural way is to have the time criteria apply to the level asked for, but maybe I am missing something. Some experimentation seems to show that the level param is actually what controls the time aspect, but not totally sure.
> 
> IMHO, this whole starttime, endtime, startsbefore, endbefore, startsafter, endafter system seems really confusing. All the other systems of querying this type of data in the past have used a simple start/end window, and the "effective times" of the channel-like objects were "half open intervals" that included their begin, but not their end. In math notation, [start, end), meaning if you asked for an interval where the start/end were the same, you got the single channel that you likely wanted. I am not sure the added complexity and non-intuitiveness of these 6 time query parameters is really worth it.
> 
> Can someone clarify how all this is supposed to work?
> 
> thanks,
> Philip
> _______________________________________________
> webservices mailing list
> webservices at iris.washington.edu
> http://www.iris.washington.edu/mailman/listinfo/webservices

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iris.washington.edu/pipermail/webservices/attachments/20130510/f668c70f/attachment-0001.htm>