Dear Tim and other Colleagues,
Thank you for the document. My suggestions are:
(1) I don't think that the values 'lastestupdate', 'timespancount' and
'restriction' should be optional. I would make then fixed. In this way the
show parameter would default to 'None' and have no options in this version.
(2) Parameter show gives an idea that it controls the columns. Maybe rename
it to 'extracolumns' to make it clear that we talk about something optional
and, that would really change the amount of information in the output.
(2) I would rename 'mergetimespans' to 'mergeoverlaps'
(3) I suggest adding a parameter let say 'mergegaptolerance' that would
default to 0.0 (no merge) but could be like 5. And would merge gaps smaller
than 5s. This is useful for doing plots and other analysis of complete
station operation times.
(4) On the orderby parameter, I guess that there is a mistake with the
'lastestupdate' and 'latestupdate_desc' also, I found the options too long.
(5) The parameter 'limit' has only use on doing interfaces to browse
timespans, in this case it is missing and 'offset' parameter. Remeber that
it is always required to give start and end. I would add the 'offset'
parameter for sake of consistency. Alternatively remove both.
(6) Considering temporary network, it should be clear when you request a
timespans in an interval that the network code was re-used in two different
experiments. In this case, I would generate a GAP inevitably between
experiments and also, on the JSON I would expect a different 'datasource'
object even thou, network, station, location and channel matches. I.e. this
behavior should be explicit in the document.
This problem can also generate some other side effects. What is unique is
the pair of Network Code + Network Start Code. Maybe use the extracolumns
to request 'network start code' from the inventory.
With my kind regards,
Centro de Sismologia / IAG / USP
Rua do Matão, 1226, office D-211
+55 (11) 9820-10-930 ~ +55 (11) 3091-4743
Em seg, 25 de fev de 2019 às 19:47, Tim Ahern <tim<at>iris.washington.edu>
Thanks to all of the FDSN members that responded to the previous
discussion related to the Availability Service. *All 18 members* that
responded were in favor of the Availability Service concept.
As promised, here is the Draft Web Service Specification for the
fdsnws-availability service in a format similar to existing FDSN web
The delay in getting this to you was mine, sorry.
Can you please respond with comments to the entire list no later than
March 19, 2019 which is 3 weeks from today.
Thanks in advance
FDSN WG III
FDSN Working Group III
Topic home: 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/