International Federation of Digital Seismograph Networks

Thread: Fdsnws-event update specification to include event type

None
Started: 2018-09-11 18:15:17
Last activity: 2018-09-25 16:44:51
Greetings members of FDSN WG III

Attached is version 1.2 of the FDSN WS specification with modifications to the FDSN event service related to the addition of the EventType parameter and text-format field for the fdsnws-event service (versioned as 1.2).

Please review this and indicate your approval or disapproval of this change by September 25, two weeks from today.

Please send your responses to the list so that others can see your response.


Regards
Tim Ahern

Chair
FDSN WG III







  • This seems to be a reasonable and useful change to me. I approve.
    Pete

    Dr. Peter Davis
    Executive Director, Project IDA
    University of California, San Diego
    http://ida.ucsd.edu/
    (o) 858-534-2839
    (f) 858-534-6354



    On Sep 11, 2018, at 11:16 AM, Tim Ahern <tim<at>iris.washington.edu> wrote:

    Greetings members of FDSN WG III

    Attached is version 1.2 of the FDSN WS specification with modifications to the FDSN event service related to the addition of the EventType parameter and text-format field for the fdsnws-event service (versioned as 1.2).

    Please review this and indicate your approval or disapproval of this change by September 25, two weeks from today.

    Please send your responses to the list so that others can see your response.


    Regards
    Tim Ahern

    Chair
    FDSN WG III


    <FDSN-WS-Specifications-1.2.pdf>




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


    • I am in favor of the recommended change related to the event type in the event service specification

      Cheers
      Tim

      Director of IRIS Data Services
      IRIS DMC
      1408 NE 45th Street #201
      Seattle, WA 98105

      (206)547-0393 x118
      (206) 547-1093 FAX








      On Sep 12, 2018, at 9:47 AM, Peter Davis <pdavis<at>ucsd.edu> wrote:

      This seems to be a reasonable and useful change to me. I approve.
      Pete

      Dr. Peter Davis
      Executive Director, Project IDA
      University of California, San Diego
      http://ida.ucsd.edu/
      (o) 858-534-2839
      (f) 858-534-6354



      On Sep 11, 2018, at 11:16 AM, Tim Ahern <tim<at>iris.washington.edu <tim<at>iris.washington.edu>> wrote:

      Greetings members of FDSN WG III

      Attached is version 1.2 of the FDSN WS specification with modifications to the FDSN event service related to the addition of the EventType parameter and text-format field for the fdsnws-event service (versioned as 1.2).

      Please review this and indicate your approval or disapproval of this change by September 25, two weeks from today.

      Please send your responses to the list so that others can see your response.


      Regards
      Tim Ahern

      Chair
      FDSN WG III


      <FDSN-WS-Specifications-1.2.pdf>




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



      • Hello,

        The USGS service provides basic support for this parameter already,
        including a comma separated list, so this seems reasonable.

        My only concern is with the wildcard "*" value. Is this necessary, since
        the default if this parameter is omitted is to include all event types?


        Thanks,

        Jeremy


        On Wed, Sep 12, 2018 at 12:06 PM Tim Ahern <tim<at>iris.washington.edu> wrote:

        I am in favor of the recommended change related to the event type in the
        event service specification

        Cheers
        Tim

        Director of IRIS Data Services
        IRIS DMC
        1408 NE 45th Street #201
        Seattle, WA 98105

        (206)547-0393 x118
        (206) 547-1093 FAX








        On Sep 12, 2018, at 9:47 AM, Peter Davis <pdavis<at>ucsd.edu> wrote:

        This seems to be a reasonable and useful change to me. I approve.
        Pete

        *Dr. Peter Davis*
        *Executive Director, Project IDA*
        *University of California, San Diego*
        *http://ida.ucsd.edu/*
        *(o) 858-534-2839*
        *(f) 858-534-6354*



        On Sep 11, 2018, at 11:16 AM, Tim Ahern <tim<at>iris.washington.edu> wrote:

        Greetings members of FDSN WG III

        Attached is version 1.2 of the FDSN WS specification with modifications to
        the FDSN event service related to the addition of the EventType parameter
        and text-format field for the fdsnws-event service (versioned as 1.2).

        Please review this and indicate your approval or disapproval of this
        change by September 25, two weeks from today.

        Please send your responses to the list so that others can see your
        response.


        Regards
        Tim Ahern

        Chair
        FDSN WG III


        <FDSN-WS-Specifications-1.2.pdf>




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





        • Hi all

          I agree that the asterisk wild card value makes no sense and should
          not be part of the spec.

          Philip



          On Wed, Sep 12, 2018 at 3:26 PM, Jeremy Fee <jmfee<at>usgs.gov> wrote:
          Hello,

          The USGS service provides basic support for this parameter already,
          including a comma separated list, so this seems reasonable.

          My only concern is with the wildcard "*" value. Is this necessary, since
          the default if this parameter is omitted is to include all event types?


          Thanks,

          Jeremy


          On Wed, Sep 12, 2018 at 12:06 PM Tim Ahern <tim<at>iris.washington.edu> wrote:

          I am in favor of the recommended change related to the event type in the
          event service specification

          Cheers
          Tim

          Director of IRIS Data Services
          IRIS DMC
          1408 NE 45th Street #201
          Seattle, WA 98105

          (206)547-0393 x118
          (206) 547-1093 FAX








          On Sep 12, 2018, at 9:47 AM, Peter Davis <pdavis<at>ucsd.edu> wrote:

          This seems to be a reasonable and useful change to me. I approve.
          Pete

          Dr. Peter Davis
          Executive Director, Project IDA
          University of California, San Diego
          http://ida.ucsd.edu/
          (o) 858-534-2839
          (f) 858-534-6354



          On Sep 11, 2018, at 11:16 AM, Tim Ahern <tim<at>iris.washington.edu> wrote:

          Greetings members of FDSN WG III

          Attached is version 1.2 of the FDSN WS specification with modifications to
          the FDSN event service related to the addition of the EventType parameter
          and text-format field for the fdsnws-event service (versioned as 1.2).

          Please review this and indicate your approval or disapproval of this
          change by September 25, two weeks from today.

          Please send your responses to the list so that others can see your
          response.


          Regards
          Tim Ahern

          Chair
          FDSN WG III


          <FDSN-WS-Specifications-1.2.pdf>




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





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


          • Florian Haslinger
            2018-09-21 18:46:35
            Hi all

            I was probably too naive (and not reading the spec document precisely enough) in assuming that that wildcard ‘*' could be used as a regular expression expander - i.e. by ‘*explosion*’ one would get all events of the types that include the string ‘explosion’ somewhere. Which I would have found an interesting and useful feature.

            But in case the wildcard would just function as placeholder for ‘any’, then I agree that it is probably useless.

            cheers
            florian


            On 20 Sep 2018, at 8:49 PM, Philip Crotwell <crotwell<at>seis.sc.edu> wrote:

            Hi all

            I agree that the asterisk wild card value makes no sense and should
            not be part of the spec.

            Philip



            On Wed, Sep 12, 2018 at 3:26 PM, Jeremy Fee <jmfee<at>usgs.gov> wrote:
            Hello,

            The USGS service provides basic support for this parameter already,
            including a comma separated list, so this seems reasonable.

            My only concern is with the wildcard "*" value. Is this necessary, since
            the default if this parameter is omitted is to include all event types?


            Thanks,

            Jeremy


            On Wed, Sep 12, 2018 at 12:06 PM Tim Ahern <tim<at>iris.washington.edu> wrote:

            I am in favor of the recommended change related to the event type in the
            event service specification

            Cheers
            Tim

            Director of IRIS Data Services
            IRIS DMC
            1408 NE 45th Street #201
            Seattle, WA 98105

            (206)547-0393 x118
            (206) 547-1093 FAX








            On Sep 12, 2018, at 9:47 AM, Peter Davis <pdavis<at>ucsd.edu> wrote:

            This seems to be a reasonable and useful change to me. I approve.
            Pete

            Dr. Peter Davis
            Executive Director, Project IDA
            University of California, San Diego
            http://ida.ucsd.edu/
            (o) 858-534-2839
            (f) 858-534-6354



            On Sep 11, 2018, at 11:16 AM, Tim Ahern <tim<at>iris.washington.edu> wrote:

            Greetings members of FDSN WG III

            Attached is version 1.2 of the FDSN WS specification with modifications to
            the FDSN event service related to the addition of the EventType parameter
            and text-format field for the fdsnws-event service (versioned as 1.2).

            Please review this and indicate your approval or disapproval of this
            change by September 25, two weeks from today.

            Please send your responses to the list so that others can see your
            response.


            Regards
            Tim Ahern

            Chair
            FDSN WG III


            <FDSN-WS-Specifications-1.2.pdf>




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





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


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


  • Stephane Zuzlewski
    2018-09-12 19:45:33
    The change sounds reasonable to me.


    Stephane

    On 9/11/18 11:16 AM, Tim Ahern wrote:
    Greetings members of FDSN WG III

    Attached is version 1.2 of the FDSN WS specification with modifications to the FDSN event service related to the addition of the EventType parameter and text-format field for the fdsnws-event service (versioned as 1.2).

    Please review this and indicate your approval or disapproval of this change by September 25, two weeks from today.

    Please send your responses to the list so that others can see your response.


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

    --
    ------------------------------------------------------------------
    Stephane Zuzlewski University of California, Berkeley
    stephane<at>seismo.berkeley.edu Berkeley Seismological Laboratory
    Office: 510-664-9029 (Thu) 215 McCone Hall # 4760
    Fax: 510-643-5811 Berkeley, CA 94720-4760
    Remote: 209-724-9540 (Mon,Tue,Wed,Fri)


  • Alexandros Savvaidis
    2018-09-13 04:30:03
    Dear all,

    I approve the updated specification.

    Best Regards,
    Alexandros

    Alexandros Savvaidis, Ph.D., Research Scientist
    Manager of Texas Seismological Network (TexNet)
    PI in Seismology, Center of Integrated Seismicity Research (CISR)

    From: <fdsn-wg3-products-bounce<at>lists.fdsn.org> on behalf of Tim Ahern <tim<at>iris.washington.edu>
    Date: Tuesday, September 11, 2018 at 1:25 PM
    To: FDSN Working Group III <fdsn-wg3-products<at>lists.fdsn.org>
    Subject: [fdsn-wg3-products] Fdsnws-event update specification to include event type

    Greetings members of FDSN WG III

    Attached is version 1.2 of the FDSN WS specification with modifications to the FDSN event service related to the addition of the EventType parameter and text-format field for the fdsnws-event service (versioned as 1.2).

    Please review this and indicate your approval or disapproval of this change by September 25, two weeks from today.

    Please send your responses to the list so that others can see your response.


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

    • Domingo Ballesta, Jordi (KNMI)
      2018-09-13 15:43:38
      Dear all,


      At KNMI (The Netherlands) we find this update very useful, as we monitor both tectonic and induced events.

      We approve the proposed specification.


      Kinds regards,


      Jordi Domingo Ballesta
      Advisor IT and Data Management
      ............................................................
      R&D Seismology and Acoustics
      KNMI (Royal Netherlands Meteorological Institute)
      Ministry of Infrastructure and Water Management
      Utrechtseweg 297 | 3731 GA De Bilt | The Netherlands
      Postbus 201 | 3730 AE De Bilt | The Netherlands
      ............................................................
      T +31 (0)30 22 06 670
      M +31 (0)6 17 017 546
      jordi.domingo.ballesta<at>knmi.nl
      http://rdsa.knmi.nl/
      ............................................................


      ________________________________
      From: fdsn-wg3-products-bounce<at>lists.fdsn.org <fdsn-wg3-products-bounce<at>lists.fdsn.org> on behalf of Alexandros Savvaidis <alexandros.savvaidis<at>beg.utexas.edu>
      Sent: 12 September 2018 11:30 PM
      To: FDSN Working Group III
      Subject: Re: [fdsn-wg3-products] Fdsnws-event update specification to include event type


      Dear all,



      I approve the updated specification.



      Best Regards,

      Alexandros



      Alexandros Savvaidis, Ph.D., Research Scientist

      Manager of Texas Seismological Network (TexNet)

      PI in Seismology, Center of Integrated Seismicity Research (CISR)



      From: <fdsn-wg3-products-bounce<at>lists.fdsn.org> on behalf of Tim Ahern <tim<at>iris.washington.edu>
      Date: Tuesday, September 11, 2018 at 1:25 PM
      To: FDSN Working Group III <fdsn-wg3-products<at>lists.fdsn.org>
      Subject: [fdsn-wg3-products] Fdsnws-event update specification to include event type



      Greetings members of FDSN WG III

      Attached is version 1.2 of the FDSN WS specification with modifications to the FDSN event service related to the addition of the EventType parameter and text-format field for the fdsnws-event service (versioned as 1.2).

      Please review this and indicate your approval or disapproval of this change by September 25, two weeks from today.

      Please send your responses to the list so that others can see your response.


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

      Sign Inhttp://www.fdsn.org/account/profile/
      www.fdsn.org
      FDSN is a global organization supporting seismology research.



      • Dear all,


        at ZAMG we monitor all seismic activity, not only tectonic events, and flag the events according to the ISF classification.

        I find the update very useful.


        We therefore approve the proposed specification.


        Best regards,

        Niko



        Nikolaus Horn
        Abteilung für Geophysik - Seismologie / Departement of Geophysics - Seismology
        ZAMG - Zentralanstalt für Meteorologie und Geodynamik
        1190 Wien, Hohe Warte
        Tel.: +43 1 36026 2521
        Fax: +43 1 368 66 21
        E-Mail: nikolaus.horn<at>zamg.ac.at

        www.zamg.ac.at
        Join us on facebook: http://www.facebook.com/zamg.at
        ________________________________
        Von: fdsn-wg3-products-bounce<at>lists.fdsn.org <fdsn-wg3-products-bounce<at>lists.fdsn.org> im Auftrag von Domingo Ballesta, Jordi (KNMI) <jordi.domingo.ballesta<at>knmi.nl>
        Gesendet: Donnerstag, 13. September 2018 10:44:20
        An: FDSN Working Group III
        Betreff: Re: [fdsn-wg3-products] Fdsnws-event update specification to include event type

        Dear all,


        At KNMI (The Netherlands) we find this update very useful, as we monitor both tectonic and induced events.

        We approve the proposed specification.


        Kinds regards,


        Jordi Domingo Ballesta
        Advisor IT and Data Management
        ............................................................
        R&D Seismology and Acoustics
        KNMI (Royal Netherlands Meteorological Institute)
        Ministry of Infrastructure and Water Management
        Utrechtseweg 297 | 3731 GA De Bilt | The Netherlands
        Postbus 201 | 3730 AE De Bilt | The Netherlands
        ............................................................
        T +31 (0)30 22 06 670
        M +31 (0)6 17 017 546
        jordi.domingo.ballesta<at>knmi.nl
        http://rdsa.knmi.nl/
        ............................................................


        ________________________________
        From: fdsn-wg3-products-bounce<at>lists.fdsn.org <fdsn-wg3-products-bounce<at>lists.fdsn.org> on behalf of Alexandros Savvaidis <alexandros.savvaidis<at>beg.utexas.edu>
        Sent: 12 September 2018 11:30 PM
        To: FDSN Working Group III
        Subject: Re: [fdsn-wg3-products] Fdsnws-event update specification to include event type


        Dear all,



        I approve the updated specification.



        Best Regards,

        Alexandros



        Alexandros Savvaidis, Ph.D., Research Scientist

        Manager of Texas Seismological Network (TexNet)

        PI in Seismology, Center of Integrated Seismicity Research (CISR)



        From: <fdsn-wg3-products-bounce<at>lists.fdsn.org> on behalf of Tim Ahern <tim<at>iris.washington.edu>
        Date: Tuesday, September 11, 2018 at 1:25 PM
        To: FDSN Working Group III <fdsn-wg3-products<at>lists.fdsn.org>
        Subject: [fdsn-wg3-products] Fdsnws-event update specification to include event type



        Greetings members of FDSN WG III

        Attached is version 1.2 of the FDSN WS specification with modifications to the FDSN event service related to the addition of the EventType parameter and text-format field for the fdsnws-event service (versioned as 1.2).

        Please review this and indicate your approval or disapproval of this change by September 25, two weeks from today.

        Please send your responses to the list so that others can see your response.


        Regards
        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
        FDSN: FDSN Working Group IIIhttp://www.fdsn.org/message-center/topic/fdsn-wg3-products/
        www.fdsn.org
        FDSN is a global organization supporting seismology research.



        Sent from the FDSN Message Center (http://www.fdsn.org/message-center/)
        FDSN: Message Centerhttp://www.fdsn.org/message-center/
        www.fdsn.org
        FDSN is a global organization supporting seismology research.


        Update subscription preferences at http://www.fdsn.org/account/profile/
        Sign Inhttp://www.fdsn.org/account/profile/
        www.fdsn.org
        FDSN is a global organization supporting seismology research.



        Sign Inhttp://www.fdsn.org/account/profile/
        Sign Inhttp://www.fdsn.org/account/profile/
        www.fdsn.org
        FDSN is a global organization supporting seismology research.


        www.fdsn.orghttp://www.fdsn.org
        FDSN:<http://www.fdsn.org/
        www.fdsn.org
        FDSN is a global organization supporting seismology research.


        FDSN is a global organization supporting seismology research.


        ----------------------
        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
        FDSN: FDSN Working Group IIIhttp://www.fdsn.org/message-center/topic/fdsn-wg3-products/
        www.fdsn.org
        FDSN is a global organization supporting seismology research.



        Sent from the FDSN Message Center (http://www.fdsn.org/message-center/)
        FDSN: Message Centerhttp://www.fdsn.org/message-center/
        www.fdsn.org
        FDSN is a global organization supporting seismology research.


        Update subscription preferences at http://www.fdsn.org/account/profile/
        Sign Inhttp://www.fdsn.org/account/profile/
        www.fdsn.org
        FDSN is a global organization supporting seismology research.



  • Jose Antonio Jara Salvador
    2018-09-14 01:36:45
    Dear all, I am in favor of this change.

    Cheers,

    Jose Antonio Jara Salvador
    Head of Seismology
    Institut Cartogràfic i Geològic de Catalunya

    From: fdsn-wg3-products-bounce<at>lists.fdsn.org [fdsn-wg3-products-bounce<at>lists.fdsn.org] On Behalf Of Tim Ahern
    Sent: dimarts, 11 / setembre / 2018 20:17
    To: FDSN Working Group III
    Subject: [fdsn-wg3-products] Fdsnws-event update specification to include event type

    Greetings members of FDSN WG III

    Attached is version 1.2 of the FDSN WS specification with modifications to the FDSN event service related to the addition of the EventType parameter and text-format field for the fdsnws-event service (versioned as 1.2).

    Please review this and indicate your approval or disapproval of this change by September 25, two weeks from today.

    Please send your responses to the list so that others can see your response.


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

  • Hello WG III!

    Technically, the eventtype parameter is certainly a very useful and
    highly appreciated addition to fdsnws-event. It needs to be noted,
    however, that adoption of the QuakeML 1.2 event type list in an FDSN
    standard might make future improvements more complicated.

    In particular, we know that there is a QuakeML version 1.3 planned that
    shall include an improved and/or more complete list of event types [1].
    ETHZ please provide an update on the current status. We also know that
    there is the list of event types of the ISC [2], which is similar but
    not fully compatible with the QuakeML 1.2 list of event types. AFAIK the
    QuakeML 1.3 list of event types shall become fully compatible with that
    of the ISC (provided the ISC list is a "final" version).

    The main difference between the QuakeML 1.2 list and the ISC list is
    that the latter is structured. There are categories like "anthropogenic
    event", which contain subcategories like "explosion", which in turn may
    be a "nuclear explosion" but also a "quarry blast". But both "nuclear
    explosion" and "quarry blast" belong to "explosion". The QuakeML 1.2
    event list, in contrast, is not structured, just a flat list of possible
    values. This means that if a user searches for events of type
    "explosion", the web service according to the current specification
    would neither include events of type "nuclear explosion" nor "quarry
    blast". This will inevitably lead to a lot of confusion.

    In July 2016 there were remarks on this list about QuakeML lacking more
    specific types of landslide events (Jeremy Fee) and volcanic events
    (Glenn Thompson) [3]. I don't know if there are plans to extend QuakeML
    1.3 and/or the ISC list to better accommodate these domains but it would
    probably now be a good opportunity.

    We will probably soon have to deal with mars quakes, too. :)

    Until QuakeML 1.3 is released as the official successor of 1.2 we
    consider the ISC event type list superior, especially in the context of
    data requests. GEOFON therefore disapproves the eventtype parameter
    specification in its present form and proposes to

    (1) Seek a clarification from the ISC whether its current list [2] is
    "final".

    (2) Adopt in the fdsnws-event specification either the structured ISC
    list or the QuakeML 1.3 list (if available) rather than the
    inappropriate and soon-obsolete QuakeML 1.2 list. A conforming
    fdsnws-event implementation will have to "know" that a "nuclear
    explosion" is also an "explosion" and that a request for "explosion"
    will have to return events with type "nuclear explosion" as well as
    "quarry blast".

    Both issues can probably be solved within a rather short time frame and
    should not be a show stopper. But since the web service specification is
    supposed to be usable for years to come, a clarification prior to
    approval will certainly pay off.

    Regards
    Joachim


    [1] http://www.fdsn.org/message-center/thread/488/#m-823
    [2] http://www.isc.ac.uk/standards/event_types/event_types.pdf
    [3] http://www.fdsn.org/message-center/thread/427/

    • Florian Haslinger
      2018-09-14 15:10:10
      Hi Joachim, hello all,

      I had written an email yesterday that related to what Joachim brought up below, but deleted it before sending :-)

      While I certainly agree that we are as a community not ‘at the end’ of the eventtyp discussion, I think that this can and should be tackled with the versioning of the fdsnws-releases, and I much prefer having prescribed values for those type collections rather than e.g. the current magnitude-type which seems to be ‘free’, only with some suggestions of how mag types could be called / written.

      So - let’s discuss extensions (and proper structuring) of event types, but let’s start implementing it with what we have now.

      Regarding the ISF / ISC event types and QuakeML 1.2, I believe they do match ‘exactly’ - comparing the ISC document that Joachim refer’s (Storchak et al 2012) and the QuakeML basic event description "QuakeML-BED-20130214b.pdf” from https://quake.ethz.ch/quakeml/Documents (which I believe is the valid QuakeML1.2 document).

      Regarding hierarchy, note that the ISC eventtype suggestion states
      “the above bullet-point hierarchy of event types is not part of the standard formats. Nevertheless its presence in this document helps to explain that event type reporters can be as general or as detailed as they so desire”
      and I would interpret this to mean that there shall be no expectation that in a search for events by type, any hiearchy following this is implemented by default.
      Of course a service may specifiy that they do honor that hierarchy (or any other) - here I am not sure what the fdsnws is actually implementing. (Some features of hierarchical search could be implemented by using wildcards, but certainly not all and it’s an ugly fix anyway).

      One ‘difference' between the QuakeML 1.2 parameters and ISC eventtype list is that QuakeML breaks the ISC types down further, where ISC lumps them together (I guess mainly due to lack of letters - remember that the ‘keep to one letter’ was a hard requirement for that ISC type description). But even that breakdown follows the ‘proposed nomenclature for application in QuakeML’ from the ISC document (also cf. the comment on hierarchy at the end of that section)

      Just on the side - there is no mechanism to use the ISC/ISF ‘letter code’ for the event type in the fdsnws, I believe?

      cheers
      florian



      On 14 Sep 2018, at 9:34 AM, Joachim Saul <saul<at>gfz-potsdam.de<saul<at>gfz-potsdam.de>> wrote:

      Hello WG III!

      Technically, the eventtype parameter is certainly a very useful and
      highly appreciated addition to fdsnws-event. It needs to be noted,
      however, that adoption of the QuakeML 1.2 event type list in an FDSN
      standard might make future improvements more complicated.

      In particular, we know that there is a QuakeML version 1.3 planned that
      shall include an improved and/or more complete list of event types [1].
      ETHZ please provide an update on the current status. We also know that
      there is the list of event types of the ISC [2], which is similar but
      not fully compatible with the QuakeML 1.2 list of event types. AFAIK the
      QuakeML 1.3 list of event types shall become fully compatible with that
      of the ISC (provided the ISC list is a "final" version).

      The main difference between the QuakeML 1.2 list and the ISC list is
      that the latter is structured. There are categories like "anthropogenic
      event", which contain subcategories like "explosion", which in turn may
      be a "nuclear explosion" but also a "quarry blast". But both "nuclear
      explosion" and "quarry blast" belong to "explosion". The QuakeML 1.2
      event list, in contrast, is not structured, just a flat list of possible
      values. This means that if a user searches for events of type
      "explosion", the web service according to the current specification
      would neither include events of type "nuclear explosion" nor "quarry
      blast". This will inevitably lead to a lot of confusion.

      In July 2016 there were remarks on this list about QuakeML lacking more
      specific types of landslide events (Jeremy Fee) and volcanic events
      (Glenn Thompson) [3]. I don't know if there are plans to extend QuakeML
      1.3 and/or the ISC list to better accommodate these domains but it would
      probably now be a good opportunity.

      We will probably soon have to deal with mars quakes, too. :)

      Until QuakeML 1.3 is released as the official successor of 1.2 we
      consider the ISC event type list superior, especially in the context of
      data requests. GEOFON therefore disapproves the eventtype parameter
      specification in its present form and proposes to

      (1) Seek a clarification from the ISC whether its current list [2] is
      "final".

      (2) Adopt in the fdsnws-event specification either the structured ISC
      list or the QuakeML 1.3 list (if available) rather than the
      inappropriate and soon-obsolete QuakeML 1.2 list. A conforming
      fdsnws-event implementation will have to "know" that a "nuclear
      explosion" is also an "explosion" and that a request for "explosion"
      will have to return events with type "nuclear explosion" as well as
      "quarry blast".

      Both issues can probably be solved within a rather short time frame and
      should not be a show stopper. But since the web service specification is
      supposed to be usable for years to come, a clarification prior to
      approval will certainly pay off.

      Regards
      Joachim


      [1] http://www.fdsn.org/message-center/thread/488/#m-823
      [2] http://www.isc.ac.uk/standards/event_types/event_types.pdf
      [3] http://www.fdsn.org/message-center/thread/427/

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


      • Florian Haslinger
        2018-09-14 15:13:16
        ps - and sorry for spamming…

        I am not the ‘official’ WGIII member from ETH… so my email is not any official vote on the matter from here :-)

        florian

        On 14 Sep 2018, at 10:11 AM, Florian Haslinger <florian.haslinger<at>sed.ethz.ch<florian.haslinger<at>sed.ethz.ch>> wrote:

        Hi Joachim, hello all,

        I had written an email yesterday that related to what Joachim brought up below, but deleted it before sending :-)

        While I certainly agree that we are as a community not ‘at the end’ of the eventtyp discussion, I think that this can and should be tackled with the versioning of the fdsnws-releases, and I much prefer having prescribed values for those type collections rather than e.g. the current magnitude-type which seems to be ‘free’, only with some suggestions of how mag types could be called / written.

        So - let’s discuss extensions (and proper structuring) of event types, but let’s start implementing it with what we have now.

        Regarding the ISF / ISC event types and QuakeML 1.2, I believe they do match ‘exactly’ - comparing the ISC document that Joachim refer’s (Storchak et al 2012) and the QuakeML basic event description "QuakeML-BED-20130214b.pdf” from https://quake.ethz.ch/quakeml/Documents (which I believe is the valid QuakeML1.2 document).

        Regarding hierarchy, note that the ISC eventtype suggestion states
        “the above bullet-point hierarchy of event types is not part of the standard formats. Nevertheless its presence in this document helps to explain that event type reporters can be as general or as detailed as they so desire”
        and I would interpret this to mean that there shall be no expectation that in a search for events by type, any hiearchy following this is implemented by default.
        Of course a service may specifiy that they do honor that hierarchy (or any other) - here I am not sure what the fdsnws is actually implementing. (Some features of hierarchical search could be implemented by using wildcards, but certainly not all and it’s an ugly fix anyway).

        One ‘difference' between the QuakeML 1.2 parameters and ISC eventtype list is that QuakeML breaks the ISC types down further, where ISC lumps them together (I guess mainly due to lack of letters - remember that the ‘keep to one letter’ was a hard requirement for that ISC type description). But even that breakdown follows the ‘proposed nomenclature for application in QuakeML’ from the ISC document (also cf. the comment on hierarchy at the end of that section)

        Just on the side - there is no mechanism to use the ISC/ISF ‘letter code’ for the event type in the fdsnws, I believe?

        cheers
        florian



        On 14 Sep 2018, at 9:34 AM, Joachim Saul <saul<at>gfz-potsdam.de<saul<at>gfz-potsdam.de>> wrote:

        Hello WG III!

        Technically, the eventtype parameter is certainly a very useful and
        highly appreciated addition to fdsnws-event. It needs to be noted,
        however, that adoption of the QuakeML 1.2 event type list in an FDSN
        standard might make future improvements more complicated.

        In particular, we know that there is a QuakeML version 1.3 planned that
        shall include an improved and/or more complete list of event types [1].
        ETHZ please provide an update on the current status. We also know that
        there is the list of event types of the ISC [2], which is similar but
        not fully compatible with the QuakeML 1.2 list of event types. AFAIK the
        QuakeML 1.3 list of event types shall become fully compatible with that
        of the ISC (provided the ISC list is a "final" version).

        The main difference between the QuakeML 1.2 list and the ISC list is
        that the latter is structured. There are categories like "anthropogenic
        event", which contain subcategories like "explosion", which in turn may
        be a "nuclear explosion" but also a "quarry blast". But both "nuclear
        explosion" and "quarry blast" belong to "explosion". The QuakeML 1.2
        event list, in contrast, is not structured, just a flat list of possible
        values. This means that if a user searches for events of type
        "explosion", the web service according to the current specification
        would neither include events of type "nuclear explosion" nor "quarry
        blast". This will inevitably lead to a lot of confusion.

        In July 2016 there were remarks on this list about QuakeML lacking more
        specific types of landslide events (Jeremy Fee) and volcanic events
        (Glenn Thompson) [3]. I don't know if there are plans to extend QuakeML
        1.3 and/or the ISC list to better accommodate these domains but it would
        probably now be a good opportunity.

        We will probably soon have to deal with mars quakes, too. :)

        Until QuakeML 1.3 is released as the official successor of 1.2 we
        consider the ISC event type list superior, especially in the context of
        data requests. GEOFON therefore disapproves the eventtype parameter
        specification in its present form and proposes to

        (1) Seek a clarification from the ISC whether its current list [2] is
        "final".

        (2) Adopt in the fdsnws-event specification either the structured ISC
        list or the QuakeML 1.3 list (if available) rather than the
        inappropriate and soon-obsolete QuakeML 1.2 list. A conforming
        fdsnws-event implementation will have to "know" that a "nuclear
        explosion" is also an "explosion" and that a request for "explosion"
        will have to return events with type "nuclear explosion" as well as
        "quarry blast".

        Both issues can probably be solved within a rather short time frame and
        should not be a show stopper. But since the web service specification is
        supposed to be usable for years to come, a clarification prior to
        approval will certainly pay off.

        Regards
        Joachim


        [1] http://www.fdsn.org/message-center/thread/488/#m-823
        [2] http://www.isc.ac.uk/standards/event_types/event_types.pdf
        [3] http://www.fdsn.org/message-center/thread/427/

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


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


      • Dear Colleagues,

        I remember that there were discussions about this point duirng the meetings of the IASPEI Commission of Seismological Observation and Interpretation (CoSOI) in Gothenburg or Prague together with the ISC. The decided solution may differ from Storchak et al. (2012) and please remember that ISF = IASPEI Standard Format. We should avoid to have different formats for IASPEI and FDSN, which has Commission status in IASPEI.

        Please contact Dmirty about the latest status.

        Cheers,

        Johannes



        Dr. Johannes SCHWEITZER
        Secretary-General / Treasurer
        iaspei<at>norsar.no

        [IASPEI_logo_new_smaller]
        ________________________________
        IASPEI
        c/o NORSAR
        Gunnar Randers vei 15
        PO Box 53, N-2007 Kjeller
        Norway
        Mobile: +47 41614946
        Phone: +47 63 80 59 00

        From: fdsn-wg3-products-bounce<at>lists.fdsn.org <fdsn-wg3-products-bounce<at>lists.fdsn.org> On Behalf Of Florian Haslinger
        Sent: Friday, September 14, 2018 10:11 AM
        To: FDSN Working Group III <fdsn-wg3-products<at>lists.fdsn.org>
        Subject: Re: [fdsn-wg3-products] Fdsnws-event update specification to include event type

        Hi Joachim, hello all,

        I had written an email yesterday that related to what Joachim brought up below, but deleted it before sending :-)

        While I certainly agree that we are as a community not ‘at the end’ of the eventtyp discussion, I think that this can and should be tackled with the versioning of the fdsnws-releases, and I much prefer having prescribed values for those type collections rather than e.g. the current magnitude-type which seems to be ‘free’, only with some suggestions of how mag types could be called / written.

        So - let’s discuss extensions (and proper structuring) of event types, but let’s start implementing it with what we have now.

        Regarding the ISF / ISC event types and QuakeML 1.2, I believe they do match ‘exactly’ - comparing the ISC document that Joachim refer’s (Storchak et al 2012) and the QuakeML basic event description "QuakeML-BED-20130214b.pdf” from https://quake.ethz.ch/quakeml/Documents (which I believe is the valid QuakeML1.2 document).

        Regarding hierarchy, note that the ISC eventtype suggestion states
        “the above bullet-point hierarchy of event types is not part of the standard formats. Nevertheless its presence in this document helps to explain that event type reporters can be as general or as detailed as they so desire”
        and I would interpret this to mean that there shall be no expectation that in a search for events by type, any hiearchy following this is implemented by default.
        Of course a service may specifiy that they do honor that hierarchy (or any other) - here I am not sure what the fdsnws is actually implementing. (Some features of hierarchical search could be implemented by using wildcards, but certainly not all and it’s an ugly fix anyway).

        One ‘difference' between the QuakeML 1.2 parameters and ISC eventtype list is that QuakeML breaks the ISC types down further, where ISC lumps them together (I guess mainly due to lack of letters - remember that the ‘keep to one letter’ was a hard requirement for that ISC type description). But even that breakdown follows the ‘proposed nomenclature for application in QuakeML’ from the ISC document (also cf. the comment on hierarchy at the end of that section)

        Just on the side - there is no mechanism to use the ISC/ISF ‘letter code’ for the event type in the fdsnws, I believe?

        cheers
        florian




        On 14 Sep 2018, at 9:34 AM, Joachim Saul <saul<at>gfz-potsdam.de<saul<at>gfz-potsdam.de>> wrote:

        Hello WG III!

        Technically, the eventtype parameter is certainly a very useful and
        highly appreciated addition to fdsnws-event. It needs to be noted,
        however, that adoption of the QuakeML 1.2 event type list in an FDSN
        standard might make future improvements more complicated.

        In particular, we know that there is a QuakeML version 1.3 planned that
        shall include an improved and/or more complete list of event types [1].
        ETHZ please provide an update on the current status. We also know that
        there is the list of event types of the ISC [2], which is similar but
        not fully compatible with the QuakeML 1.2 list of event types. AFAIK the
        QuakeML 1.3 list of event types shall become fully compatible with that
        of the ISC (provided the ISC list is a "final" version).

        The main difference between the QuakeML 1.2 list and the ISC list is
        that the latter is structured. There are categories like "anthropogenic
        event", which contain subcategories like "explosion", which in turn may
        be a "nuclear explosion" but also a "quarry blast". But both "nuclear
        explosion" and "quarry blast" belong to "explosion". The QuakeML 1.2
        event list, in contrast, is not structured, just a flat list of possible
        values. This means that if a user searches for events of type
        "explosion", the web service according to the current specification
        would neither include events of type "nuclear explosion" nor "quarry
        blast". This will inevitably lead to a lot of confusion.

        In July 2016 there were remarks on this list about QuakeML lacking more
        specific types of landslide events (Jeremy Fee) and volcanic events
        (Glenn Thompson) [3]. I don't know if there are plans to extend QuakeML
        1.3 and/or the ISC list to better accommodate these domains but it would
        probably now be a good opportunity.

        We will probably soon have to deal with mars quakes, too. :)

        Until QuakeML 1.3 is released as the official successor of 1.2 we
        consider the ISC event type list superior, especially in the context of
        data requests. GEOFON therefore disapproves the eventtype parameter
        specification in its present form and proposes to

        (1) Seek a clarification from the ISC whether its current list [2] is
        "final".

        (2) Adopt in the fdsnws-event specification either the structured ISC
        list or the QuakeML 1.3 list (if available) rather than the
        inappropriate and soon-obsolete QuakeML 1.2 list. A conforming
        fdsnws-event implementation will have to "know" that a "nuclear
        explosion" is also an "explosion" and that a request for "explosion"
        will have to return events with type "nuclear explosion" as well as
        "quarry blast".

        Both issues can probably be solved within a rather short time frame and
        should not be a show stopper. But since the web service specification is
        supposed to be usable for years to come, a clarification prior to
        approval will certainly pay off.

        Regards
        Joachim


        [1] http://www.fdsn.org/message-center/thread/488/#m-823
        [2] http://www.isc.ac.uk/standards/event_types/event_types.pdf
        [3] http://www.fdsn.org/message-center/thread/427/

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


        Attachments
        • Mulder, Taimi (NRCan/RNCan)
          2018-09-20 05:09:05
          Regarding the event type 2-char codes that the ISC uses, as Florian mentions below, I really like the way the ISC and IASPEI chose to partition out the meaning between the two characters:

          ISC
          1st char – certainty (s=suspected, k=known, u=unknown, n=not reported)
          2nd char – type (ISC limited themselves to 26 types which coincides with the number of letters in the english alphabet)

          IASPEI
          1st char – confidence with which the event type is asserted (s=suspected, k=known, f=felt, d=damaging)
          2nd char – type (IASPEI has 9 types)

          Note that QuakeML had 44 event type classifications.

          In particular, I really like the ability to indicate ‘felt’ events. This is a much needed classification and event types codes that include it are necessary for forward mapping of legacy information/data holdings.

          I do like how the ISC breaks the list down into subsections. This type of grouping is very useful, especially when dealing with incorporating legacy data. In many cases it may be impossible to trace an event back to one of the expanded definitions available in QuakeML or the ISC sub-categories. Users may also want all events encapsulated within a particular group such as “collapse” or “explosion”. It is nice to see that QuakeML preserves those generic heading catagories, although I agree with the earlier comments about blasts (quarry, road cut, blasting levee) and the explosion sub-types need to be encapsulated with any search for “explosion”; this follows for searches on any of the other sub-categories outlined by the ISC document and the QuakeML sub-category extensions.

          It would be very useful to have an internationally accepted standard for event type codes, as well as for event type classification. The two go hand in hand. At the moment, the ISC/IASPEI event type codes are the closest our community has. With the QuakeML event classification getting pinned down, and internationally accepted, this would be a good time to perhaps start thinking about a sensible way to represent the types by event codes. Many institutions have legacy codes which they are outgrowing (or have outgrown) and some may be reluctant to undergo the effort of change until a commonly accepted international standard is put forth. Perhaps if a sensible 2-char designations can be put forth for the QuakeML extensions, perhaps that may go some way towards getting other agencies to adopt the added event types into their own classifications.

          This does divert the current conversational thread and may not be the forum in which to discuss event type codes, if the fdsnws may have no mechanism to use them, however this forum does represent a large international cross-section for potentially creating an international standard.

          -Taimi
          Taimi Mulder
          Earthquake Seismologist
          NRCAN-LMS-HAOB-Canadian Hazards Information Service
          Geological Survey of Canada
          Sismologue de tremblements de terre
          Service canadien d'information sur les risques
          Commission geologique du Canada

          Pacific Geoscience Centre
          PO Box 6000, Sidney, BC, V8L 4B2, Canada
          tel: 250-363-6436<tel:250-363-6436>
          Email: Taimi.Mulder<at>canada.ca<Taimi.Mulder<at>canada.ca>



          From: fdsn-wg3-products-bounce<at>lists.fdsn.org <fdsn-wg3-products-bounce<at>lists.fdsn.org> On Behalf Of IASPEI
          Sent: September 19, 2018 10:07
          To: FDSN Working Group III <fdsn-wg3-products<at>lists.fdsn.org>
          Subject: RE: [fdsn-wg3-products] Fdsnws-event update specification to include event type

          Dear Colleagues,

          I remember that there were discussions about this point duirng the meetings of the IASPEI Commission of Seismological Observation and Interpretation (CoSOI) in Gothenburg or Prague together with the ISC. The decided solution may differ from Storchak et al. (2012) and please remember that ISF = IASPEI Standard Format. We should avoid to have different formats for IASPEI and FDSN, which has Commission status in IASPEI.

          Please contact Dmirty about the latest status.

          Cheers,

          Johannes



          Dr. Johannes SCHWEITZER
          Secretary-General / Treasurer
          iaspei<at>norsar.no<iaspei<at>norsar.no>

          [IASPEI_logo_new_smaller]
          ________________________________
          IASPEI
          c/o NORSAR
          Gunnar Randers vei 15
          PO Box 53, N-2007 Kjeller
          Norway
          Mobile: +47 41614946
          Phone: +47 63 80 59 00

          From: fdsn-wg3-products-bounce<at>lists.fdsn.org<fdsn-wg3-products-bounce<at>lists.fdsn.org> <fdsn-wg3-products-bounce<at>lists.fdsn.org<fdsn-wg3-products-bounce<at>lists.fdsn.org>> On Behalf Of Florian Haslinger
          Sent: Friday, September 14, 2018 10:11 AM
          To: FDSN Working Group III <fdsn-wg3-products<at>lists.fdsn.org<fdsn-wg3-products<at>lists.fdsn.org>>
          Subject: Re: [fdsn-wg3-products] Fdsnws-event update specification to include event type

          Hi Joachim, hello all,

          I had written an email yesterday that related to what Joachim brought up below, but deleted it before sending :-)

          While I certainly agree that we are as a community not ‘at the end’ of the eventtyp discussion, I think that this can and should be tackled with the versioning of the fdsnws-releases, and I much prefer having prescribed values for those type collections rather than e.g. the current magnitude-type which seems to be ‘free’, only with some suggestions of how mag types could be called / written.

          So - let’s discuss extensions (and proper structuring) of event types, but let’s start implementing it with what we have now.

          Regarding the ISF / ISC event types and QuakeML 1.2, I believe they do match ‘exactly’ - comparing the ISC document that Joachim refer’s (Storchak et al 2012) and the QuakeML basic event description "QuakeML-BED-20130214b.pdf” from https://quake.ethz.ch/quakeml/Documents (which I believe is the valid QuakeML1.2 document).

          Regarding hierarchy, note that the ISC eventtype suggestion states
          “the above bullet-point hierarchy of event types is not part of the standard formats. Nevertheless its presence in this document helps to explain that event type reporters can be as general or as detailed as they so desire”
          and I would interpret this to mean that there shall be no expectation that in a search for events by type, any hiearchy following this is implemented by default.
          Of course a service may specifiy that they do honor that hierarchy (or any other) - here I am not sure what the fdsnws is actually implementing. (Some features of hierarchical search could be implemented by using wildcards, but certainly not all and it’s an ugly fix anyway).

          One ‘difference' between the QuakeML 1.2 parameters and ISC eventtype list is that QuakeML breaks the ISC types down further, where ISC lumps them together (I guess mainly due to lack of letters - remember that the ‘keep to one letter’ was a hard requirement for that ISC type description). But even that breakdown follows the ‘proposed nomenclature for application in QuakeML’ from the ISC document (also cf. the comment on hierarchy at the end of that section)

          Just on the side - there is no mechanism to use the ISC/ISF ‘letter code’ for the event type in the fdsnws, I believe?

          cheers
          florian



          On 14 Sep 2018, at 9:34 AM, Joachim Saul <saul<at>gfz-potsdam.de<saul<at>gfz-potsdam.de>> wrote:

          Hello WG III!

          Technically, the eventtype parameter is certainly a very useful and
          highly appreciated addition to fdsnws-event. It needs to be noted,
          however, that adoption of the QuakeML 1.2 event type list in an FDSN
          standard might make future improvements more complicated.

          In particular, we know that there is a QuakeML version 1.3 planned that
          shall include an improved and/or more complete list of event types [1].
          ETHZ please provide an update on the current status. We also know that
          there is the list of event types of the ISC [2], which is similar but
          not fully compatible with the QuakeML 1.2 list of event types. AFAIK the
          QuakeML 1.3 list of event types shall become fully compatible with that
          of the ISC (provided the ISC list is a "final" version).

          The main difference between the QuakeML 1.2 list and the ISC list is
          that the latter is structured. There are categories like "anthropogenic
          event", which contain subcategories like "explosion", which in turn may
          be a "nuclear explosion" but also a "quarry blast". But both "nuclear
          explosion" and "quarry blast" belong to "explosion". The QuakeML 1.2
          event list, in contrast, is not structured, just a flat list of possible
          values. This means that if a user searches for events of type
          "explosion", the web service according to the current specification
          would neither include events of type "nuclear explosion" nor "quarry
          blast". This will inevitably lead to a lot of confusion.

          In July 2016 there were remarks on this list about QuakeML lacking more
          specific types of landslide events (Jeremy Fee) and volcanic events
          (Glenn Thompson) [3]. I don't know if there are plans to extend QuakeML
          1.3 and/or the ISC list to better accommodate these domains but it would
          probably now be a good opportunity.

          We will probably soon have to deal with mars quakes, too. :)

          Until QuakeML 1.3 is released as the official successor of 1.2 we
          consider the ISC event type list superior, especially in the context of
          data requests. GEOFON therefore disapproves the eventtype parameter
          specification in its present form and proposes to

          (1) Seek a clarification from the ISC whether its current list [2] is
          "final".

          (2) Adopt in the fdsnws-event specification either the structured ISC
          list or the QuakeML 1.3 list (if available) rather than the
          inappropriate and soon-obsolete QuakeML 1.2 list. A conforming
          fdsnws-event implementation will have to "know" that a "nuclear
          explosion" is also an "explosion" and that a request for "explosion"
          will have to return events with type "nuclear explosion" as well as
          "quarry blast".

          Both issues can probably be solved within a rather short time frame and
          should not be a show stopper. But since the web service specification is
          supposed to be usable for years to come, a clarification prior to
          approval will certainly pay off.

          Regards
          Joachim


          [1] http://www.fdsn.org/message-center/thread/488/#m-823
          [2] http://www.isc.ac.uk/standards/event_types/event_types.pdf
          [3] http://www.fdsn.org/message-center/thread/427/

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


          Attachments
          • Trani, Luca (KNMI)
            2018-09-20 14:16:13
            Dear FDSN WG-III,

            I am not very much into the details of this particular issue and maybe I am missing some important bits. However, from the discussions so far it occurs to me that a possible solution could be to define a shared controlled vocabulary or better a taxonomy. This would not necessarily be part of QuakeML but it could be maintained by an external authority e.g. FDSN <www.fdsn.org/vocabulary/eventtypes>.

            An advantage is that such a taxonomy could be extended and evolve independently from QuakeML. For instance, new concepts could be added, definitions could be modified without violating the standard or having to update versions.

            The adoption within the WS of such a taxonomy could be incremental, initially just as a recommendation which would not violate the current format. In future versions we could think about stronger constraints. My view is that once experienced the advantages of adopting such structured definitions good behaviors would emerge fostering a ‘de facto’ standardisation.

            The classification of the document “Nomenclature of Events Types” could be a good starting point maybe trying to harmonise definitions with other existing classifications e.g. IASPEI. It could be formalised in a machine-readable way in order to be consumed by automated tools, e.g. with SKOS.

            These are some examples of how the strings would look like:
            <www.fdsn.org/vocabulary/eventtypes/earthquake>
            <www.fdsn.org/vocabulary/eventtypes/rockburst>

            Those links should be actionable and lead to the corresponding definitions. There is no need to include details about the hierarchy in the terms as they would be defined in the SKOS taxonomy.

            Best regards,
            Luca


            Luca Trani
            Senior Advisor IT - Researcher
            ........................................................................
            KNMI
            Ministry of Infrastructure and Water Management
            Utrechtseweg 297 | 3731 GA | De Bilt | the Netherlands
            PO Box 201 | 3730 AE | De Bilt | the Netherlands
            ........................................................................
            T +31 (0)30 2206 297
            trani<at>knmi.nl<trani<at>knmi.nl>
            www.knmi.nlhttp://www.knmi.nl/
            ........................................................................

            Van: fdsn-wg3-products-bounce<at>lists.fdsn.org [fdsn-wg3-products-bounce<at>lists.fdsn.org] Namens Mulder, Taimi (NRCan/RNCan)
            Verzonden: donderdag 20 september 2018 00:10
            Aan: FDSN Working Group III
            Onderwerp: RE: [fdsn-wg3-products] Fdsnws-event update specification to include event type

            Regarding the event type 2-char codes that the ISC uses, as Florian mentions below, I really like the way the ISC and IASPEI chose to partition out the meaning between the two characters:

            ISC
            1st char – certainty (s=suspected, k=known, u=unknown, n=not reported)
            2nd char – type (ISC limited themselves to 26 types which coincides with the number of letters in the english alphabet)

            IASPEI
            1st char – confidence with which the event type is asserted (s=suspected, k=known, f=felt, d=damaging)
            2nd char – type (IASPEI has 9 types)

            Note that QuakeML had 44 event type classifications.

            In particular, I really like the ability to indicate ‘felt’ events. This is a much needed classification and event types codes that include it are necessary for forward mapping of legacy information/data holdings.

            I do like how the ISC breaks the list down into subsections. This type of grouping is very useful, especially when dealing with incorporating legacy data. In many cases it may be impossible to trace an event back to one of the expanded definitions available in QuakeML or the ISC sub-categories. Users may also want all events encapsulated within a particular group such as “collapse” or “explosion”. It is nice to see that QuakeML preserves those generic heading catagories, although I agree with the earlier comments about blasts (quarry, road cut, blasting levee) and the explosion sub-types need to be encapsulated with any search for “explosion”; this follows for searches on any of the other sub-categories outlined by the ISC document and the QuakeML sub-category extensions.

            It would be very useful to have an internationally accepted standard for event type codes, as well as for event type classification. The two go hand in hand. At the moment, the ISC/IASPEI event type codes are the closest our community has. With the QuakeML event classification getting pinned down, and internationally accepted, this would be a good time to perhaps start thinking about a sensible way to represent the types by event codes. Many institutions have legacy codes which they are outgrowing (or have outgrown) and some may be reluctant to undergo the effort of change until a commonly accepted international standard is put forth. Perhaps if a sensible 2-char designations can be put forth for the QuakeML extensions, perhaps that may go some way towards getting other agencies to adopt the added event types into their own classifications.

            This does divert the current conversational thread and may not be the forum in which to discuss event type codes, if the fdsnws may have no mechanism to use them, however this forum does represent a large international cross-section for potentially creating an international standard.

            -Taimi
            Taimi Mulder
            Earthquake Seismologist
            NRCAN-LMS-HAOB-Canadian Hazards Information Service
            Geological Survey of Canada
            Sismologue de tremblements de terre
            Service canadien d'information sur les risques
            Commission geologique du Canada

            Pacific Geoscience Centre
            PO Box 6000, Sidney, BC, V8L 4B2, Canada
            tel: 250-363-6436<tel:250-363-6436>
            Email: Taimi.Mulder<at>canada.ca<Taimi.Mulder<at>canada.ca>



            From: fdsn-wg3-products-bounce<at>lists.fdsn.org <fdsn-wg3-products-bounce<at>lists.fdsn.org> On Behalf Of IASPEI
            Sent: September 19, 2018 10:07
            To: FDSN Working Group III <fdsn-wg3-products<at>lists.fdsn.org>
            Subject: RE: [fdsn-wg3-products] Fdsnws-event update specification to include event type

            Dear Colleagues,

            I remember that there were discussions about this point duirng the meetings of the IASPEI Commission of Seismological Observation and Interpretation (CoSOI) in Gothenburg or Prague together with the ISC. The decided solution may differ from Storchak et al. (2012) and please remember that ISF = IASPEI Standard Format. We should avoid to have different formats for IASPEI and FDSN, which has Commission status in IASPEI.

            Please contact Dmirty about the latest status.

            Cheers,

            Johannes



            Dr. Johannes SCHWEITZER
            Secretary-General / Treasurer
            iaspei<at>norsar.no<iaspei<at>norsar.no>

            [IASPEI_logo_new_smaller]
            ________________________________
            IASPEI
            c/o NORSAR
            Gunnar Randers vei 15
            PO Box 53, N-2007 Kjeller
            Norway
            Mobile: +47 41614946
            Phone: +47 63 80 59 00

            From: fdsn-wg3-products-bounce<at>lists.fdsn.org<fdsn-wg3-products-bounce<at>lists.fdsn.org> <fdsn-wg3-products-bounce<at>lists.fdsn.org<fdsn-wg3-products-bounce<at>lists.fdsn.org>> On Behalf Of Florian Haslinger
            Sent: Friday, September 14, 2018 10:11 AM
            To: FDSN Working Group III <fdsn-wg3-products<at>lists.fdsn.org<fdsn-wg3-products<at>lists.fdsn.org>>
            Subject: Re: [fdsn-wg3-products] Fdsnws-event update specification to include event type

            Hi Joachim, hello all,

            I had written an email yesterday that related to what Joachim brought up below, but deleted it before sending :-)

            While I certainly agree that we are as a community not ‘at the end’ of the eventtyp discussion, I think that this can and should be tackled with the versioning of the fdsnws-releases, and I much prefer having prescribed values for those type collections rather than e.g. the current magnitude-type which seems to be ‘free’, only with some suggestions of how mag types could be called / written.

            So - let’s discuss extensions (and proper structuring) of event types, but let’s start implementing it with what we have now.

            Regarding the ISF / ISC event types and QuakeML 1.2, I believe they do match ‘exactly’ - comparing the ISC document that Joachim refer’s (Storchak et al 2012) and the QuakeML basic event description "QuakeML-BED-20130214b.pdf” from https://quake.ethz.ch/quakeml/Documents (which I believe is the valid QuakeML1.2 document).

            Regarding hierarchy, note that the ISC eventtype suggestion states
            “the above bullet-point hierarchy of event types is not part of the standard formats. Nevertheless its presence in this document helps to explain that event type reporters can be as general or as detailed as they so desire”
            and I would interpret this to mean that there shall be no expectation that in a search for events by type, any hiearchy following this is implemented by default.
            Of course a service may specifiy that they do honor that hierarchy (or any other) - here I am not sure what the fdsnws is actually implementing. (Some features of hierarchical search could be implemented by using wildcards, but certainly not all and it’s an ugly fix anyway).

            One ‘difference' between the QuakeML 1.2 parameters and ISC eventtype list is that QuakeML breaks the ISC types down further, where ISC lumps them together (I guess mainly due to lack of letters - remember that the ‘keep to one letter’ was a hard requirement for that ISC type description). But even that breakdown follows the ‘proposed nomenclature for application in QuakeML’ from the ISC document (also cf. the comment on hierarchy at the end of that section)

            Just on the side - there is no mechanism to use the ISC/ISF ‘letter code’ for the event type in the fdsnws, I believe?

            cheers
            florian



            On 14 Sep 2018, at 9:34 AM, Joachim Saul <saul<at>gfz-potsdam.de<saul<at>gfz-potsdam.de>> wrote:

            Hello WG III!

            Technically, the eventtype parameter is certainly a very useful and
            highly appreciated addition to fdsnws-event. It needs to be noted,
            however, that adoption of the QuakeML 1.2 event type list in an FDSN
            standard might make future improvements more complicated.

            In particular, we know that there is a QuakeML version 1.3 planned that
            shall include an improved and/or more complete list of event types [1].
            ETHZ please provide an update on the current status. We also know that
            there is the list of event types of the ISC [2], which is similar but
            not fully compatible with the QuakeML 1.2 list of event types. AFAIK the
            QuakeML 1.3 list of event types shall become fully compatible with that
            of the ISC (provided the ISC list is a "final" version).

            The main difference between the QuakeML 1.2 list and the ISC list is
            that the latter is structured. There are categories like "anthropogenic
            event", which contain subcategories like "explosion", which in turn may
            be a "nuclear explosion" but also a "quarry blast". But both "nuclear
            explosion" and "quarry blast" belong to "explosion". The QuakeML 1.2
            event list, in contrast, is not structured, just a flat list of possible
            values. This means that if a user searches for events of type
            "explosion", the web service according to the current specification
            would neither include events of type "nuclear explosion" nor "quarry
            blast". This will inevitably lead to a lot of confusion.

            In July 2016 there were remarks on this list about QuakeML lacking more
            specific types of landslide events (Jeremy Fee) and volcanic events
            (Glenn Thompson) [3]. I don't know if there are plans to extend QuakeML
            1.3 and/or the ISC list to better accommodate these domains but it would
            probably now be a good opportunity.

            We will probably soon have to deal with mars quakes, too. :)

            Until QuakeML 1.3 is released as the official successor of 1.2 we
            consider the ISC event type list superior, especially in the context of
            data requests. GEOFON therefore disapproves the eventtype parameter
            specification in its present form and proposes to

            (1) Seek a clarification from the ISC whether its current list [2] is
            "final".

            (2) Adopt in the fdsnws-event specification either the structured ISC
            list or the QuakeML 1.3 list (if available) rather than the
            inappropriate and soon-obsolete QuakeML 1.2 list. A conforming
            fdsnws-event implementation will have to "know" that a "nuclear
            explosion" is also an "explosion" and that a request for "explosion"
            will have to return events with type "nuclear explosion" as well as
            "quarry blast".

            Both issues can probably be solved within a rather short time frame and
            should not be a show stopper. But since the web service specification is
            supposed to be usable for years to come, a clarification prior to
            approval will certainly pay off.

            Regards
            Joachim


            [1] http://www.fdsn.org/message-center/thread/488/#m-823
            [2] http://www.isc.ac.uk/standards/event_types/event_types.pdf
            [3] http://www.fdsn.org/message-center/thread/427/

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


            Attachments
            • Hi Luca, hi all,

              this is planned for the next QuakeML version. See on https://quake.ethz.ch/
              quakeml/QuakeML2.0

              "Values of enumerations are URIs. An implicit hierarchy and further semantic
              relations of terms (e.g., to terms in other vocabularies) can be defined in an
              SKOS file that will be provided in addition to XML and RelaxNG schema files."

              Attached is the SKOS definiton of EventType according to the hierarchy from
              the Storchak et al. document.

              Regards,
              Fabian


              Dear FDSN WG-III,

              I am not very much into the details of this particular issue and maybe I am
              missing some important bits. However, from the discussions so far it occurs
              to me that a possible solution could be to define a shared controlled
              vocabulary or better a taxonomy. This would not necessarily be part of
              QuakeML but it could be maintained by an external authority e.g. FDSN
              <www.fdsn.org/vocabulary/eventtypes>.

              An advantage is that such a taxonomy could be extended and evolve
              independently from QuakeML. For instance, new concepts could be added,
              definitions could be modified without violating the standard or having to
              update versions.

              The adoption within the WS of such a taxonomy could be incremental,
              initially just as a recommendation which would not violate the current
              format. In future versions we could think about stronger constraints. My
              view is that once experienced the advantages of adopting such structured
              definitions good behaviors would emerge fostering a ‘de facto’
              standardisation.

              The classification of the document “Nomenclature of Events Types” could be a
              good starting point maybe trying to harmonise definitions with other
              existing classifications e.g. IASPEI. It could be formalised in a
              machine-readable way in order to be consumed by automated tools, e.g. with
              SKOS.

              These are some examples of how the strings would look like:
              <www.fdsn.org/vocabulary/eventtypes/earthquake>
              <www.fdsn.org/vocabulary/eventtypes/rockburst>

              Those links should be actionable and lead to the corresponding definitions.
              There is no need to include details about the hierarchy in the terms as
              they would be defined in the SKOS taxonomy.

              Best regards,
              Luca


              Luca Trani
              Senior Advisor IT - Researcher
              ........................................................................
              KNMI
              Ministry of Infrastructure and Water Management
              Utrechtseweg 297 | 3731 GA | De Bilt | the Netherlands
              PO Box 201 | 3730 AE | De Bilt | the Netherlands
              ........................................................................
              T +31 (0)30 2206 297
              trani<at>knmi.nl<trani<at>knmi.nl>
              www.knmi.nlhttp://www.knmi.nl/
              ........................................................................

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

              • Trani, Luca (KNMI)
                2018-09-22 00:24:16
                Thank you Fabian.

                Indeed I was lacking important info. This looks great! Are you planning to maintain this as part of the QuakeML Core? Or would this be an additional module with its own versioning?

                Best,
                Luca

                Luca Trani
                Senior Advisor IT - Researcher
                ........................................................................
                KNMI
                Ministry of Infrastructure and Water Management  
                Utrechtseweg 297 | 3731 GA | De Bilt | the Netherlands
                PO Box 201 | 3730 AE | De Bilt | the Netherlands
                ........................................................................ 
                T +31 (0)30 2206 297
                trani<at>knmi.nl
                www.knmi.nl
                ........................................................................

                -----Oorspronkelijk bericht-----
                Van: Fabian Euchner [fabian.euchner<at>sed.ethz.ch]
                Verzonden: vrijdag 21 september 2018 16:11
                Aan: Trani, Luca (KNMI)
                CC: FDSN Working Group III
                Onderwerp: Re: [fdsn-wg3-products] Fdsnws-event update specification to include event type

                Hi Luca, hi all,

                this is planned for the next QuakeML version. See on https://quake.ethz.ch/
                quakeml/QuakeML2.0

                "Values of enumerations are URIs. An implicit hierarchy and further semantic relations of terms (e.g., to terms in other vocabularies) can be defined in an SKOS file that will be provided in addition to XML and RelaxNG schema files."

                Attached is the SKOS definiton of EventType according to the hierarchy from the Storchak et al. document.

                Regards,
                Fabian


                Dear FDSN WG-III,

                I am not very much into the details of this particular issue and maybe
                I am missing some important bits. However, from the discussions so far
                it occurs to me that a possible solution could be to define a shared
                controlled vocabulary or better a taxonomy. This would not necessarily
                be part of QuakeML but it could be maintained by an external authority
                e.g. FDSN <www.fdsn.org/vocabulary/eventtypes>.

                An advantage is that such a taxonomy could be extended and evolve
                independently from QuakeML. For instance, new concepts could be added,
                definitions could be modified without violating the standard or having
                to update versions.

                The adoption within the WS of such a taxonomy could be incremental,
                initially just as a recommendation which would not violate the current
                format. In future versions we could think about stronger constraints.
                My view is that once experienced the advantages of adopting such
                structured definitions good behaviors would emerge fostering a ‘de facto’
                standardisation.

                The classification of the document “Nomenclature of Events Types”
                could be a good starting point maybe trying to harmonise definitions
                with other existing classifications e.g. IASPEI. It could be
                formalised in a machine-readable way in order to be consumed by
                automated tools, e.g. with SKOS.

                These are some examples of how the strings would look like:
                <www.fdsn.org/vocabulary/eventtypes/earthquake>
                <www.fdsn.org/vocabulary/eventtypes/rockburst>

                Those links should be actionable and lead to the corresponding definitions.
                There is no need to include details about the hierarchy in the terms
                as they would be defined in the SKOS taxonomy.

                Best regards,
                Luca


                Luca Trani
                Senior Advisor IT - Researcher
                ........................................................................
                KNMI
                Ministry of Infrastructure and Water Management Utrechtseweg 297 |
                3731 GA | De Bilt | the Netherlands PO Box 201 | 3730 AE | De Bilt |
                the Netherlands
                ........................................................................
                T +31 (0)30 2206 297
                trani<at>knmi.nl<trani<at>knmi.nl>
                www.knmi.nlhttp://www.knmi.nl/
                ........................................................................

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

      • Domingo Ballesta, Jordi (KNMI)
        2018-09-18 18:27:45
        Hi Joachim, Florian,


        I completely agree on using an harmonized list of event types, and if it is structured, much better. However, I wouldn't use a list of event types from ISC or QuakeML 1.3 in a fdsnws-event version that returns QuakeML 1.2.


        For me, it doesn't make sense to search for certain a event type (which belongs to the new list), and get as a result a QuakeML 1.2 with a different event type. In addition, the event type of the text format (QuakeML 1.3 / ISC) might be different from the event type of the xml format (QuakeML 1.2).


        In other words, I would either:


        a) go ahead with the current proposed specification (list of event types from QuakeML 1.2 and return QuakeML 1.2 format)


        b) wait until QuakeML 1.3 is released (then use the list of event types from QuakeML 1.3 and return QuakeML 1.3 format)


        My vote goes for any of the 2 options as long as it is implemented in a (relative) short time frame.


        Kind regards,


        Jordi Domingo Ballesta
        Advisor IT and Data Management
        ............................................................
        R&D Seismology and Acoustics
        KNMI (Royal Netherlands Meteorological Institute)
        Ministry of Infrastructure and Water Management
        Utrechtseweg 297 | 3731 GA De Bilt | The Netherlands
        Postbus 201 | 3730 AE De Bilt | The Netherlands
        ............................................................
        T +31 (0)30 22 06 670
        M +31 (0)6 17 017 546
        jordi.domingo.ballesta<at>knmi.nl
        http://rdsa.knmi.nl/
        ............................................................


        ________________________________
        From: fdsn-wg3-products-bounce<at>lists.fdsn.org <fdsn-wg3-products-bounce<at>lists.fdsn.org> on behalf of Florian Haslinger <florian.haslinger<at>sed.ethz.ch>
        Sent: 14 September 2018 10:11 AM
        To: FDSN Working Group III
        Subject: Re: [fdsn-wg3-products] Fdsnws-event update specification to include event type

        Hi Joachim, hello all,

        I had written an email yesterday that related to what Joachim brought up below, but deleted it before sending :-)

        While I certainly agree that we are as a community not ‘at the end’ of the eventtyp discussion, I think that this can and should be tackled with the versioning of the fdsnws-releases, and I much prefer having prescribed values for those type collections rather than e.g. the current magnitude-type which seems to be ‘free’, only with some suggestions of how mag types could be called / written.

        So - let’s discuss extensions (and proper structuring) of event types, but let’s start implementing it with what we have now.

        Regarding the ISF / ISC event types and QuakeML 1.2, I believe they do match ‘exactly’ - comparing the ISC document that Joachim refer’s (Storchak et al 2012) and the QuakeML basic event description "QuakeML-BED-20130214b.pdf” from https://quake.ethz.ch/quakeml/Documents (which I believe is the valid QuakeML1.2 document).

        Regarding hierarchy, note that the ISC eventtype suggestion states
        “the above bullet-point hierarchy of event types is not part of the standard formats. Nevertheless its presence in this document helps to explain that event type reporters can be as general or as detailed as they so desire”
        and I would interpret this to mean that there shall be no expectation that in a search for events by type, any hiearchy following this is implemented by default.
        Of course a service may specifiy that they do honor that hierarchy (or any other) - here I am not sure what the fdsnws is actually implementing. (Some features of hierarchical search could be implemented by using wildcards, but certainly not all and it’s an ugly fix anyway).

        One ‘difference' between the QuakeML 1.2 parameters and ISC eventtype list is that QuakeML breaks the ISC types down further, where ISC lumps them together (I guess mainly due to lack of letters - remember that the ‘keep to one letter’ was a hard requirement for that ISC type description). But even that breakdown follows the ‘proposed nomenclature for application in QuakeML’ from the ISC document (also cf. the comment on hierarchy at the end of that section)

        Just on the side - there is no mechanism to use the ISC/ISF ‘letter code’ for the event type in the fdsnws, I believe?

        cheers
        florian



        On 14 Sep 2018, at 9:34 AM, Joachim Saul <saul<at>gfz-potsdam.de<saul<at>gfz-potsdam.de>> wrote:

        Hello WG III!

        Technically, the eventtype parameter is certainly a very useful and
        highly appreciated addition to fdsnws-event. It needs to be noted,
        however, that adoption of the QuakeML 1.2 event type list in an FDSN
        standard might make future improvements more complicated.

        In particular, we know that there is a QuakeML version 1.3 planned that
        shall include an improved and/or more complete list of event types [1].
        ETHZ please provide an update on the current status. We also know that
        there is the list of event types of the ISC [2], which is similar but
        not fully compatible with the QuakeML 1.2 list of event types. AFAIK the
        QuakeML 1.3 list of event types shall become fully compatible with that
        of the ISC (provided the ISC list is a "final" version).

        The main difference between the QuakeML 1.2 list and the ISC list is
        that the latter is structured. There are categories like "anthropogenic
        event", which contain subcategories like "explosion", which in turn may
        be a "nuclear explosion" but also a "quarry blast". But both "nuclear
        explosion" and "quarry blast" belong to "explosion". The QuakeML 1.2
        event list, in contrast, is not structured, just a flat list of possible
        values. This means that if a user searches for events of type
        "explosion", the web service according to the current specification
        would neither include events of type "nuclear explosion" nor "quarry
        blast". This will inevitably lead to a lot of confusion.

        In July 2016 there were remarks on this list about QuakeML lacking more
        specific types of landslide events (Jeremy Fee) and volcanic events
        (Glenn Thompson) [3]. I don't know if there are plans to extend QuakeML
        1.3 and/or the ISC list to better accommodate these domains but it would
        probably now be a good opportunity.

        We will probably soon have to deal with mars quakes, too. :)

        Until QuakeML 1.3 is released as the official successor of 1.2 we
        consider the ISC event type list superior, especially in the context of
        data requests. GEOFON therefore disapproves the eventtype parameter
        specification in its present form and proposes to

        (1) Seek a clarification from the ISC whether its current list [2] is
        "final".

        (2) Adopt in the fdsnws-event specification either the structured ISC
        list or the QuakeML 1.3 list (if available) rather than the
        inappropriate and soon-obsolete QuakeML 1.2 list. A conforming
        fdsnws-event implementation will have to "know" that a "nuclear
        explosion" is also an "explosion" and that a request for "explosion"
        will have to return events with type "nuclear explosion" as well as
        "quarry blast".

        Both issues can probably be solved within a rather short time frame and
        should not be a show stopper. But since the web service specification is
        supposed to be usable for years to come, a clarification prior to
        approval will certainly pay off.

        Regards
        Joachim


        [1] http://www.fdsn.org/message-center/thread/488/#m-823
        [2] http://www.isc.ac.uk/standards/event_types/event_types.pdf
        [3] http://www.fdsn.org/message-center/thread/427/

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


        • Florian Haslinger
          2018-09-18 19:26:26
          Hi Domingo & all,

          we probably are getting slightly ‘confused’ on this discussion (noones fault, and nothing new ;-)… let me try to take a step back and recap (and apologies for undertaking this, it shouldn’t be my role…)

          - the discussion as we have it now is sort of a repeat of the discussion in this list shortly before the Kobe meeting last year, and also during the WG III meeting in Kobe (check the minutes at http://www.fdsn.org/media/wg/III/2017/Minutes_FDSN_WGIII_Minutes.pdf ).

          The minutes don’t reflect any decision on how to move forward with event types, as far as I remember we somehow seemed to agree that
          a) event type discussions should better be led by CoSOI as the relevant IASPEI body - where everybody is invited to join

          b) for the fdsn event webservice we might go ahead now and follow the quakeML event types which in turn take up the ISC/ISF (CoSOI approved) list - knowing quite well that updates will be required.


          I would suggest that this would still be a pragmatic way forward - the event types are already used and deemed useful by many, so let’s accept the proposal for the fdsnws-event 1.2 specification.

          One minor possible change in the fdsnws specs: If we would want to reflect the ‘authoritativeness’ of the event-type declaration, we could change the ‘description’ (in table 5 of Tim’s specifications 1.2 document, and wherever else it may appear) from
          ‘Allowed values are from the QuakeML 1.2 EventType enumeration’ to ‘Allowed values are from the ISF2.0 event type enumeration, with the syntax as implemented in QuakeML 1.2’ (if the second half statement is necessary to clarify syntax?).

          Note that the ISF2.0 as well as QuakeML 1.2 were ‘recognized’ and encouraged for wider implementation by the IASPEI during the 2015 Prague meeting. So authoritatively we should be safe, for now...


          For any follow-up discussion on event types, interested parties should approach CoSOI and take up this discussion there - maybe with an initiative from the FDSN WG III?
          (the website http://iaspei.org/commissions/commission-on-seismological-observation-and-interpretation is a bit outdated, it seems - not sure who the current chair is (Dmitry handed over to Thomas Meier at some point, as I recall (or was it the other way around?))


          By the way, I didn’t know that QuakeML 1.3 was anywhere … I had thought that we are currently moving to 2.0? But I may just not be up to date. In any case, I would not wait for QuakeML 2.0 now - regarding event types it probably won’t change, as long as ISF2.0 doesn’t change… (at least the current QuakeML 2.0BEDTypes are the same…)


          cheers
          florian





          On 18 Sep 2018, at 1:28 PM, Domingo Ballesta, Jordi (KNMI) <jordi.domingo.ballesta<at>knmi.nl<jordi.domingo.ballesta<at>knmi.nl>> wrote:

          Hi Joachim, Florian,


          I completely agree on using an harmonized list of event types, and if it is structured, much better. However, I wouldn't use a list of event types from ISC or QuakeML 1.3 in a fdsnws-event version that returns QuakeML 1.2.


          For me, it doesn't make sense to search for certain a event type (which belongs to the new list), and get as a result a QuakeML 1.2 with a different event type. In addition, the event type of the text format (QuakeML 1.3 / ISC) might be different from the event type of the xml format (QuakeML 1.2).


          In other words, I would either:


          a) go ahead with the current proposed specification (list of event types from QuakeML 1.2 and return QuakeML 1.2 format)


          b) wait until QuakeML 1.3 is released (then use the list of event types from QuakeML 1.3 and return QuakeML 1.3 format)


          My vote goes for any of the 2 options as long as it is implemented in a (relative) short time frame.


          Kind regards,


          Jordi Domingo Ballesta
          Advisor IT and Data Management
          ............................................................
          R&D Seismology and Acoustics
          KNMI (Royal Netherlands Meteorological Institute)
          Ministry of Infrastructure and Water Management
          Utrechtseweg 297 | 3731 GA De Bilt | The Netherlands
          Postbus 201 | 3730 AE De Bilt | The Netherlands
          ............................................................
          T +31 (0)30 22 06 670
          M +31 (0)6 17 017 546
          jordi.domingo.ballesta<at>knmi.nl<jordi.domingo.ballesta<at>knmi.nl>
          http://rdsa.knmi.nl/
          ............................................................


          ________________________________
          From: fdsn-wg3-products-bounce<at>lists.fdsn.org <fdsn-wg3-products-bounce<at>lists.fdsn.org> on behalf of Florian Haslinger <florian.haslinger<at>sed.ethz.ch>
          Sent: 14 September 2018 10:11 AM
          To: FDSN Working Group III
          Subject: Re: [fdsn-wg3-products] Fdsnws-event update specification to include event type

          Hi Joachim, hello all,

          I had written an email yesterday that related to what Joachim brought up below, but deleted it before sending :-)

          While I certainly agree that we are as a community not ‘at the end’ of the eventtyp discussion, I think that this can and should be tackled with the versioning of the fdsnws-releases, and I much prefer having prescribed values for those type collections rather than e.g. the current magnitude-type which seems to be ‘free’, only with some suggestions of how mag types could be called / written.

          So - let’s discuss extensions (and proper structuring) of event types, but let’s start implementing it with what we have now.

          Regarding the ISF / ISC event types and QuakeML 1.2, I believe they do match ‘exactly’ - comparing the ISC document that Joachim refer’s (Storchak et al 2012) and the QuakeML basic event description "QuakeML-BED-20130214b.pdf” from https://quake.ethz.ch/quakeml/Documents (which I believe is the valid QuakeML1.2 document).

          Regarding hierarchy, note that the ISC eventtype suggestion states
          “the above bullet-point hierarchy of event types is not part of the standard formats. Nevertheless its presence in this document helps to explain that event type reporters can be as general or as detailed as they so desire”
          and I would interpret this to mean that there shall be no expectation that in a search for events by type, any hiearchy following this is implemented by default.
          Of course a service may specifiy that they do honor that hierarchy (or any other) - here I am not sure what the fdsnws is actually implementing. (Some features of hierarchical search could be implemented by using wildcards, but certainly not all and it’s an ugly fix anyway).

          One ‘difference' between the QuakeML 1.2 parameters and ISC eventtype list is that QuakeML breaks the ISC types down further, where ISC lumps them together (I guess mainly due to lack of letters - remember that the ‘keep to one letter’ was a hard requirement for that ISC type description). But even that breakdown follows the ‘proposed nomenclature for application in QuakeML’ from the ISC document (also cf. the comment on hierarchy at the end of that section)

          Just on the side - there is no mechanism to use the ISC/ISF ‘letter code’ for the event type in the fdsnws, I believe?

          cheers
          florian



          On 14 Sep 2018, at 9:34 AM, Joachim Saul <saul<at>gfz-potsdam.de<saul<at>gfz-potsdam.de>> wrote:

          Hello WG III!

          Technically, the eventtype parameter is certainly a very useful and
          highly appreciated addition to fdsnws-event. It needs to be noted,
          however, that adoption of the QuakeML 1.2 event type list in an FDSN
          standard might make future improvements more complicated.

          In particular, we know that there is a QuakeML version 1.3 planned that
          shall include an improved and/or more complete list of event types [1].
          ETHZ please provide an update on the current status. We also know that
          there is the list of event types of the ISC [2], which is similar but
          not fully compatible with the QuakeML 1.2 list of event types. AFAIK the
          QuakeML 1.3 list of event types shall become fully compatible with that
          of the ISC (provided the ISC list is a "final" version).

          The main difference between the QuakeML 1.2 list and the ISC list is
          that the latter is structured. There are categories like "anthropogenic
          event", which contain subcategories like "explosion", which in turn may
          be a "nuclear explosion" but also a "quarry blast". But both "nuclear
          explosion" and "quarry blast" belong to "explosion". The QuakeML 1.2
          event list, in contrast, is not structured, just a flat list of possible
          values. This means that if a user searches for events of type
          "explosion", the web service according to the current specification
          would neither include events of type "nuclear explosion" nor "quarry
          blast". This will inevitably lead to a lot of confusion.

          In July 2016 there were remarks on this list about QuakeML lacking more
          specific types of landslide events (Jeremy Fee) and volcanic events
          (Glenn Thompson) [3]. I don't know if there are plans to extend QuakeML
          1.3 and/or the ISC list to better accommodate these domains but it would
          probably now be a good opportunity.

          We will probably soon have to deal with mars quakes, too. :)

          Until QuakeML 1.3 is released as the official successor of 1.2 we
          consider the ISC event type list superior, especially in the context of
          data requests. GEOFON therefore disapproves the eventtype parameter
          specification in its present form and proposes to

          (1) Seek a clarification from the ISC whether its current list [2] is
          "final".

          (2) Adopt in the fdsnws-event specification either the structured ISC
          list or the QuakeML 1.3 list (if available) rather than the
          inappropriate and soon-obsolete QuakeML 1.2 list. A conforming
          fdsnws-event implementation will have to "know" that a "nuclear
          explosion" is also an "explosion" and that a request for "explosion"
          will have to return events with type "nuclear explosion" as well as
          "quarry blast".

          Both issues can probably be solved within a rather short time frame and
          should not be a show stopper. But since the web service specification is
          supposed to be usable for years to come, a clarification prior to
          approval will certainly pay off.

          Regards
          Joachim


          [1] http://www.fdsn.org/message-center/thread/488/#m-823
          [2] http://www.isc.ac.uk/standards/event_types/event_types.pdf
          [3] http://www.fdsn.org/message-center/thread/427/

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


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


          • Sorry Florian et al., but....

            Florian Haslinger wrote on 09/18/2018 02:27 PM:
            b) for the fdsn event webservice we might go ahead now and follow the
            quakeML event types which in turn take up the ISC/ISF (CoSOI approved)
            list - knowing quite well that updates will be required.


            I would suggest that this would still be a pragmatic way forward - the
            event types are already used and deemed useful by many, so let’s accept
            the proposal for the fdsnws-event 1.2 specification.

            ... you are missing the point that I was trying to make in my previous
            email. For *describing* an event, the QuakeML 1.2 event naming is just
            fine. You can say that an event was a "nuclear explosion" or -- if you
            are not so sure -- just label it "explosion". If it was indeed a nuclear
            explosion, both could in principle be considered "correct". This is
            reflected in the structured ISC list, in which "nuclear explosion" is a
            *subset* of "explosion".

            So far, so good! Following that logic, a user requesting "explosion"
            events would expect to also get events labeled as "nuclear explosion" as
            well as "quarry blast". Would anyone disagree?

            But in the (flat) QuakeML 1.2 list there is absolutely no notion that
            "nuclear explosion" is a subset of "explosion". As a consequence a user
            requesting "explosion" events will get neither events of type "nuclear
            explosion" nor any other subtype of "explosion" according to the ISC
            list. Unless implemented otherwise, but that's not guaranteed as it is
            not part of the current specification draft.

            This is ugly and should be changed before adoption as a standard. That's
            all.

            Of course one may argue that users, who have learned to work around
            weaknesses of other FDSN standards, will also learn how to deal with
            this one. But I don't think that's the right approach.

            Regards
            Joachim

            • Florian Haslinger
              2018-09-18 21:18:07
              Hi Joachim

              no need to be sorry :-)

              what I was trying to point out is that - while the notion seems attractive, indeed - there should not be an expectation that the event type as used in either ISF2.0 or QuakeML 1.2 can be used ‘hierarchical’.

              (that’s why I cited the statement of the Storchak et al document in one of my prev. emails:
              The above bullet-point hierarchy of event types is not part of the standard formats. Nevertheless its presence in this document helps to explain that event type reporters can be as general or as detailed as they so desire

              So I would ‘disagree’ with your statement that a user may expect to get any explosion (actually, a user can expect whatever she/he wants, but at the end they should read the manual…). But this is probably up to interpretation.


              I would certainly not mind if the fdsn service would technically implement this, but - if that’s not feasible for whatever reason (lack of resources may be one…) for the moment I would be content with having it described properly.

              Maybe that could be clarified in the specification text - with examples, so that users know what to do in order to get ‘all explosions’ or ‘all earthquakes’ … (use wildcards or just comma separated lists).

              cheers
              florian



              On 18 Sep 2018, at 4:00 PM, Joachim Saul <saul<at>gfz-potsdam.de<saul<at>gfz-potsdam.de>> wrote:

              Sorry Florian et al., but....

              Florian Haslinger wrote on 09/18/2018 02:27 PM:
              b) for the fdsn event webservice we might go ahead now and follow the
              quakeML event types which in turn take up the ISC/ISF (CoSOI approved)
              list - knowing quite well that updates will be required.


              I would suggest that this would still be a pragmatic way forward - the
              event types are already used and deemed useful by many, so let’s accept
              the proposal for the fdsnws-event 1.2 specification.

              ... you are missing the point that I was trying to make in my previous
              email. For *describing* an event, the QuakeML 1.2 event naming is just
              fine. You can say that an event was a "nuclear explosion" or -- if you
              are not so sure -- just label it "explosion". If it was indeed a nuclear
              explosion, both could in principle be considered "correct". This is
              reflected in the structured ISC list, in which "nuclear explosion" is a
              *subset* of "explosion".

              So far, so good! Following that logic, a user requesting "explosion"
              events would expect to also get events labeled as "nuclear explosion" as
              well as "quarry blast". Would anyone disagree?

              But in the (flat) QuakeML 1.2 list there is absolutely no notion that
              "nuclear explosion" is a subset of "explosion". As a consequence a user
              requesting "explosion" events will get neither events of type "nuclear
              explosion" nor any other subtype of "explosion" according to the ISC
              list. Unless implemented otherwise, but that's not guaranteed as it is
              not part of the current specification draft.

              This is ugly and should be changed before adoption as a standard. That's
              all.

              Of course one may argue that users, who have learned to work around
              weaknesses of other FDSN standards, will also learn how to deal with
              this one. But I don't think that's the right approach.

              Regards
              Joachim

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


          • Domingo Ballesta, Jordi (KNMI)
            2018-09-19 22:49:18
            Dear all,


            We agree on Florian's suggestion to move forward:


            I would suggest that this would still be a pragmatic way forward - the event types are already used and deemed useful by many, so let’s accept the proposal for the fdsnws-event 1.2 specification.

            One minor possible change in the fdsnws specs: If we would want to reflect the ‘authoritativeness’ of the event-type declaration, we could change the ‘description’ (in table 5 of Tim’s specifications 1.2 document, and wherever else it may appear) from ‘Allowed values are from the QuakeML 1.2 EventType enumeration’ to ‘Allowed values are from the ISF2.0 event type enumeration, with the syntax as implemented in QuakeML 1.2’ (if the second half statement is necessary to clarify syntax?).


            Cheers,

            Jordi

            ________________________________
            From: Haslinger Florian <florian.haslinger<at>sed.ethz.ch>
            Sent: 18 September 2018 14:26:26
            To: FDSN Working Group III
            Cc: Domingo Ballesta, Jordi (KNMI)
            Subject: Re: [fdsn-wg3-products] Fdsnws-event update specification to include event type

            Hi Domingo & all,

            we probably are getting slightly ‘confused’ on this discussion (noones fault, and nothing new ;-)… let me try to take a step back and recap (and apologies for undertaking this, it shouldn’t be my role…)

            - the discussion as we have it now is sort of a repeat of the discussion in this list shortly before the Kobe meeting last year, and also during the WG III meeting in Kobe (check the minutes at http://www.fdsn.org/media/wg/III/2017/Minutes_FDSN_WGIII_Minutes.pdf ).

            The minutes don’t reflect any decision on how to move forward with event types, as far as I remember we somehow seemed to agree that
            a) event type discussions should better be led by CoSOI as the relevant IASPEI body - where everybody is invited to join

            b) for the fdsn event webservice we might go ahead now and follow the quakeML event types which in turn take up the ISC/ISF (CoSOI approved) list - knowing quite well that updates will be required.


            I would suggest that this would still be a pragmatic way forward - the event types are already used and deemed useful by many, so let’s accept the proposal for the fdsnws-event 1.2 specification.

            One minor possible change in the fdsnws specs: If we would want to reflect the ‘authoritativeness’ of the event-type declaration, we could change the ‘description’ (in table 5 of Tim’s specifications 1.2 document, and wherever else it may appear) from
            ‘Allowed values are from the QuakeML 1.2 EventType enumeration’ to ‘Allowed values are from the ISF2.0 event type enumeration, with the syntax as implemented in QuakeML 1.2’ (if the second half statement is necessary to clarify syntax?).

            Note that the ISF2.0 as well as QuakeML 1.2 were ‘recognized’ and encouraged for wider implementation by the IASPEI during the 2015 Prague meeting. So authoritatively we should be safe, for now...


            For any follow-up discussion on event types, interested parties should approach CoSOI and take up this discussion there - maybe with an initiative from the FDSN WG III?
            (the website http://iaspei.org/commissions/commission-on-seismological-observation-and-interpretation is a bit outdated, it seems - not sure who the current chair is (Dmitry handed over to Thomas Meier at some point, as I recall (or was it the other way around?))


            By the way, I didn’t know that QuakeML 1.3 was anywhere … I had thought that we are currently moving to 2.0? But I may just not be up to date. In any case, I would not wait for QuakeML 2.0 now - regarding event types it probably won’t change, as long as ISF2.0 doesn’t change… (at least the current QuakeML 2.0BEDTypes are the same…)


            cheers
            florian





            On 18 Sep 2018, at 1:28 PM, Domingo Ballesta, Jordi (KNMI) <jordi.domingo.ballesta<at>knmi.nl<jordi.domingo.ballesta<at>knmi.nl>> wrote:

            Hi Joachim, Florian,


            I completely agree on using an harmonized list of event types, and if it is structured, much better. However, I wouldn't use a list of event types from ISC or QuakeML 1.3 in a fdsnws-event version that returns QuakeML 1.2.


            For me, it doesn't make sense to search for certain a event type (which belongs to the new list), and get as a result a QuakeML 1.2 with a different event type. In addition, the event type of the text format (QuakeML 1.3 / ISC) might be different from the event type of the xml format (QuakeML 1.2).


            In other words, I would either:


            a) go ahead with the current proposed specification (list of event types from QuakeML 1.2 and return QuakeML 1.2 format)


            b) wait until QuakeML 1.3 is released (then use the list of event types from QuakeML 1.3 and return QuakeML 1.3 format)


            My vote goes for any of the 2 options as long as it is implemented in a (relative) short time frame.


            Kind regards,


            Jordi Domingo Ballesta
            Advisor IT and Data Management
            ............................................................
            R&D Seismology and Acoustics
            KNMI (Royal Netherlands Meteorological Institute)
            Ministry of Infrastructure and Water Management
            Utrechtseweg 297 | 3731 GA De Bilt | The Netherlands
            Postbus 201 | 3730 AE De Bilt | The Netherlands
            ............................................................
            T +31 (0)30 22 06 670
            M +31 (0)6 17 017 546
            jordi.domingo.ballesta<at>knmi.nl<jordi.domingo.ballesta<at>knmi.nl>
            http://rdsa.knmi.nl/
            ............................................................


            ________________________________
            From: fdsn-wg3-products-bounce<at>lists.fdsn.org <fdsn-wg3-products-bounce<at>lists.fdsn.org> on behalf of Florian Haslinger <florian.haslinger<at>sed.ethz.ch>
            Sent: 14 September 2018 10:11 AM
            To: FDSN Working Group III
            Subject: Re: [fdsn-wg3-products] Fdsnws-event update specification to include event type

            Hi Joachim, hello all,

            I had written an email yesterday that related to what Joachim brought up below, but deleted it before sending :-)

            While I certainly agree that we are as a community not ‘at the end’ of the eventtyp discussion, I think that this can and should be tackled with the versioning of the fdsnws-releases, and I much prefer having prescribed values for those type collections rather than e.g. the current magnitude-type which seems to be ‘free’, only with some suggestions of how mag types could be called / written.

            So - let’s discuss extensions (and proper structuring) of event types, but let’s start implementing it with what we have now.

            Regarding the ISF / ISC event types and QuakeML 1.2, I believe they do match ‘exactly’ - comparing the ISC document that Joachim refer’s (Storchak et al 2012) and the QuakeML basic event description "QuakeML-BED-20130214b.pdf” from https://quake.ethz.ch/quakeml/Documents (which I believe is the valid QuakeML1.2 document).

            Regarding hierarchy, note that the ISC eventtype suggestion states
            “the above bullet-point hierarchy of event types is not part of the standard formats. Nevertheless its presence in this document helps to explain that event type reporters can be as general or as detailed as they so desire”
            and I would interpret this to mean that there shall be no expectation that in a search for events by type, any hiearchy following this is implemented by default.
            Of course a service may specifiy that they do honor that hierarchy (or any other) - here I am not sure what the fdsnws is actually implementing. (Some features of hierarchical search could be implemented by using wildcards, but certainly not all and it’s an ugly fix anyway).

            One ‘difference' between the QuakeML 1.2 parameters and ISC eventtype list is that QuakeML breaks the ISC types down further, where ISC lumps them together (I guess mainly due to lack of letters - remember that the ‘keep to one letter’ was a hard requirement for that ISC type description). But even that breakdown follows the ‘proposed nomenclature for application in QuakeML’ from the ISC document (also cf. the comment on hierarchy at the end of that section)

            Just on the side - there is no mechanism to use the ISC/ISF ‘letter code’ for the event type in the fdsnws, I believe?

            cheers
            florian



            On 14 Sep 2018, at 9:34 AM, Joachim Saul <saul<at>gfz-potsdam.de<saul<at>gfz-potsdam.de>> wrote:

            Hello WG III!

            Technically, the eventtype parameter is certainly a very useful and
            highly appreciated addition to fdsnws-event. It needs to be noted,
            however, that adoption of the QuakeML 1.2 event type list in an FDSN
            standard might make future improvements more complicated.

            In particular, we know that there is a QuakeML version 1.3 planned that
            shall include an improved and/or more complete list of event types [1].
            ETHZ please provide an update on the current status. We also know that
            there is the list of event types of the ISC [2], which is similar but
            not fully compatible with the QuakeML 1.2 list of event types. AFAIK the
            QuakeML 1.3 list of event types shall become fully compatible with that
            of the ISC (provided the ISC list is a "final" version).

            The main difference between the QuakeML 1.2 list and the ISC list is
            that the latter is structured. There are categories like "anthropogenic
            event", which contain subcategories like "explosion", which in turn may
            be a "nuclear explosion" but also a "quarry blast". But both "nuclear
            explosion" and "quarry blast" belong to "explosion". The QuakeML 1.2
            event list, in contrast, is not structured, just a flat list of possible
            values. This means that if a user searches for events of type
            "explosion", the web service according to the current specification
            would neither include events of type "nuclear explosion" nor "quarry
            blast". This will inevitably lead to a lot of confusion.

            In July 2016 there were remarks on this list about QuakeML lacking more
            specific types of landslide events (Jeremy Fee) and volcanic events
            (Glenn Thompson) [3]. I don't know if there are plans to extend QuakeML
            1.3 and/or the ISC list to better accommodate these domains but it would
            probably now be a good opportunity.

            We will probably soon have to deal with mars quakes, too. :)

            Until QuakeML 1.3 is released as the official successor of 1.2 we
            consider the ISC event type list superior, especially in the context of
            data requests. GEOFON therefore disapproves the eventtype parameter
            specification in its present form and proposes to

            (1) Seek a clarification from the ISC whether its current list [2] is
            "final".

            (2) Adopt in the fdsnws-event specification either the structured ISC
            list or the QuakeML 1.3 list (if available) rather than the
            inappropriate and soon-obsolete QuakeML 1.2 list. A conforming
            fdsnws-event implementation will have to "know" that a "nuclear
            explosion" is also an "explosion" and that a request for "explosion"
            will have to return events with type "nuclear explosion" as well as
            "quarry blast".

            Both issues can probably be solved within a rather short time frame and
            should not be a show stopper. But since the web service specification is
            supposed to be usable for years to come, a clarification prior to
            approval will certainly pay off.

            Regards
            Joachim


            [1] http://www.fdsn.org/message-center/thread/488/#m-823
            [2] http://www.isc.ac.uk/standards/event_types/event_types.pdf
            [3] http://www.fdsn.org/message-center/thread/427/

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


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


  • Dear Tim and FDSN WG-III,


    Indeed, we at the ISC are the original authors of the 2012 document
    “Nomenclature of Event Types
    <www.isc.ac.uk/standards/event_types/event_types.pdf>”. We prepared this
    document together with our colleagues at NEIC and EMSC, based on our
    mutual experience of receiving and parsing external bulletin reports
    from many tens of agencies around the world. The document suggests
    implementation in both ISF and QuakeML formats. It was specifically
    designed for reporting event types taking into account the most peculiar
    requirements of real life. This *short* *document* also lists our
    considerations for preparing this document. I urge our colleagues to
    have at least a quick look.

    We, at the ISC, are strongly in favour of keeping event type as part of
    the QuakeML format. It is indeed unfortunate that the hierarchy
    maintained in the document was not implemented in the QML. Nevertheless,
    what was implemented, does allow to report event type information as
    general as required or as detailed as required (with a few deficiencies
    picked up by Florian and Joachim as part of this communication).

    We, at the ISC, strongly oppose though a possibility of a webservice
    that would search through databases for events of certain type. Sadly,
    but the information that we all currently have at our hands today is
    often inconsistent, time variable and contradicting. If used by an
    inexperienced person (XX%), it can and will lead to misinterpretations,
    misconceptions, wrong assumptions, never mind political or legal
    disputes. We can think of many examples of various nature, illustrating
    our concern, including the one brought up by Joachim Saul. Moreover, it
    is our observation that event type reporting is sadly on considerable
    decline.

    We don’t feel it would be timely or convenient to flood you with
    examples of possible horrible misinterpretations. We though would be
    quite happy to prepare an appropriate presentation for the next meeting
    of this working group in Montreal (IUGG, July 2019). This is a delay,
    but this is a serious issue and better be discussed properly.

    In summary, we think that event type should have a prominent role in
    QuakeML format as is the case already. We should think of a way to
    address the hierarchy of general/detailed event types of similar nature
    in QML if at all possible. We strongly oppose a webservice that searches
    by event type until that point in time when the historical archives have
    been homogenised and current reporting was given a boost and standardised.

    Dmitry Storchak, James Harris, Domenico Di Giacomo

    ISC

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

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

    On 11/09/2018 19:16, Tim Ahern wrote:
    Greetings members of FDSN WG III

    Attached is version 1.2 of the FDSN WS specification with modifications to the FDSN event service related to the addition of the EventType parameter and text-format field for the fdsnws-event service (versioned as 1.2).

    Please review this and indicate your approval or disapproval of this change by September 25, two weeks from today.

    Please send your responses to the list so that others can see your response.


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



    • Hello FDSN WG-III,

      Some thoughts regarding the web service specification. Clearly some members have a need to offer search capability based on event type. If it is not included in the interface standard we risk centers adding non-standard extensions, likely uncoordinated and bifurcating in definition. The proposal is that the capability is optional; if a center does not want to support such search capability because their catalogs are non-homogenized in this aspect they are not forced to. On the other hand, it would be to our collective advantage to allow centers that have well crafted catalogs using the already-defined types in QuakeML/ISF to offer search capability in a consistent way.

      My only small reservation with the proposal is that it could be simpler in definition, in particular not including a list of event types, as those should be defined elsewhere in QuakeML or ISF or wherever. The event type list accepted by the parameter could simply be defined as that matching the version of QuakeML being requested; in the case of non-QuakeML output (e.g. text) the event type could be service dependent, e.g. whatever is in the catalogs being searched (it's not perfect but the text output format is unconstrained in a number of ways already such as coordinate datum). This keeps the service specification independent of the event types, a bit future proof and will allow the general use case of selecting by type to move forward.

      regards,
      Chad


      On Sep 18, 2018, at 8:44 AM, Dmitry Storchak <dmitry<at>isc.ac.uk> wrote:


      Dear Tim and FDSN WG-III,

      Indeed, we at the ISC are the original authors of the 2012 document “Nomenclature of Event Types <x-msg://1/www.isc.ac.uk/standards/event_types/event_types.pdf>”. We prepared this document together with our colleagues at NEIC and EMSC, based on our mutual experience of receiving and parsing external bulletin reports from many tens of agencies around the world. The document suggests implementation in both ISF and QuakeML formats. It was specifically designed for reporting event types taking into account the most peculiar requirements of real life. This short document also lists our considerations for preparing this document. I urge our colleagues to have at least a quick look.

      We, at the ISC, are strongly in favour of keeping event type as part of the QuakeML format. It is indeed unfortunate that the hierarchy maintained in the document was not implemented in the QML. Nevertheless, what was implemented, does allow to report event type information as general as required or as detailed as required (with a few deficiencies picked up by Florian and Joachim as part of this communication).

      We, at the ISC, strongly oppose though a possibility of a webservice that would search through databases for events of certain type. Sadly, but the information that we all currently have at our hands today is often inconsistent, time variable and contradicting. If used by an inexperienced person (XX%), it can and will lead to misinterpretations, misconceptions, wrong assumptions, never mind political or legal disputes. We can think of many examples of various nature, illustrating our concern, including the one brought up by Joachim Saul. Moreover, it is our observation that event type reporting is sadly on considerable decline.

      We don’t feel it would be timely or convenient to flood you with examples of possible horrible misinterpretations. We though would be quite happy to prepare an appropriate presentation for the next meeting of this working group in Montreal (IUGG, July 2019). This is a delay, but this is a serious issue and better be discussed properly.

      In summary, we think that event type should have a prominent role in QuakeML format as is the case already. We should think of a way to address the hierarchy of general/detailed event types of similar nature in QML if at all possible. We strongly oppose a webservice that searches by event type until that point in time when the historical archives have been homogenised and current reporting was given a boost and standardised.

      Dmitry Storchak, James Harris, Domenico Di Giacomo
      ISC
      Dr. Dmitry A. Storchak
      Director
      International Seismological Centre (ISC)
      United Kingdom

      www.isc.ac.uk <http://www.isc.ac.uk/
      +44 (0)1635 861022
      On 11/09/2018 19:16, Tim Ahern wrote:
      Greetings members of FDSN WG III

      Attached is version 1.2 of the FDSN WS specification with modifications to the FDSN event service related to the addition of the EventType parameter and text-format field for the fdsnws-event service (versioned as 1.2).

      Please review this and indicate your approval or disapproval of this change by September 25, two weeks from today.

      Please send your responses to the list so that others can see your response.


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


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


  • Hi Tim

    Can you clarify, is this vote is what we would like to see as 1.2, or
    is this vote only whether this document accurately reflects the
    changes to support event type that were previously approved in Kobe?

    The reason I am asking for clarification on the context of this vote
    is if there is going to be a spec revision to 1.2, why does it not
    include the other items discussed in Kobe and I think were not
    objected to? In particular allowing a "Z" on the end of times in the
    query params and relaxing the restriction that web services must run
    on port 80 to allow both http and https (port 443)?

    My feeling is that spec revisions are and should be rare events and so
    it would be wise to address these two issues now, if possible, instead
    of waiting. And, IMHO, these two are more important and have a wider
    effect than event types.

    At a minimum I would like to understand why event type is moving
    forward while the Z and https are not? Perhaps I am misunderstanding
    what happened in Kobe and the context of this vote.

    Thanks
    Philip



    On Tue, Sep 11, 2018 at 2:16 PM, Tim Ahern <tim<at>iris.washington.edu> wrote:
    Greetings members of FDSN WG III

    Attached is version 1.2 of the FDSN WS specification with modifications to the FDSN event service related to the addition of the EventType parameter and text-format field for the fdsnws-event service (versioned as 1.2).

    Please review this and indicate your approval or disapproval of this change by September 25, two weeks from today.

    Please send your responses to the list so that others can see your response.


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


  • Dear colleagues,

    Personally, i support specification updated proposed by Tim.

    I would suggest to include the permit of offering fdsn services over https, as obviously a formal decision on this already exists.
    If doing so, i would also add some clarifying text on the wadl:
    As in the WADL standard (https://www.w3.org/Submission/wadl/#x3-110002.5), the base url including protocol and port is a property of the <resources> tag, and the resources tag is one, there *must* different WADLs for those services offered over http, and those offered over https, if both are present.


    Note that this is not an official ETH vote; afaik John is the representative.


    best regards,

    Philipp

    (Philipp Kästli, SED/ETHZ)


    ------------------------------------------------------
    some comments on other proposals and topics discussed

    QuakeML 1.2 is defined as a response format, thus the possible event types in the response should be the ones of QuakeML 1.2,
    without further assumptions. Assuming a specific hierarchy in event type terms in the query, while there is none specified for
    the QuakeML 1.2 response format is not recommended; it would lead to overinterpretation and probably wrong responses if the
    hierarchy added in the service definition is different from the one the data provider used when preparing the data.
    There is no harm in listing these event types in the web service specification, as it is fixed anyway by mentioning the
    response format and version. While the original version of the type list is in the QuakeML specification, it is just helpful
    for the user to have it also directly in the service specifiation.

    (on the proposal of Chad)
    - I strongly discourage ideas to allow for different event types (as request parameter value as well as for response content)
    for xml and txt response. Assume somebody would introduce an event type "vulcanic tremor" for text formats, he would either
    have to label the event differently (e.g, as earthquake), if QuakeML response format is requested, or suppress it entirely
    entirely. In either case, the information content would be dependent on the format tag. I think this should not be the case. If
    called "format", it should only define alternative formats, not alternative datasets.
    - To have the event query parameter optional in fdsn/event? As it is the only relevant change between fdsn event 1.1 and 1.2, i
    would tend to request it as mandatory in 1.2. If a data center does not want to implement it, it can easily stick to
    specification 1.1. A world with services of version 1.1 (without event type), services of version 1.2 (partial implementation,
    with event type in text response, but not as a query option), and services of version 1.2 (full implementation, event type both
    as query parameter and in text responses) seems unnecessarily complicated for a standard user.


    (on the proposal of Florian) I would not recommend to allow type search based on partly wildcards or regular expressions, as
    there is little use and many the event type terms currently used, while there is a considerable risk for errors, e.g.
    - "*explosion" earns many types of explosions, excluding "quarry blast"
    - "*blast" earns not only quarry and sonic blasts, but also blasting levees
    - there are many flavours of regular expressions

    (on the proposals of Joachim and Luca) QuakeML basic event description 1.3 is a bit out of the scope of discussion here, as the
    proposed fdsnws/station specification update still defines QuakeML 1.2 as the response format. Changing to QuakeML 2.0/QuakeML
    Basic Event Description 1.3 as a response format will be yet another version of the service specification, and it should be
    done after the question of event type is sorted out well for the response format.
    However, as Fabian pointed out, we have planned to base the event type on a SKOS vocabulary, starting the USGS/ISC/EMSC
    proposal including its type hierarchy (and potential changes if requested). As an option, we could, in the next version of
    quakeML, add two attributes to the event: one toto provide an event type term, and a second one to indicate the terminology it
    refers to (with the quakeml BED 1.3 terminology as the default one).
    As one more degree of freedom, we could allow for classifying an event according to multiple terminologies (e.g. it is an
    "earthquake" according to BED 1.3 terminology, but at the same time a "tremor burst" according to some vulcanological
    terminology).
    This would allow much flexibility in describing events, but it would make it more challanging to interpret the data).
    As this discussion refers more to quakeml than to fdsn/event, please post your contributions to this discussion preferably on
    the QuakeML mailing list.


    From: fdsn-wg3-products-bounce<at>lists.fdsn.org [fdsn-wg3-products-bounce<at>lists.fdsn.org] On Behalf Of Tim Ahern
    Sent: Dienstag, 11. September 2018 20:17
    To: FDSN Working Group III
    Subject: [fdsn-wg3-products] Fdsnws-event update specification to include event type

    Greetings members of FDSN WG III

    Attached is version 1.2 of the FDSN WS specification with modifications to the FDSN event service related to the addition of the EventType parameter and text-format field for the fdsnws-event service (versioned as 1.2).

    Please review this and indicate your approval or disapproval of this change by September 25, two weeks from today.

    Please send your responses to the list so that others can see your response.


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


  • We approve of the changes, with the expectation that the question about the use of wildcards (or not) be addressed. The type values should also be as found in the underlying QuakeML format which is being served (as suggested by Chad).

    Mark Chadwick
    GNS Science, New Zealand


    From: fdsn-wg3-products-bounce<at>lists.fdsn.org <fdsn-wg3-products-bounce<at>lists.fdsn.org> On Behalf Of Tim Ahern
    Sent: Wednesday, September 12, 2018 6:17 AM
    To: FDSN Working Group III <fdsn-wg3-products<at>lists.fdsn.org>
    Subject: [fdsn-wg3-products] Fdsnws-event update specification to include event type

    Greetings members of FDSN WG III

    Attached is version 1.2 of the FDSN WS specification with modifications to the FDSN event service related to the addition of the EventType parameter and text-format field for the fdsnws-event service (versioned as 1.2).

    Please review this and indicate your approval or disapproval of this change by September 25, two weeks from today.

    Please send your responses to the list so that others can see your response.


    Regards
    Tim Ahern

    Chair
    FDSN WG III

    Notice: This email and any attachments are confidential and may not be used, published or redistributed without the prior written consent of the Institute of Geological and Nuclear Sciences Limited (GNS Science). If received in error please destroy and immediately notify GNS Science. Do not copy or disclose the contents.