Thread: Fdsnws-event update specification to include event type

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/

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/

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

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/