International Federation of Digital Seismograph Networks

Thread: fdsn event changes

None
Started: June 9, 2017, 4:05 p.m.
Last activity: Aug. 11, 2017, 4:20 p.m.
John Clinton
June 9, 2017, 4:05 p.m.
Dear FDSN WG3,

over the last year or so, the FDSN III mailing list has seen a number of comments / suggestions / requests for modifications to each of the FDSN web services. Despite often quite vigorous discussions, there has not yet been a clear path for how version updates are agreed and implemented.

I propose we use the (short) time before now and the IASPEI meeting in Kobe in the beginning of August to agree on how we as a community agree on version updates and how they are implemented, and if possible, propose some changes that may be ratified at Kobe.

An obvious modification that was basically agreed in exchanges last summer ( http://www.fdsn.org/message-center/thread/425/ ) was for the fdsnws event to support event type. I reiterate what I would propose for including the event type:
- support in the query (default = earthquake)
- add column for event type in the text output
- open question: limit event type to the quakeMl1.2 definitions, or extend to quakeML2.0, or leave free form to be defined in the local web service documentation. This last part is tricky, as there remain complications with hierarchies on the de facto (unpublished?) Storchak et al. standard for event types

We can also use a review period to
1. review other proposed changes posted to the mailing list related to fdsn-event that may also warrant inclusion in a new version
2. try to collect individual extensions to the standard and see if they should be included if relevant (eg USGS already support the event type, as well as other useful tools such as count, but also have some tools that are internal to USGS such as pager alert level - https://earthquake.usgs.gov/fdsnws/event/1/#parameters )
3. take the opportunity to tighten the existing specifications in places (e.g. where possible, directly specify which parameter in quakeMl1.2 maps for both the query and response format)

comments or thoughts?

regards,

John



  • Jean-Marie Saurel
    June 9, 2017, 5:10 p.m.
    Hello John, hello everyone,

    Just a quick question as you speak about quakeML2.0.

    What's the status of this new quakeML version ?
    As it already been formally adopted ?
    Or maybe will it be adopted at Kobé ?

    Otherwise, I support the event_type filtering, that would be very usefull.

    Regards.
    Have a nice week-end.

    Jean-Marie SAUREL.


    On 06/09/2017 04:06 PM, John Clinton wrote:
    Dear FDSN WG3,

    over the last year or so, the FDSN III mailing list has seen a number of
    comments / suggestions / requests for modifications to each of the FDSN
    web services. Despite often quite vigorous discussions, there has not
    yet been a clear path for how version updates are agreed and implemented.

    I propose we use the (short) time before now and the IASPEI meeting in
    Kobe in the beginning of August to agree on how we as a community agree
    on version updates and how they are implemented, and if possible,
    propose some changes that may be ratified at Kobe.

    An obvious modification that was basically agreed in exchanges last
    summer ( http://www.fdsn.org/message-center/thread/425/ ) was for the
    fdsnws event to support event type. I reiterate what I would propose for
    including the event type:
    - support in the query (default = earthquake)
    - add column for event type in the text output
    - open question: limit event type to the quakeMl1.2 definitions, or
    extend to quakeML2.0, or leave free form to be defined in the local web
    service documentation. This last part is tricky, as there remain
    complications with hierarchies on the de facto (unpublished?) Storchak
    et al. standard for event types

    We can also use a review period to
    1. review other proposed changes posted to the mailing list related to
    fdsn-event that may also warrant inclusion in a new version
    2. try to collect individual extensions to the standard and see if they
    should be included if relevant (eg USGS already support the event type,
    as well as other useful tools such as count, but also have some tools
    that are internal to USGS such as pager alert level
    - https://earthquake.usgs.gov/fdsnws/event/1/#parameters )
    3. take the opportunity to tighten the existing specifications in places
    (e.g. where possible, directly specify which parameter in quakeMl1.2
    maps for both the query and response format)

    comments or thoughts?

    regards,

    John





    ----------------------
    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/



    --
    --------------------------------------
    ICG-CARIBE-EWS Working Group 1 chair

    Institut de Physique du Globe de Paris
    Observatoires Volcanologiques
    1 rue Jussieu
    75238 Paris Cédex 05
    +33(0)183957437
    France

    • Fabian Euchner
      June 14, 2017, 2:33 p.m.
      Hi all,

      Just a quick question as you speak about quakeML2.0.

      What's the status of this new quakeML version ?

      "QuakeML 2.0" is an umbrella term for a series of data models/schemas that are currently
      under development. These are thematic extensions to QuakeML 1.2, which covers only
      "Basic Event Description". Some of these packages are already quite mature and are
      currently under RfC. See http://quakeml.org/QuakeML2.0 .

      There will also be an updated BasicEventDescription package (QuakeML-BED v1.3). This
      will include mild changes to the well-known QuakeML 1.2. In particular, the event type
      enumeration needs to be revised. We would like to introduce precise definitons with
      literature references, and a hierarchy of terms with clear semantics. Suggestions are
      welcome!

      Best regards,
      Fabian

      As it already been formally adopted ?
      Or maybe will it be adopted at Kobé ?

      Otherwise, I support the event_type filtering, that would be very usefull.

      Regards.
      Have a nice week-end.

      Jean-Marie SAUREL.

      On 06/09/2017 04:06 PM, John Clinton wrote:
      Dear FDSN WG3,

      over the last year or so, the FDSN III mailing list has seen a number of
      comments / suggestions / requests for modifications to each of the FDSN
      web services. Despite often quite vigorous discussions, there has not
      yet been a clear path for how version updates are agreed and implemented.

      I propose we use the (short) time before now and the IASPEI meeting in
      Kobe in the beginning of August to agree on how we as a community agree
      on version updates and how they are implemented, and if possible,
      propose some changes that may be ratified at Kobe.

      An obvious modification that was basically agreed in exchanges last
      summer ( http://www.fdsn.org/message-center/thread/425/ ) was for the
      fdsnws event to support event type. I reiterate what I would propose for
      including the event type:
      - support in the query (default = earthquake)
      - add column for event type in the text output
      - open question: limit event type to the quakeMl1.2 definitions, or
      extend to quakeML2.0, or leave free form to be defined in the local web
      service documentation. This last part is tricky, as there remain
      complications with hierarchies on the de facto (unpublished?) Storchak
      et al. standard for event types

      We can also use a review period to
      1. review other proposed changes posted to the mailing list related to
      fdsn-event that may also warrant inclusion in a new version
      2. try to collect individual extensions to the standard and see if they
      should be included if relevant (eg USGS already support the event type,
      as well as other useful tools such as count, but also have some tools
      that are internal to USGS such as pager alert level
      - https://earthquake.usgs.gov/fdsnws/event/1/#parameters )
      3. take the opportunity to tighten the existing specifications in places
      (e.g. where possible, directly specify which parameter in quakeMl1.2
      maps for both the query and response format)

      comments or thoughts?

      regards,

      John





      ----------------------
      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/


      --
      -----------------------------------------------------------------------------
      Fabian Euchner phone +41 44 633 7178
      Institute of Geophysics fax +41 44 633 1065
      ETH Zurich, NO F5 e-mail fabian<at>sed.ethz.ch
      Sonneggstrasse 5 orcid.org/0000-0001-6340-7439
      8092 Zurich (Switzerland)
      -----------------------------------------------------------------------------
      QuakeML http://quakeml.org QuakePy http://quakepy.org
      CSEP http://www.cseptesting.org/centers/eth
      -----------------------------------------------------------------------------


      • Jean-Marie Saurel
        June 14, 2017, 12:40 p.m.
        Hello Fabian,

        Thanks for those informations.

        Regarding "event type", that's also one of the limitation of QuakeML1.2
        we are facing in volcanoe observatories.

        Do you think it could be possible to have, in addition to the existing
        or extended event types list, a possibility to reference to specific
        catalogs of event types ?


        I'm thinking about something similar to the SEED abbreviation
        catalog/reference scheme.

        This could allow to have extensive event type description, including
        litterature as you point, and an event type list that could be extended
        to the user specific needs.

        Regards.

        Jean-Marie SAUREL.

        On 06/14/2017 12:33 PM, Fabian Euchner wrote:
        Hi all,



        Just a quick question as you speak about quakeML2.0.



        What's the status of this new quakeML version ?



        "QuakeML 2.0" is an umbrella term for a series of data models/schemas
        that are currently under development. These are thematic extensions to
        QuakeML 1.2, which covers only "Basic Event Description". Some of these
        packages are already quite mature and are currently under RfC. See
        http://quakeml.org/QuakeML2.0 .



        There will also be an updated BasicEventDescription package (QuakeML-BED
        v1.3). This will include mild changes to the well-known QuakeML 1.2. In
        particular, the event type enumeration needs to be revised. We would
        like to introduce precise definitons with literature references, and a
        hierarchy of terms with clear semantics. Suggestions are welcome!



        Best regards,

        Fabian



        As it already been formally adopted ?

        Or maybe will it be adopted at Kobé ?



        Otherwise, I support the event_type filtering, that would be very usefull.



        Regards.

        Have a nice week-end.



        Jean-Marie SAUREL.



        On 06/09/2017 04:06 PM, John Clinton wrote:

        Dear FDSN WG3,



        over the last year or so, the FDSN III mailing list has seen a number of

        comments / suggestions / requests for modifications to each of the FDSN

        web services. Despite often quite vigorous discussions, there has not

        yet been a clear path for how version updates are agreed and
        implemented.



        I propose we use the (short) time before now and the IASPEI meeting in

        Kobe in the beginning of August to agree on how we as a community agree

        on version updates and how they are implemented, and if possible,

        propose some changes that may be ratified at Kobe.



        An obvious modification that was basically agreed in exchanges last

        summer ( http://www.fdsn.org/message-center/thread/425/ ) was for the

        fdsnws event to support event type. I reiterate what I would propose for

        including the event type:

        - support in the query (default = earthquake)

        - add column for event type in the text output

        - open question: limit event type to the quakeMl1.2 definitions, or

        extend to quakeML2.0, or leave free form to be defined in the local web

        service documentation. This last part is tricky, as there remain

        complications with hierarchies on the de facto (unpublished?) Storchak

        et al. standard for event types



        We can also use a review period to

        1. review other proposed changes posted to the mailing list related to

        fdsn-event that may also warrant inclusion in a new version

        2. try to collect individual extensions to the standard and see if they

        should be included if relevant (eg USGS already support the event type,

        as well as other useful tools such as count, but also have some tools

        that are internal to USGS such as pager alert level

        - https://earthquake.usgs.gov/fdsnws/event/1/#parameters )

        3. take the opportunity to tighten the existing specifications in places

        (e.g. where possible, directly specify which parameter in quakeMl1.2

        maps for both the query and response format)



        comments or thoughts?



        regards,



        John











        ----------------------

        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/





        --

        -----------------------------------------------------------------------------

        Fabian Euchner phone +41 44 633 7178

        Institute of Geophysics fax +41 44 633 1065

        ETH Zurich, NO F5 e-mail fabian<at>sed.ethz.ch

        Sonneggstrasse 5 orcid.org/0000-0001-6340-7439

        8092 Zurich (Switzerland)

        -----------------------------------------------------------------------------

        QuakeML http://quakeml.org QuakePy http://quakepy.org

        CSEP http://www.cseptesting.org/centers/eth

        -----------------------------------------------------------------------------





        --
        --------------------------------------
        ICG-CARIBE-EWS Working Group 1 chair

        Institut de Physique du Globe de Paris
        Observatoires Volcanologiques
        1 rue Jussieu
        75238 Paris Cédex 05
        +33(0)183957437
        France

        • Fabian Euchner
          June 14, 2017, 3:14 p.m.
          Hi Jean-Marie,

          not sure whether I correctly understand what you mean.

          The basic question is whether the definition of event types should be (i) included in the
          standard and be fixed, or (ii) be a free-text field. The latter would allow to use URIs/URLs
          of terms defined in other vocabularies, however, the drawback is that URLs are never as
          stable as one hopes. Therefore, I would suggest that we use (i) and copy all useful terms
          that we can find in other vocabularies into our own (and specify the semantic relation to
          the other term). I have the impression that the existing QuakeML 1.2 event type list is too
          detailed, especially for events that are served through fdsnws-event services (I haven't
          seen any train crashes or accidental explosions so far). The task will be to find a hierarchy
          that covers basic classifications of all communities, but is not unnecessarily broad.

          Regards,
          Fabian


          Hello Fabian,

          Thanks for those informations.

          Regarding "event type", that's also one of the limitation of QuakeML1.2
          we are facing in volcanoe observatories.

          Do you think it could be possible to have, in addition to the existing
          or extended event types list, a possibility to reference to specific
          catalogs of event types ?


          I'm thinking about something similar to the SEED abbreviation
          catalog/reference scheme.

          This could allow to have extensive event type description, including
          litterature as you point, and an event type list that could be extended
          to the user specific needs.

          Regards.

          Jean-Marie SAUREL.

          On 06/14/2017 12:33 PM, Fabian Euchner wrote:
          Hi all,

          Just a quick question as you speak about quakeML2.0.



          What's the status of this new quakeML version ?

          "QuakeML 2.0" is an umbrella term for a series of data models/schemas
          that are currently under development. These are thematic extensions to
          QuakeML 1.2, which covers only "Basic Event Description". Some of these
          packages are already quite mature and are currently under RfC. See
          http://quakeml.org/QuakeML2.0 .



          There will also be an updated BasicEventDescription package (QuakeML-BED
          v1.3). This will include mild changes to the well-known QuakeML 1.2. In
          particular, the event type enumeration needs to be revised. We would
          like to introduce precise definitons with literature references, and a
          hierarchy of terms with clear semantics. Suggestions are welcome!



          Best regards,

          Fabian

          As it already been formally adopted ?

          Or maybe will it be adopted at Kobé ?



          Otherwise, I support the event_type filtering, that would be very
          usefull.



          Regards.

          Have a nice week-end.



          Jean-Marie SAUREL.

          On 06/09/2017 04:06 PM, John Clinton wrote:
          Dear FDSN WG3,



          over the last year or so, the FDSN III mailing list has seen a number
          of

          comments / suggestions / requests for modifications to each of the FDSN

          web services. Despite often quite vigorous discussions, there has not

          yet been a clear path for how version updates are agreed and

          implemented.

          I propose we use the (short) time before now and the IASPEI meeting in

          Kobe in the beginning of August to agree on how we as a community agree

          on version updates and how they are implemented, and if possible,

          propose some changes that may be ratified at Kobe.
          • Jean-Marie Saurel
            June 14, 2017, 1:32 p.m.
            Fabian,

            not sure whether I correctly understand what you mean.
            Well, you are pretty close.
            I'm not very familiar with XML semantic, but I think I was refering to
            the free-text field as a reference to a URI pointing to a more precise
            description elsewhere.

            The basic question is whether the definition of event types should be
            (i) included in the standard and be fixed, or (ii) be a free-text field.
            The latter would allow to use URIs/URLs of terms defined in other
            vocabularies, however, the drawback is that URLs are never as stable as
            one hopes. Therefore, I would suggest that we use (i) and copy all
            useful terms that we can find in other vocabularies into our own (and
            specify the semantic relation to the other term). I have the impression
            that the existing QuakeML 1.2 event type list is too detailed,
            especially for events that are served through fdsnws-event services (I
            haven't seen any train crashes or accidental explosions so far). The
            task will be to find a hierarchy that covers basic classifications of
            all communities, but is not unnecessarily broad.

            I think I would favor both solutions.

            We would like to use the QuakeML and it's associated webservices and
            tools to distribute, for example, volcano events.
            If we can do so, we won't need to develop our own exotic format, nor to
            maintain our own webservices code and so on.

            On volcano, the identification and number of events is at least as
            important as their localization, sometimes even more.
            Each volcano has a unique set of event types (or event species). Some
            volcano have "summit events", "deep events", some others have "LP
            events", "hybrid event". A "type B volcano-tectonic event" is not
            necessarily the same on two different volcano.
            The problem is very similar when you deal with event classification and
            wants to deal with "family 123 event" and so on.

            We would like to have a way to include this diversity in the QuakeML
            "event type" field. And I don't think we could ever build a definitive
            list of types.

            Maybe there is already an additional package in QuakeML2.0 related to
            this issue. In which case it could be interesting to something in the
            BasicEventDescription telling the user he must look at the extension for
            more precise informations.

            Regards.

            Jean-Marie.


            Regards,

            Fabian





            Hello Fabian,



            Thanks for those informations.



            Regarding "event type", that's also one of the limitation of QuakeML1.2

            we are facing in volcanoe observatories.



            Do you think it could be possible to have, in addition to the existing

            or extended event types list, a possibility to reference to specific

            catalogs of event types ?





            I'm thinking about something similar to the SEED abbreviation

            catalog/reference scheme.



            This could allow to have extensive event type description, including

            litterature as you point, and an event type list that could be extended

            to the user specific needs.



            Regards.



            Jean-Marie SAUREL.



            On 06/14/2017 12:33 PM, Fabian Euchner wrote:

            Hi all,



            Just a quick question as you speak about quakeML2.0.







            What's the status of this new quakeML version ?



            "QuakeML 2.0" is an umbrella term for a series of data models/schemas

            that are currently under development. These are thematic extensions to

            QuakeML 1.2, which covers only "Basic Event Description". Some of these

            packages are already quite mature and are currently under RfC. See

            http://quakeml.org/QuakeML2.0 .







            There will also be an updated BasicEventDescription package (QuakeML-BED

            v1.3). This will include mild changes to the well-known QuakeML 1.2. In

            particular, the event type enumeration needs to be revised. We would

            like to introduce precise definitons with literature references, and a

            hierarchy of terms with clear semantics. Suggestions are welcome!







            Best regards,



            Fabian



            As it already been formally adopted ?



            Or maybe will it be adopted at Kobé ?







            Otherwise, I support the event_type filtering, that would be very

            usefull.







            Regards.



            Have a nice week-end.







            Jean-Marie SAUREL.



            On 06/09/2017 04:06 PM, John Clinton wrote:

            Dear FDSN WG3,







            over the last year or so, the FDSN III mailing list has seen a number

            of



            comments / suggestions / requests for modifications to each of
            the FDSN



            web services. Despite often quite vigorous discussions, there has not



            yet been a clear path for how version updates are agreed and



            implemented.



            I propose we use the (short) time before now and the IASPEI
            meeting in



            Kobe in the beginning of August to agree on how we as a community
            agree



            on version updates and how they are implemented, and if possible,



            propose some changes that may be ratified at Kobe.







            An obvious modification that was basically agreed in exchanges last



            summer ( http://www.fdsn.org/message-center/thread/425/ ) was for the



            fdsnws event to support event type. I reiterate what I would propose

            for



            including the event type:



            - support in the query (default = earthquake)



            - add column for event type in the text output



            - open question: limit event type to the quakeMl1.2 definitions, or



            extend to quakeML2.0, or leave free form to be defined in the
            local web



            service documentation. This last part is tricky, as there remain



            complications with hierarchies on the de facto (unpublished?)
            Storchak



            et al. standard for event types







            We can also use a review period to



            1. review other proposed changes posted to the mailing list
            related to



            fdsn-event that may also warrant inclusion in a new version



            2. try to collect individual extensions to the standard and see
            if they



            should be included if relevant (eg USGS already support the event
            type,



            as well as other useful tools such as count, but also have some tools



            that are internal to USGS such as pager alert level



            - https://earthquake.usgs.gov/fdsnws/event/1/#parameters )



            3. take the opportunity to tighten the existing specifications in

            places



            (e.g. where possible, directly specify which parameter in quakeMl1.2



            maps for both the query and response format)







            comments or thoughts?







            regards,







            John























            ----------------------



            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/



            --




            --------------------------------------------------------------------------

            ---



            Fabian Euchner phone +41 44 633 7178



            Institute of Geophysics fax +41 44 633 1065



            ETH Zurich, NO F5 e-mail fabian<at>sed.ethz.ch



            Sonneggstrasse 5 orcid.org/0000-0001-6340-7439



            8092 Zurich (Switzerland)




            --------------------------------------------------------------------------

            ---



            QuakeML http://quakeml.org QuakePy http://quakepy.org



            CSEP http://www.cseptesting.org/centers/eth




            --------------------------------------------------------------------------

            ---





            --

            -----------------------------------------------------------------------------

            Fabian Euchner phone +41 44 633 7178

            Institute of Geophysics fax +41 44 633 1065

            ETH Zurich, NO F5 e-mail fabian<at>sed.ethz.ch

            Sonneggstrasse 5 orcid.org/0000-0001-6340-7439

            8092 Zurich (Switzerland)

            -----------------------------------------------------------------------------

            QuakeML http://quakeml.org QuakePy http://quakepy.org

            CSEP http://www.cseptesting.org/centers/eth

            -----------------------------------------------------------------------------






            ----------------------
            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/



            --
            --------------------------------------
            ICG-CARIBE-EWS Working Group 1 chair

            Institut de Physique du Globe de Paris
            Observatoires Volcanologiques
            1 rue Jussieu
            75238 Paris Cédex 05
            +33(0)183957437
            France

  • Fabian Euchner
    June 12, 2017, 3:32 p.m.
    Hi John, hi all,

    An obvious modification that was basically agreed in exchanges last summer (
    http://www.fdsn.org/message-center/thread/425/ ) was for the fdsnws event
    to support event type. I reiterate what I would propose for including the
    event type: - support in the query (default = earthquake)

    I would make the "catch all" wildcard the default, including empty/unset values. There is
    no guarantee that the underlying data model has an event type. In QuakeML, eventType is
    optional and may not be set. The output from the ISC event web service, e.g., does not
    include eventType.

    Also, if "catch all" is the default, queries yield the same result for current services and
    future eventtype-enabled ones (without using eventtype query parameter).

    - open question: limit event type to the quakeMl1.2 definitions, or extend
    to quakeML2.0, or leave free form to be defined in the local web service
    documentation. This last part is tricky, as there remain complications with
    hierarchies on the de facto (unpublished?) Storchak et al. standard for
    event types

    If the results are still intended to be QuakeML 1.2, the output eventType has to be from
    the list defined in QuakeML 1.2. Theoretically, the allowed values for the query parameter
    could be different (e.g., in order to account for "legacy" event types), but I'm not sure if
    this would be helpful rather than confusing.

    Best regards,
    Fabian

    --
    -----------------------------------------------------------------------------
    Fabian Euchner phone +41 44 633 7178
    Institute of Geophysics fax +41 44 633 1065
    ETH Zurich, NO F5 e-mail fabian<at>sed.ethz.ch
    Sonneggstrasse 5 orcid.org/0000-0001-6340-7439
    8092 Zurich (Switzerland)
    -----------------------------------------------------------------------------
    QuakeML http://quakeml.org QuakePy http://quakepy.org
    CSEP http://www.cseptesting.org/centers/eth
    -----------------------------------------------------------------------------


  • Dmitry Storchak
    June 15, 2017, 5:36 p.m.
    Hi,

    Just wanted to say that the ISC-NEIC-EMSC document on event types,
    mentioned by John Clinton, is available here at the ISC website
    <http://www.isc.ac.uk/standards/event_types/event_types.pdf.

    Regards,

    Dmitry

    Dr. Dmitry A. Storchak
    Director
    International Seismological Centre (ISC)
    United Kingdom

    www.isc.ac.uk
    +44 (0)1635 861022

    On 09/06/2017 17:06, John Clinton wrote:
    Dear FDSN WG3,

    over the last year or so, the FDSN III mailing list has seen a number
    of comments / suggestions / requests for modifications to each of the
    FDSN web services. Despite often quite vigorous discussions, there has
    not yet been a clear path for how version updates are agreed and
    implemented.

    I propose we use the (short) time before now and the IASPEI meeting in
    Kobe in the beginning of August to agree on how we as a community
    agree on version updates and how they are implemented, and if
    possible, propose some changes that may be ratified at Kobe.

    An obvious modification that was basically agreed in exchanges last
    summer ( http://www.fdsn.org/message-center/thread/425/ ) was for the
    fdsnws event to support event type. I reiterate what I would propose
    for including the event type:
    - support in the query (default = earthquake)
    - add column for event type in the text output
    - open question: limit event type to the quakeMl1.2 definitions, or
    extend to quakeML2.0, or leave free form to be defined in the local
    web service documentation. This last part is tricky, as there remain
    complications with hierarchies on the de facto (unpublished?)
    Storchak et al. standard for event types

    We can also use a review period to
    1. review other proposed changes posted to the mailing list related to
    fdsn-event that may also warrant inclusion in a new version
    2. try to collect individual extensions to the standard and see if
    they should be included if relevant (eg USGS already support the event
    type, as well as other useful tools such as count, but also have some
    tools that are internal to USGS such as pager alert level -
    https://earthquake.usgs.gov/fdsnws/event/1/#parameters )
    3. take the opportunity to tighten the existing specifications in
    places (e.g. where possible, directly specify which parameter in
    quakeMl1.2 maps for both the query and response format)

    comments or thoughts?

    regards,

    John




    ----------------------
    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/


    • Florian Haslinger
      June 16, 2017, 11:11 a.m.
      Hi all,

      the discussion seems to have moved from the basic question ‘what to do with event types in FDSN services’ to ‘what to do about event types’ (which was one of John’s initial ‘open questions’…).
      While obviously connected, I feel that it would be appropriate to try and keep these discussions separated - or at least be conscious about what exactly we are discussing.

      I believe it would be worthwhile to pick up the ‘what to do about event types’ discussion again. At the end, any service or format should then ‘just implement’ the community decided definitions.

      A couple of thoughts / questions on that:

      - which is the appropriate body / forum to discuss (and propose/decide) event type definition standards?
      From seismology, we have at least two bodies within the IASPEI framework - CoSOI (a IASPEI commission) and FDSN (having IASPEI commission status) which play a role here. To me at least it is not fully clear which of the two could claim ‘ownership’ of this issue.
      But by now we also have other communities starting to share our services (data and / or formats), or being actively encouraged to share, like volcanology, infrasound, GNSS. They may have specific requests for event type definitions that we haven’t yet covered (as Jean-Marie nicely described for the volcanology case).

      To me, seismology is naturally in the lead, but perhaps we should formally invite / involve the other communities (via IUGG structures?).
      Sorry if that gets political, but the alternative in my view is that we just live with everybody implementing their own ideas in some private modification of a standard (thereby killing the standard…).

      - how hierarchical should the event type definitions be?
      The CoSOI standard (that’s what I call the ISC-NEIC-EMSC proposal forwarded by Dmitry, as - if I recall correctly - it was approved by CoSOI some years ago), has an implicit hierarchy for some types, but that is not comprehensive enough (and the hierarchy is not reflected in the structure of the definition).
      The volcano use-case described by Jean-Marie indicates that a ‘private typology’ may be required (or at least very useful) in their domain, and that may be true for other domains. So perhaps the opportunity to specify such a private type definition should be provided.
      Drawback / caveat: lazy people may just prefer to use the private types so that they don’t have to worry about following standards… Careful consideration is required where to draw the line between the private types and the standard ones.

      - related to the above - how referential should the event type definitions be?
      (see email discussion between Fabian and Jean-Marie)
      should we allow ‘any’ vocabulary as long as it can be referred to? should ‘private’ vocabularies be required to come with a reference / resource link?


      There are certainly various other ‘issues’ that also need to be addressed … Kobe would provide a good opportunity to discuss this further (at least in CoSOI and FDSN WGIII meetings…), and it would be great if we could collect input / views before the meeting (fully supporting John’s initial intention :-)

      As I couldn’t find any generic CoSOI mailing list, I at least include its current Chair (Thomas Meier) in cc, not sure whether he is on the FDSN WGIII list.


      Kind regards,
      Florian


      ----------------------------
      Swiss Seismological Service
      ETH Zurich

      Dr. Florian Haslinger
      NO H65
      Sonneggstr. 5
      CH - 8092 Zürich
      Switzerland

      ph: +41-44-633 4670
      www.seismo.ethz.chhttp://www.seismo.ethz.ch

      On 15 Jun 2017, at 6:37 PM, Dmitry Storchak <dmitry<at>isc.ac.uk<dmitry<at>isc.ac.uk>> wrote:


      Hi,

      Just wanted to say that the ISC-NEIC-EMSC document on event types, mentioned by John Clinton, is available here at the ISC websitehttp://www.isc.ac.uk/standards/event_types/event_types.pdf.

      Regards,

      Dmitry

      Dr. Dmitry A. Storchak
      Director
      International Seismological Centre (ISC)
      United Kingdom

      www.isc.ac.ukhttp://www.isc.ac.uk/
      +44 (0)1635 861022

      On 09/06/2017 17:06, John Clinton wrote:
      Dear FDSN WG3,

      over the last year or so, the FDSN III mailing list has seen a number of comments / suggestions / requests for modifications to each of the FDSN web services. Despite often quite vigorous discussions, there has not yet been a clear path for how version updates are agreed and implemented.

      I propose we use the (short) time before now and the IASPEI meeting in Kobe in the beginning of August to agree on how we as a community agree on version updates and how they are implemented, and if possible, propose some changes that may be ratified at Kobe.

      An obvious modification that was basically agreed in exchanges last summer ( http://www.fdsn.org/message-center/thread/425/ ) was for the fdsnws event to support event type. I reiterate what I would propose for including the event type:
      - support in the query (default = earthquake)
      - add column for event type in the text output
      - open question: limit event type to the quakeMl1.2 definitions, or extend to quakeML2.0, or leave free form to be defined in the local web service documentation. This last part is tricky, as there remain complications with hierarchies on the de facto (unpublished?) Storchak et al. standard for event types

      We can also use a review period to
      1. review other proposed changes posted to the mailing list related to fdsn-event that may also warrant inclusion in a new version
      2. try to collect individual extensions to the standard and see if they should be included if relevant (eg USGS already support the event type, as well as other useful tools such as count, but also have some tools that are internal to USGS such as pager alert level - https://earthquake.usgs.gov/fdsnws/event/1/#parameters )
      3. take the opportunity to tighten the existing specifications in places (e.g. where possible, directly specify which parameter in quakeMl1.2 maps for both the query and response format)

      comments or thoughts?

      regards,

      John





      ----------------------
      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/



      ----------------------
      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/


      • Dmitry Storchak
        June 16, 2017, 12:28 p.m.
        Hi all,

        If CoSOI of IASPEI is needed for something, then it is for the jobs like
        this. Indeed, all interested parties (volcanology, infrasound etc)
        should be invited to take part in a corresponding working group.

        Regards,

        Dmitry

        Dr. Dmitry A. Storchak
        Director
        International Seismological Centre (ISC)
        United Kingdom

        www.isc.ac.uk
        +44 (0)1635 861022

        On 16/06/2017 12:13, Florian Haslinger wrote:
        Hi all,

        the discussion seems to have moved from the basic question ‘what to do
        with event types in FDSN services’ to ‘what to do about event types’
        (which was one of John’s initial ‘open questions’…).
        While obviously connected, I feel that it would be appropriate to try
        and keep these discussions separated - or at least be conscious about
        what exactly we are discussing.

        I believe it would be worthwhile to pick up the ‘what to do about
        event types’ discussion again. At the end, any service or format
        should then ‘just implement’ the community decided definitions.

        A couple of thoughts / questions on that:

        - which is the appropriate body / forum to discuss (and
        propose/decide) event type definition standards?
        From seismology, we have at least two bodies within the IASPEI
        framework - CoSOI (a IASPEI commission) and FDSN (having IASPEI
        commission status) which play a role here. To me at least it is not
        fully clear which of the two could claim ‘ownership’ of this issue.
        But by now we also have other communities starting to share our
        services (data and / or formats), or being actively encouraged to
        share, like volcanology, infrasound, GNSS. They may have specific
        requests for event type definitions that we haven’t yet covered (as
        Jean-Marie nicely described for the volcanology case).

        To me, seismology is naturally in the lead, but perhaps we should
        formally invite / involve the other communities (via IUGG structures?).
        Sorry if that gets political, but the alternative in my view is that
        we just live with everybody implementing their own ideas in some
        private modification of a standard (thereby killing the standard…).

        - how hierarchical should the event type definitions be?
        The CoSOI standard (that’s what I call the ISC-NEIC-EMSC proposal
        forwarded by Dmitry, as - if I recall correctly - it was approved by
        CoSOI some years ago), has an implicit hierarchy for some types, but
        that is not comprehensive enough (and the hierarchy is not reflected
        in the structure of the definition).
        The volcano use-case described by Jean-Marie indicates that a ‘private
        typology’ may be required (or at least very useful) in their domain,
        and that may be true for other domains. So perhaps the opportunity to
        specify such a private type definition should be provided.
        Drawback / caveat: lazy people may just prefer to use the private
        types so that they don’t have to worry about following standards…
        Careful consideration is required where to draw the line between the
        private types and the standard ones.

        - related to the above - how referential should the event type
        definitions be?
        (see email discussion between Fabian and Jean-Marie)
        should we allow ‘any’ vocabulary as long as it can be referred to?
        should ‘private’ vocabularies be required to come with a reference /
        resource link?


        There are certainly various other ‘issues’ that also need to be
        addressed … Kobe would provide a good opportunity to discuss this
        further (at least in CoSOI and FDSN WGIII meetings…), and it would be
        great if we could collect input / views before the meeting (fully
        supporting John’s initial intention :-)

        As I couldn’t find any generic CoSOI mailing list, I at least include
        its current Chair (Thomas Meier) in cc, not sure whether he is on the
        FDSN WGIII list.


        Kind regards,
        Florian


        ----------------------------
        Swiss Seismological Service
        ETH Zurich

        Dr. Florian Haslinger
        NO H65
        Sonneggstr. 5
        CH - 8092 Zürich
        Switzerland

        ph: +41-44-633 4670
        www.seismo.ethz.ch <http://www.seismo.ethz.ch

        On 15 Jun 2017, at 6:37 PM, Dmitry Storchak <dmitry<at>isc.ac.uk
        <dmitry<at>isc.ac.uk>> wrote:

        Hi,

        Just wanted to say that the ISC-NEIC-EMSC document on event types,
        mentioned by John Clinton, is available here at the ISC website
        <http://www.isc.ac.uk/standards/event_types/event_types.pdf.

        Regards,

        Dmitry

        Dr. Dmitry A. Storchak
        Director
        International Seismological Centre (ISC)
        United Kingdom

        www.isc.ac.uk
        +44 (0)1635 861022
        On 09/06/2017 17:06, John Clinton wrote:
        Dear FDSN WG3,

        over the last year or so, the FDSN III mailing list has seen a
        number of comments / suggestions / requests for modifications to
        each of the FDSN web services. Despite often quite vigorous
        discussions, there has not yet been a clear path for how version
        updates are agreed and implemented.

        I propose we use the (short) time before now and the IASPEI meeting
        in Kobe in the beginning of August to agree on how we as a community
        agree on version updates and how they are implemented, and if
        possible, propose some changes that may be ratified at Kobe.

        An obvious modification that was basically agreed in exchanges last
        summer ( http://www.fdsn.org/message-center/thread/425/
        <http://www.fdsn.org/message-center/thread/425/ ) was for the
        fdsnws event to support event type. I reiterate what I would propose
        for including the event type:
        - support in the query (default = earthquake)
        - add column for event type in the text output
        - open question: limit event type to the quakeMl1.2 definitions, or
        extend to quakeML2.0, or leave free form to be defined in the local
        web service documentation. This last part is tricky, as there remain
        complications with hierarchies on the de facto (unpublished?)
        Storchak et al. standard for event types

        We can also use a review period to
        1. review other proposed changes posted to the mailing list related
        to fdsn-event that may also warrant inclusion in a new version
        2. try to collect individual extensions to the standard and see if
        they should be included if relevant (eg USGS already support the
        event type, as well as other useful tools such as count, but also
        have some tools that are internal to USGS such as pager alert level
        - https://earthquake.usgs.gov/fdsnws/event/1/#parameters )
        3. take the opportunity to tighten the existing specifications in
        places (e.g. where possible, directly specify which parameter in
        quakeMl1.2 maps for both the query and response format)

        comments or thoughts?

        regards,

        John




        ----------------------
        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 athttp://www.fdsn.org/account/profile/


        ----------------------
        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/
        <http://www.fdsn.org/account/profile/



        ----------------------
        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/


  • Tim Ahern
    June 23, 2017, 1:37 p.m.
    Hi John

    While the conversation continues, I think to move this forward when you are ready you should bring it to the FDSN WGIII for approval in Kobe.

    Specifically I think

    http://www.fdsn.org/webservices/FDSN-WS-Specifications-1.1.pdf
    documentation needs to be updated to identify defaults and other things related to parameter specification.

    I also think that you need to coordinate this with WG II where the FDSN Schema is vetted. I think WG II is still relevant to this or do you do it within ETH? Events are a bit different than what I usually track.

    So something should be brought to WG III about parameters and something to WGII for schema as needed. Then the WGs can adopt as they see fit.

    Is this possible?

    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 Jun 9, 2017, at 9:06 AM, John Clinton <jclinton<at>sed.ethz.ch> wrote:

    Dear FDSN WG3,

    over the last year or so, the FDSN III mailing list has seen a number of comments / suggestions / requests for modifications to each of the FDSN web services. Despite often quite vigorous discussions, there has not yet been a clear path for how version updates are agreed and implemented.

    I propose we use the (short) time before now and the IASPEI meeting in Kobe in the beginning of August to agree on how we as a community agree on version updates and how they are implemented, and if possible, propose some changes that may be ratified at Kobe.

    An obvious modification that was basically agreed in exchanges last summer ( http://www.fdsn.org/message-center/thread/425/ ) was for the fdsnws event to support event type. I reiterate what I would propose for including the event type:
    - support in the query (default = earthquake)
    - add column for event type in the text output
    - open question: limit event type to the quakeMl1.2 definitions, or extend to quakeML2.0, or leave free form to be defined in the local web service documentation. This last part is tricky, as there remain complications with hierarchies on the de facto (unpublished?) Storchak et al. standard for event types

    We can also use a review period to
    1. review other proposed changes posted to the mailing list related to fdsn-event that may also warrant inclusion in a new version
    2. try to collect individual extensions to the standard and see if they should be included if relevant (eg USGS already support the event type, as well as other useful tools such as count, but also have some tools that are internal to USGS such as pager alert level - https://earthquake.usgs.gov/fdsnws/event/1/#parameters )
    3. take the opportunity to tighten the existing specifications in places (e.g. where possible, directly specify which parameter in quakeMl1.2 maps for both the query and response format)

    comments or thoughts?

    regards,

    John



    ----------------------
    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
      July 6, 2017, 7 a.m.
      Hello Tim, hello everyone,

      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.


      * Rationale
      -----------
      When you have a webservice that doesn't trim the miniseed records (which
      is good), the current specification implies that you will end up with
      less data than you requested.
      The data will start at the first block after the starttime and end at
      the last block before the endtime.

      If you request several channels for, let's say, some cross-correlation
      computation, you will then need to trim your data to the smallest common
      data portion, which might not be enough.

      If you have slightly more data than asked as suggested, the user can
      trim the data to the exact starttime and endtime it has requested.

      Finally, from an implementation point of vue, it's way easier to find
      the miniseed blocks that include the start and end time than to find the
      first miniseed block that start at or doesn't include the starttime and
      the last miniseed block that ends at or doesn't include the endtime.


      Regards.

      Jean-Marie SAUREL.
      --
      --------------------------------------
      Institut de Physique du Globe de Paris
      Observatoires Volcanologiques
      1 rue Jussieu
      75238 Paris Cédex 05
      +33(0)183957437
      France

      • Pete Evans
        July 10, 2017, 4:46 p.m.
        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
        pevans<at>gfz-potsdam.de Tel. +49 (0)331 288-1261
        http://geofon.gfz-potsdam.de/ Fax +49 (0)331 288-1277

        • Tim Ahern
          July 10, 2017, 9:15 a.m.
          Hi Peter and all

          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 <pevans<at>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
          pevans<at>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
            July 10, 2017, 3:46 p.m.
            Hello Tim, hello everyone,

            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 <pevans<at>gfz-potsdam.de
            <pevans<at>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
            pevans<at>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/




            ----------------------
            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/



            --
            --------------------------------------
            Institut de Physique du Globe de Paris
            Observatoires Volcanologiques
            1 rue Jussieu
            75238 Paris Cédex 05
            +33(0)183957437
            France

          • Andres Heinloo
            Aug. 11, 2017, 4:20 p.m.
            On 07/10/2017 05:16 PM, Tim Ahern wrote:

            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