Thread: response given known channel start

Started: 2013-05-04 00:39:49
Last activity: 2013-05-10 23:15:19
Topics: Web Services
Philip Crotwell
2013-05-04 00:39:49
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

  • Chad Trabant
    2013-05-10 23:15:19

    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


08:55:59 v.01697673