International Federation of Digital Seismograph Networks

Thread: Availability Service Specification - next steps

None
Started: Feb. 25, 2019, 2:46 p.m.
Last activity: March 14, 2019, 4:26 a.m.
Tim Ahern
Feb. 25, 2019, 2:46 p.m.
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 services.
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



Tim Ahern

Chair
FDSN WG III



  • Marcelo Belentani de Bianchi
    Feb. 28, 2019, 4:27 p.m.
    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,

    Marcelo Bianchi
    --
    Centro de Sismologia / IAG / USP
    http://www.moho.iag.usp.br/ ~ http://www.iag.usp.br/geofisica
    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>
    escreveu:

    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
    services.
    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



    Tim Ahern

    Chair
    FDSN WG III



    ----------------------
    FDSN Working Group III
    Topic home: http://www.fdsn.org/message-center/topic/fdsn-wg3-products/ |
    Unsubscribe: fdsn-wg3-products-unsubscribe<at>lists.fdsn.org

    Sent from the FDSN Message Center (http://www.fdsn.org/message-center/)
    Update subscription preferences at http://www.fdsn.org/account/profile/


  • Catherine Pequegnat
    March 14, 2019, 4:26 a.m.
    Dear all,

    Please find below some comments by RESIF team :

    (1) We suggest to unify methods naming between webservices. We could keep only this methods:
    - query
    - queryauth
    - version​
    - application.wadl​
    and we could have boolean parameters to replace other methods. For instance :
    '...query?extent=true...' to replace the extent method.

    (2) The 'limit' parameter should be renamed to 'rowlimit' which is more self-explanatory.
    (3) Rename header to have an overall homogeneity between webservices such as 'station webservice' that is :
    #Network Station Location Channel Quality SampleRate Earliest Latest Updated TimeSpans
    (4) We wonder if the main implementation version number should correspond to the specification version number ?
    (5) With regard to temporary network, we should add an option 'networkstartyear' to understand observed gaps and avoid misleading merging.
    (6) We also think(cf Marcelo's reply) that 'lastestupdate', 'timespancount' and 'restriction' should not be optional.
    (7) We also think (cf Marcelo's reply) that 'mergetimespans' should be renamed to 'mergeoverlaps'.
    (8) We suggest adding a parameter 'mergetolerance' with 0.0 as default value (no merge).

    Generally speaking (but this goes beyond the strict framework of the webservice specification availability), we wonder if it would not be wise to provide for the output in text format of the two webservices station and availability an output format corresponding exactly to the format of the files passed as argument when using the POST method.
    Thus: the station output' ==> availability input and availability output ==> dataselect input

    Best regards,
    Catherine Péquegnat
    RESIF-DC
    ✆ +33 4 76 63 51 37 ou +33 4 76 63 52 48
    🏢 Isterre, bureau 035
    22 rue de la Piscine
    38400 Grenoble Cedex