Fdsnws-event update specification to include event type
Tim Ahern
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
Pete Davis
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
> <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-produ...@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/
Tim Ahern
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 <pda...@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/ <http://ida.ucsd.edu/>
> (o) 858-534-2839
> (f) 858-534-6354
>
>
>
>> On Sep 11, 2018, at 11:16 AM, Tim Ahern <t...@iris.washington.edu <mailto:t...@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/ <http://www.fdsn.org/message-center/topic/fdsn-wg3-products/> | Unsubscribe: fdsn-wg3-produ...@lists.fdsn.org <mailto:fdsn-wg3-produ...@lists.fdsn.org>
>>
>> Sent from the FDSN Message Center (http://www.fdsn.org/message-center/ <http://www.fdsn.org/message-center/>)
>> Update subscription preferences at http://www.fdsn.org/account/profile/ <http://www.fdsn.org/account/profile/>
>
Stephane Zuzlewski
Stephane
> ----------------------
> FDSN Working Group III
> Topic home: http://www.fdsn.org/message-center/topic/fdsn-wg3-products/ | Unsubscribe: fdsn-wg3-produ...@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
step...@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)
Jeremy Fee
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 <t...@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 <pda...@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/ <http://ida.ucsd.edu/>*
> *(o) 858-534-2839*
> *(f) 858-534-6354*
>
>
>
> On Sep 11, 2018, at 11:16 AM, Tim Ahern <t...@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-produ...@lists.fdsn.org
>
> Sent from the FDSN Message Center (http://www.fdsn.org/message-center/)
Alexandros Savvaidis
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)
Regards
Tim Ahern
Chair
FDSN WG III
----------------------
Domingo Ballesta, Jordi (KNMI)
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.domin...@knmi.nl
http://rdsa.knmi.nl/
............................................................
________________________________
From: fdsn-wg3-pro...@lists.fdsn.org <fdsn-wg3-pro...@lists.fdsn.org> on behalf of Alexandros Savvaidis <alexandros...@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,
Best Regards,
Alexandros
Regards
Tim Ahern
Chair
FDSN WG III
Sign In<http://www.fdsn.org/account/profile/>
www.fdsn.org
FDSN is a global organization supporting seismology research.
Nikolaus Horn
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: nikola...@zamg.ac.at
www.zamg.ac.at
Join us on facebook: http://www.facebook.com/zamg.at
________________________________
Von: fdsn-wg3-pro...@lists.fdsn.org <fdsn-wg3-pro...@lists.fdsn.org> im Auftrag von Domingo Ballesta, Jordi (KNMI) <jordi.domin...@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,
Kinds regards,
Dear all,
Best Regards,
Alexandros
Regards
Tim Ahern
Chair
FDSN WG III
FDSN: FDSN Working Group III<http://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 Center<http://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 In<http://www.fdsn.org/account/profile/>
www.fdsn.org
FDSN is a global organization supporting seismology research.
Sign In<http://www.fdsn.org/account/profile/>
Sign In<http://www.fdsn.org/account/profile/>
www.fdsn.org
FDSN is a global organization supporting seismology research.
www.fdsn.org<http://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-produ...@lists.fdsn.org
FDSN: FDSN Working Group III<http://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 Center<http://www.fdsn.org/message-center/>
Jose Antonio Jara Salvador
Cheers,
Jose Antonio Jara Salvador
Head of Seismology
Institut Cartogràfic i Geològic de Catalunya
From: fdsn-wg3-pro...@lists.fdsn.org [mailto:fdsn-wg3-pro...@lists.fdsn.org] On Behalf Of Tim Ahern
Sent: dimarts, 11 / setembre / 2018 20:17
To: FDSN Working Group III
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-produ...@lists.fdsn.org<mailto:fdsn-wg3-produ...@lists.fdsn.org>
Sent from the FDSN Message Center (http://www.fdsn.org/message-center/)
Florian Haslinger
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 <sa...@gfz-potsdam.de<mailto:sa...@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/
Florian Haslinger
I am not the ‘official’ WGIII member from ETH… so my email is not any official vote on the matter from here :-)
florian
IASPEI
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
ias...@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
Joachim Saul
Domingo Ballesta, Jordi (KNMI)
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.domin...@knmi.nl
http://rdsa.knmi.nl/
............................................................
________________________________
From: fdsn-wg3-pro...@lists.fdsn.org <fdsn-wg3-pro...@lists.fdsn.org> on behalf of Florian Haslinger <florian....@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,
Florian Haslinger
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.domin...@knmi.nl<mailto:jordi.domin...@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.domin...@knmi.nl<mailto:jordi.domin...@knmi.nl>
Florian Haslinger
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 <sa...@gfz-potsdam.de<mailto:sa...@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
Joachim Saul
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
Dmitry Storchak
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
> ----------------------
> FDSN Working Group III
> Topic home: http://www.fdsn.org/message-center/topic/fdsn-wg3-products/ | Unsubscribe: fdsn-wg3-produ...@lists.fdsn.org
>
Chad Trabant
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 <dmi...@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/ <http://www.fdsn.org/message-center/topic/fdsn-wg3-products/> | Unsubscribe: fdsn-wg3-produ...@lists.fdsn.org <mailto:fdsn-wg3-produ...@lists.fdsn.org>
>>
>> Sent from the FDSN Message Center (http://www.fdsn.org/message-center/ <http://www.fdsn.org/message-center/>)
>> Update subscription preferences at http://www.fdsn.org/account/profile/ <http://www.fdsn.org/account/profile/>
>
>
> ----------------------
> FDSN Working Group III
> Topic home: http://www.fdsn.org/message-center/topic/fdsn-wg3-products/ <http://www.fdsn.org/message-center/topic/fdsn-wg3-products/> | Unsubscribe: fdsn-wg3-produ...@lists.fdsn.org <mailto:fdsn-wg3-produ...@lists.fdsn.org>
>
> Sent from the FDSN Message Center (http://www.fdsn.org/message-center/ <http://www.fdsn.org/message-center/>)
> Update subscription preferences at http://www.fdsn.org/account/profile/ <http://www.fdsn.org/account/profile/>
Philip Crotwell
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
> ----------------------
> FDSN Working Group III
> Topic home: http://www.fdsn.org/message-center/topic/fdsn-wg3-products/ | Unsubscribe: fdsn-wg3-produ...@lists.fdsn.org
>
> Sent from the FDSN Message Center (http://www.fdsn.org/message-center/)
Domingo Ballesta, Jordi (KNMI)
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....@sed.ethz.ch>
Sent: 18 September 2018 14:26:26
To: FDSN Working Group III
Cc: Domingo Ballesta, Jordi (KNMI)
Mulder, Taimi (NRCan/RNCan)
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....@canada.ca<mailto:Taimi....@canada.ca>
From: fdsn-wg3-pro...@lists.fdsn.org <fdsn-wg3-pro...@lists.fdsn.org> On Behalf Of IASPEI
Sent: September 19, 2018 10:07
To: FDSN Working Group III <fdsn-wg3...@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
ias...@norsar.no<mailto:ias...@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
Trani, Luca (KNMI)
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
tr...@knmi.nl<mailto:tr...@knmi.nl>
www.knmi.nl<http://www.knmi.nl/>
........................................................................
Philip Crotwell
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 <jm...@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 <t...@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 <pda...@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
Florian Haslinger
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
Fabian Euchner
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
--
-----------------------------------------------------------------------------
Fabian Euchner phone +41 44 633 7178
Institute of Geophysics fax +41 44 633 1065
ETH Zurich, NO F5 e-mail fab...@sed.ethz.ch
Sonneggstrasse 5 orcid.org/0000-0001-6340-7439
8092 Zurich (Switzerland)
-----------------------------------------------------------------------------
Trani, Luca (KNMI)
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
tr...@knmi.nl
www.knmi.nl
........................................................................
-----Oorspronkelijk bericht-----
Van: Fabian Euchner [mailto:fabian....@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
Philipp Kästli
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-pro...@lists.fdsn.org [mailto:fdsn-wg3-pro...@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
----------------------
Mark Chadwick
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-pro...@lists.fdsn.org <fdsn-wg3-pro...@lists.fdsn.org> On Behalf Of Tim Ahern
Sent: Wednesday, September 12, 2018 6:17 AM
To: FDSN Working Group III <fdsn-wg3...@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.