Re: fdsn dataselect change
Tim Ahern
I understand the motivation but if one looks at this from the data requestor’s side rather than the data center’s side I think this would be the wrong approach, A data requestor wants to specify a start time and end time and get the data contained within their request, they are not concerned about how the data are packaged at the data center,
I think a better solution would be to modify SeisComp3 behavior and solve the problem for most of the implementations of dataselect that exist, I don’t think IRIS would want to change its current implementation that does honor the user specified times, So I would advocate for retaining the current specifications and change the SeisComp3 behavior,
Cheers
Tim Ahern
Director of Data Services
IRIS
IRIS DMC
1408 NE 45th Street #201
Seattle, WA 98105
(206)547-0393 x118
(206) 547-1093 FAX
> On Jul 10, 2017, at 8:47 AM, Pete Evans <pev...@gfz-potsdam.de> wrote:
>
> Hi all,
>
> On 07/06/2017 09:04 AM, Jean-Marie Saurel wrote:
>
>> I hope it's not too late, but I would like to submit this comment and
>> ask for a slight change in the webservice specification for starttime
>> and endtime options, regarding dataselect only.
>>
>> http://www.fdsn.org/webservices/FDSN-WS-Specifications-1.1.pdf
>>
>> Currently, for dataselect, it says (page 6) that starttime selects any
>> data on or after the value specified.
>> And endtime selects any data on or prior the value specified.
>> So the user have at most the data requested.
>>
>> I would like to suggest that, for dataselect only, the starttime selects
>> any data starting from a block including the starttime.
>> And endtime selects any data ending on a block including the endtime.
>> The user then have at least the data requested.
>
> This is what our (SeisComp) fdsnws-dataselect implementation
> in fact does. See the illustration at Note 5 on
> http://geofon.gfz-potsdam.de/waveform/webservices.php
>
> This means
>
> (1) our server doesn't have to break up mini-SEED records,
>
> (2) users may receive more data than they requested, but
> never less, if we have it.
>
> So GEOFON would support Jean-Marie's suggestion above, I think.
>
>
> P.
>
>
> --
> Dr. Peter L. Evans, Sect. 2.4 Seismology
> GFZ German Research Centre for Geosciences
> pev...@gfz-potsdam.de Tel. +49 (0)331 288-1261
> http://geofon.gfz-potsdam.de/ Fax +49 (0)331 288-1277
>
> ----------------------
> FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)
>
> Sent from the FDSN Message Center (http://www.fdsn.org/message-center/)
> Update subscription preferences at http://www.fdsn.org/account/profile/
Jean-Marie Saurel
I didn't made the initial comment from a datacenter point of vue, but
from a user point of vue.
> I understand the motivation but if one looks at this from the data
> requestor’s side rather than the data center’s side I think this would
> be the wrong approach, A data requestor wants to specify a start time
> and end time and get the data contained within their request, they are
> not concerned about how the data are packaged at the data center,
You're correct, they are not concerned about how the data is handled by
the datacenter.
But I think the data requestor usually prefers to have "at least" the
data requested than "at most", if data is available of course.
>
> I think a better solution would be to modify SeisComp3 behavior and
> solve the problem for most of the implementations of dataselect that
> exist, I don’t think IRIS would want to change its current
> implementation that does honor the user specified times, So I would
The IRIS webservices currently meet the specifications, and with the
proposed change, they will still meet the specifications, so no changes
will be needed.
If I'm correct, the IRIS dataselect always trim the data to the nearest
sample matching the request, and so gives "exactly" what the user needs.
As a side note, while the user is not concerned by the way the data are
handled in the data center, most advanced users wants the purest data
they can have and so would like to get the data as they were pushed in
the datacenter by the station operator, ie without any triming or data
modification.
Regards.
Jean-Marie SAUREL.
> advocate for retaining the current specifications and change the
> SeisComp3 behavior,
>
> Cheers
>
>
>
> Tim Ahern
>
> Director of Data Services
> IRIS
>
> IRIS DMC
> 1408 NE 45th Street #201
> Seattle, WA 98105
>
> (206)547-0393 x118
> (206) 547-1093 FAX
>
>> On Jul 10, 2017, at 8:47 AM, Pete Evans <pev...@gfz-potsdam.de
--
--------------------------------------
Institut de Physique du Globe de Paris
Observatoires Volcanologiques
1 rue Jussieu
75238 Paris Cédex 05
+33(0)183957437
France
Andres Heinloo
> I think a better solution would be to modify SeisComp3 behavior and
> solve the problem for most of the implementations of dataselect that
> exist, I don’t think IRIS would want to change its current
> implementation that does honor the user specified times, So I would
> advocate for retaining the current specifications and change the
> SeisComp3 behavior,
OK, we are changing the SC3 behavior.
According to the spec [1], page 6: "The starttime parameter should be
interpreted as selecting any data or information (time series samples,
earthquake origins, metadata epochs) at times on or later than the value
specified. Similarly, the endtime selects any data or information at
times on or prior to the value specified."
AFAICS, there are 2 possibilities to honor the spec:
(1) Return less data than the user requested.
(2) Trim first and last record. (Note: with very low sample rates we
still may have to return much less data than the user requested if there
is no sample at specified time.)
I guess (2) is preferred over (1) from users' perspective, but I'm not
sure about how to implement this correctly:
1. Should the quality indicator of trimmed records be set to "M"
(modified)? Even if it was previously "Q" (quality controlled)?
2. What about flags like "beginning of event", etc.? It is undefined if
they apply to the part of record that is cut off or retained.
Regards,
Andres.
[1] http://www.fdsn.org/webservices/FDSN-WS-Specifications-1.1.pdf