fdsn event changes
John Clinton
over the last year or so, the FDSN III mailing list has seen a number of comments / suggestions / requests for modifications to each of the FDSN web services. Despite often quite vigorous discussions, there has not yet been a clear path for how version updates are agreed and implemented.
I propose we use the (short) time before now and the IASPEI meeting in Kobe in the beginning of August to agree on how we as a community agree on version updates and how they are implemented, and if possible, propose some changes that may be ratified at Kobe.
An obvious modification that was basically agreed in exchanges last summer ( http://www.fdsn.org/message-center/thread/425/ ) was for the fdsnws event to support event type. I reiterate what I would propose for including the event type:
- support in the query (default = earthquake)
- add column for event type in the text output
- open question: limit event type to the quakeMl1.2 definitions, or extend to quakeML2.0, or leave free form to be defined in the local web service documentation. This last part is tricky, as there remain complications with hierarchies on the de facto (unpublished?) Storchak et al. standard for event types
We can also use a review period to
1. review other proposed changes posted to the mailing list related to fdsn-event that may also warrant inclusion in a new version
2. try to collect individual extensions to the standard and see if they should be included if relevant (eg USGS already support the event type, as well as other useful tools such as count, but also have some tools that are internal to USGS such as pager alert level - https://earthquake.usgs.gov/fdsnws/event/1/#parameters )
3. take the opportunity to tighten the existing specifications in places (e.g. where possible, directly specify which parameter in quakeMl1.2 maps for both the query and response format)
comments or thoughts?
regards,
John
Jean-Marie Saurel
Just a quick question as you speak about quakeML2.0.
What's the status of this new quakeML version ?
As it already been formally adopted ?
Or maybe will it be adopted at Kobé ?
Otherwise, I support the event_type filtering, that would be very usefull.
Regards.
Have a nice week-end.
Jean-Marie SAUREL.
> ----------------------
> FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)
>
> Sent from the FDSN Message Center (http://www.fdsn.org/message-center/)
> Update subscription preferences at http://www.fdsn.org/account/profile/
>
--
--------------------------------------
ICG-CARIBE-EWS Working Group 1 chair
Institut de Physique du Globe de Paris
Observatoires Volcanologiques
1 rue Jussieu
75238 Paris Cédex 05
+33(0)183957437
France
Fabian Euchner
> An obvious modification that was basically agreed in exchanges last summer (
> http://www.fdsn.org/message-center/thread/425/ ) was for the fdsnws event
> to support event type. I reiterate what I would propose for including the
> event type: - support in the query (default = earthquake)
I would make the "catch all" wildcard the default, including empty/unset values. There is
no guarantee that the underlying data model has an event type. In QuakeML, eventType is
optional and may not be set. The output from the ISC event web service, e.g., does not
include eventType.
Also, if "catch all" is the default, queries yield the same result for current services and
future eventtype-enabled ones (without using eventtype query parameter).
> - open question: limit event type to the quakeMl1.2 definitions, or extend
> to quakeML2.0, or leave free form to be defined in the local web service
> documentation. This last part is tricky, as there remain complications with
> hierarchies on the de facto (unpublished?) Storchak et al. standard for
> event types
If the results are still intended to be QuakeML 1.2, the output eventType has to be from
the list defined in QuakeML 1.2. Theoretically, the allowed values for the query parameter
could be different (e.g., in order to account for "legacy" event types), but I'm not sure if
this would be helpful rather than confusing.
Best regards,
Fabian
--
-----------------------------------------------------------------------------
Fabian Euchner phone +41 44 633 7178
Institute of Geophysics fax +41 44 633 1065
ETH Zurich, NO F5 e-mail fab...@sed.ethz.ch
Sonneggstrasse 5 orcid.org/0000-0001-6340-7439
8092 Zurich (Switzerland)
-----------------------------------------------------------------------------
QuakeML http://quakeml.org QuakePy http://quakepy.org
CSEP http://www.cseptesting.org/centers/eth
-----------------------------------------------------------------------------
Jean-Marie Saurel
Thanks for those informations.
Regarding "event type", that's also one of the limitation of QuakeML1.2
we are facing in volcanoe observatories.
Do you think it could be possible to have, in addition to the existing
or extended event types list, a possibility to reference to specific
catalogs of event types ?
I'm thinking about something similar to the SEED abbreviation
catalog/reference scheme.
This could allow to have extensive event type description, including
litterature as you point, and an event type list that could be extended
to the user specific needs.
Regards.
Jean-Marie SAUREL.
On 06/14/2017 12:33 PM, Fabian Euchner wrote:
> Hi all,
>
>
>
>> Just a quick question as you speak about quakeML2.0.
>
>>
>
>> What's the status of this new quakeML version ?
>
>
>
> "QuakeML 2.0" is an umbrella term for a series of data models/schemas
> that are currently under development. These are thematic extensions to
> QuakeML 1.2, which covers only "Basic Event Description". Some of these
> packages are already quite mature and are currently under RfC. See
> http://quakeml.org/QuakeML2.0 .
>
>
>
> There will also be an updated BasicEventDescription package (QuakeML-BED
> v1.3). This will include mild changes to the well-known QuakeML 1.2. In
> particular, the event type enumeration needs to be revised. We would
> like to introduce precise definitons with literature references, and a
> hierarchy of terms with clear semantics. Suggestions are welcome!
>
>
>
> Best regards,
>
> Fabian
> -----------------------------------------------------------------------------
>
> 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)
>
> -----------------------------------------------------------------------------
>
> QuakeML http://quakeml.org QuakePy http://quakepy.org
>
> CSEP http://www.cseptesting.org/centers/eth
>
> -----------------------------------------------------------------------------
>
>
>
Jean-Marie Saurel
> not sure whether I correctly understand what you mean.
Well, you are pretty close.
I'm not very familiar with XML semantic, but I think I was refering to
the free-text field as a reference to a URI pointing to a more precise
description elsewhere.
>
> The basic question is whether the definition of event types should be
> (i) included in the standard and be fixed, or (ii) be a free-text field.
> The latter would allow to use URIs/URLs of terms defined in other
> vocabularies, however, the drawback is that URLs are never as stable as
> one hopes. Therefore, I would suggest that we use (i) and copy all
> useful terms that we can find in other vocabularies into our own (and
> specify the semantic relation to the other term). I have the impression
> that the existing QuakeML 1.2 event type list is too detailed,
> especially for events that are served through fdsnws-event services (I
> haven't seen any train crashes or accidental explosions so far). The
> task will be to find a hierarchy that covers basic classifications of
> all communities, but is not unnecessarily broad.
>
I think I would favor both solutions.
We would like to use the QuakeML and it's associated webservices and
tools to distribute, for example, volcano events.
If we can do so, we won't need to develop our own exotic format, nor to
maintain our own webservices code and so on.
On volcano, the identification and number of events is at least as
important as their localization, sometimes even more.
Each volcano has a unique set of event types (or event species). Some
volcano have "summit events", "deep events", some others have "LP
events", "hybrid event". A "type B volcano-tectonic event" is not
necessarily the same on two different volcano.
The problem is very similar when you deal with event classification and
wants to deal with "family 123 event" and so on.
We would like to have a way to include this diversity in the QuakeML
"event type" field. And I don't think we could ever build a definitive
list of types.
Maybe there is already an additional package in QuakeML2.0 related to
this issue. In which case it could be interesting to something in the
BasicEventDescription telling the user he must look at the extension for
more precise informations.
Regards.
Jean-Marie.
>
>
> Regards,
>
> Fabian
--
Fabian Euchner
> Just a quick question as you speak about quakeML2.0.
>
> What's the status of this new quakeML version ?
"QuakeML 2.0" is an umbrella term for a series of data models/schemas that are currently
under development. These are thematic extensions to QuakeML 1.2, which covers only
"Basic Event Description". Some of these packages are already quite mature and are
currently under RfC. See http://quakeml.org/QuakeML2.0 .
There will also be an updated BasicEventDescription package (QuakeML-BED v1.3). This
will include mild changes to the well-known QuakeML 1.2. In particular, the event type
enumeration needs to be revised. We would like to introduce precise definitons with
literature references, and a hierarchy of terms with clear semantics. Suggestions are
welcome!
Best regards,
Fabian
> As it already been formally adopted ?
--
Fabian Euchner
not sure whether I correctly understand what you mean.
The basic question is whether the definition of event types should be (i) included in the
standard and be fixed, or (ii) be a free-text field. The latter would allow to use URIs/URLs
of terms defined in other vocabularies, however, the drawback is that URLs are never as
stable as one hopes. Therefore, I would suggest that we use (i) and copy all useful terms
that we can find in other vocabularies into our own (and specify the semantic relation to
the other term). I have the impression that the existing QuakeML 1.2 event type list is too
detailed, especially for events that are served through fdsnws-event services (I haven't
seen any train crashes or accidental explosions so far). The task will be to find a hierarchy
that covers basic classifications of all communities, but is not unnecessarily broad.
Regards,
Fabian
Nick Ackerley
There is a Geological Survey of Canada open file, currently under review,
explaining that the GSC is adopting a subset of the QuakeML 1.2 event
types. It includes the procedures we use in routine processing for
assigning each type (we make heavy use of "suspected" - a key innovation of
the QuakeML event type ontology, IMHO) and cites basic references in the
literature for each type. Let me know if that may be of help to you. I am
glad that QuakeML is pushing beyond a simple "enumerated type" to include
simple definitions, synonyms and hierarchical relationships.
I can't find a "Request for Comments" page relating to event types at
https://quake.ethz.ch/quakeml/QuakeML2.0RFC . If one exists or could be
created I would prefer to comment further there; if not, I can post my
comments to this list.
Nick Ackerley
Seismic Analyst, Canadian Hazard Information Service
Natural Resources Canada / Government of Canada
Analyste Sismique, Service canadien d’information sur les risques
Ressources naturelles Canada / Gouvernement du Canada
On Wed, Jun 14, 2017 at 8:34 AM, Fabian Euchner <fabian....@sed.ethz.ch>
wrote:
Dmitry Storchak
Just wanted to say that the ISC-NEIC-EMSC document on event types,
mentioned by John Clinton, is available here at the ISC website
<http://www.isc.ac.uk/standards/event_types/event_types.pdf>.
Regards,
Dmitry
Dr. Dmitry A. Storchak
Director
International Seismological Centre (ISC)
United Kingdom
www.isc.ac.uk
+44 (0)1635 861022
Florian Haslinger
the discussion seems to have moved from the basic question ‘what to do with event types in FDSN services’ to ‘what to do about event types’ (which was one of John’s initial ‘open questions’…).
While obviously connected, I feel that it would be appropriate to try and keep these discussions separated - or at least be conscious about what exactly we are discussing.
I believe it would be worthwhile to pick up the ‘what to do about event types’ discussion again. At the end, any service or format should then ‘just implement’ the community decided definitions.
A couple of thoughts / questions on that:
- which is the appropriate body / forum to discuss (and propose/decide) event type definition standards?
>From seismology, we have at least two bodies within the IASPEI framework - CoSOI (a IASPEI commission) and FDSN (having IASPEI commission status) which play a role here. To me at least it is not fully clear which of the two could claim ‘ownership’ of this issue.
But by now we also have other communities starting to share our services (data and / or formats), or being actively encouraged to share, like volcanology, infrasound, GNSS. They may have specific requests for event type definitions that we haven’t yet covered (as Jean-Marie nicely described for the volcanology case).
To me, seismology is naturally in the lead, but perhaps we should formally invite / involve the other communities (via IUGG structures?).
Sorry if that gets political, but the alternative in my view is that we just live with everybody implementing their own ideas in some private modification of a standard (thereby killing the standard…).
- how hierarchical should the event type definitions be?
The CoSOI standard (that’s what I call the ISC-NEIC-EMSC proposal forwarded by Dmitry, as - if I recall correctly - it was approved by CoSOI some years ago), has an implicit hierarchy for some types, but that is not comprehensive enough (and the hierarchy is not reflected in the structure of the definition).
The volcano use-case described by Jean-Marie indicates that a ‘private typology’ may be required (or at least very useful) in their domain, and that may be true for other domains. So perhaps the opportunity to specify such a private type definition should be provided.
Drawback / caveat: lazy people may just prefer to use the private types so that they don’t have to worry about following standards… Careful consideration is required where to draw the line between the private types and the standard ones.
- related to the above - how referential should the event type definitions be?
(see email discussion between Fabian and Jean-Marie)
should we allow ‘any’ vocabulary as long as it can be referred to? should ‘private’ vocabularies be required to come with a reference / resource link?
There are certainly various other ‘issues’ that also need to be addressed … Kobe would provide a good opportunity to discuss this further (at least in CoSOI and FDSN WGIII meetings…), and it would be great if we could collect input / views before the meeting (fully supporting John’s initial intention :-)
As I couldn’t find any generic CoSOI mailing list, I at least include its current Chair (Thomas Meier) in cc, not sure whether he is on the FDSN WGIII list.
Kind regards,
Florian
----------------------------
Swiss Seismological Service
ETH Zurich
Dr. Florian Haslinger
NO H65
Sonneggstr. 5
CH - 8092 Zürich
Switzerland
ph: +41-44-633 4670
www.seismo.ethz.ch<http://www.seismo.ethz.ch>
On 15 Jun 2017, at 6:37 PM, Dmitry Storchak <dmi...@isc.ac.uk<mailto:dmi...@isc.ac.uk>> wrote:
Hi,
Just wanted to say that the ISC-NEIC-EMSC document on event types, mentioned by John Clinton, is available here at the ISC website<http://www.isc.ac.uk/standards/event_types/event_types.pdf>.
Regards,
Dmitry
Dr. Dmitry A. Storchak
Director
International Seismological Centre (ISC)
United Kingdom
www.isc.ac.uk<http://www.isc.ac.uk/>
Dmitry Storchak
If CoSOI of IASPEI is needed for something, then it is for the jobs like
this. Indeed, all interested parties (volcanology, infrasound etc)
should be invited to take part in a corresponding working group.
Regards,
Dmitry
Dr. Dmitry A. Storchak
Director
International Seismological Centre (ISC)
United Kingdom
www.isc.ac.uk
+44 (0)1635 861022
>>> Update subscription preferences athttp://www.fdsn.org/account/profile/
Fabian Euchner
(this is getting slightly out-of-topic on this list, which is mainly on web services, not so
much on data models, so I'm cross-posting to the QuakeML list)
> There is a Geological Survey of Canada open file, currently under review,
> explaining that the GSC is adopting a subset of the QuakeML 1.2 event
> types. It includes the procedures we use in routine processing for
> assigning each type (we make heavy use of "suspected" - a key innovation of
> the QuakeML event type ontology, IMHO) and cites basic references in the
> literature for each type. Let me know if that may be of help to you.
Nice to hear this, and yes, I think this will be of great help for the commnuity. Would be
great if you could share the document when review is finished.
> I am
> glad that QuakeML is pushing beyond a simple "enumerated type" to include
> simple definitions, synonyms and hierarchical relationships.
Note that the XML Schema will still use a simple enumeration, but in addition we will
provide an SKOS definition in which the semantic relations can be seen.
> I can't find a "Request for Comments" page relating to event types at
> https://quake.ethz.ch/quakeml/QuakeML2.0RFC . If one exists or could be
> created I would prefer to comment further there; if not, I can post my
> comments to this list.
Discussion on the next generation of QuakeML "Basic Event Description" (which includes
EventType) is here: quakeml.org/QuakeML2.0/
BasicEventDescriptionTypesDiscussion#class_EventType . I took the liberty to propose a
simplified classification scheme as a starting point.
This is not yet an official RfC, but of course comments and suggestions can be posted and
are very welcome! (everybody who needs an account for this Wiki please let me know by e-
mail, automatic account creation is disabled because of uncontrollable spam).
In addition, suggestions and comments should be posted on the QuakeML mailing list at
qua...@sympa.ethz.ch in order to get a higher visibility.
(sign up to the mailing list at https://sympa.ethz.ch/sympa/subscribe/quakeml )
Best regards,
Fabian
>
> Nick Ackerley
>
>
>
> Seismic Analyst, Canadian Hazard Information Service
>
> Natural Resources Canada / Government of Canada
>
>
>
> Analyste Sismique, Service canadien d’information sur les risques
>
> Ressources naturelles Canada / Gouvernement du Canada
>
>
>
> On Wed, Jun 14, 2017 at 8:34 AM, Fabian Euchner <fabian....@sed.ethz.ch>
> wrote:
> > There will also be an updated BasicEventDescription package (QuakeML-BED
> > v1.3). This will include mild changes to the well-known QuakeML 1.2. In
> > particular, the event type enumeration needs to be revised. We would like
> > to introduce precise definitons with literature references, and a
> > hierarchy
> > of terms with clear semantics. Suggestions are welcome!
Tim Ahern
While the conversation continues, I think to move this forward when you are ready you should bring it to the FDSN WGIII for approval in Kobe.
Specifically I think
http://www.fdsn.org/webservices/FDSN-WS-Specifications-1.1.pdf
documentation needs to be updated to identify defaults and other things related to parameter specification.
I also think that you need to coordinate this with WG II where the FDSN Schema is vetted. I think WG II is still relevant to this or do you do it within ETH? Events are a bit different than what I usually track.
So something should be brought to WG III about parameters and something to WGII for schema as needed. Then the WGs can adopt as they see fit.
Is this possible?
Cheers
Tim Ahern
Director of Data Services
IRIS
IRIS DMC
1408 NE 45th Street #201
Seattle, WA 98105
(206)547-0393 x118
(206) 547-1093 FAX
> On Jun 9, 2017, at 9:06 AM, John Clinton <jcli...@sed.ethz.ch> wrote:
>
> Dear FDSN WG3,
>
> over the last year or so, the FDSN III mailing list has seen a number of comments / suggestions / requests for modifications to each of the FDSN web services. Despite often quite vigorous discussions, there has not yet been a clear path for how version updates are agreed and implemented.
>
> I propose we use the (short) time before now and the IASPEI meeting in Kobe in the beginning of August to agree on how we as a community agree on version updates and how they are implemented, and if possible, propose some changes that may be ratified at Kobe.
>
> An obvious modification that was basically agreed in exchanges last summer ( http://www.fdsn.org/message-center/thread/425/ <http://www.fdsn.org/message-center/thread/425/> ) was for the fdsnws event to support event type. I reiterate what I would propose for including the event type:
> - support in the query (default = earthquake)
> - add column for event type in the text output
> - open question: limit event type to the quakeMl1.2 definitions, or extend to quakeML2.0, or leave free form to be defined in the local web service documentation. This last part is tricky, as there remain complications with hierarchies on the de facto (unpublished?) Storchak et al. standard for event types
>
> We can also use a review period to
> 1. review other proposed changes posted to the mailing list related to fdsn-event that may also warrant inclusion in a new version
> 2. try to collect individual extensions to the standard and see if they should be included if relevant (eg USGS already support the event type, as well as other useful tools such as count, but also have some tools that are internal to USGS such as pager alert level - https://earthquake.usgs.gov/fdsnws/event/1/#parameters <https://earthquake.usgs.gov/fdsnws/event/1/#parameters> )
> 3. take the opportunity to tighten the existing specifications in places (e.g. where possible, directly specify which parameter in quakeMl1.2 maps for both the query and response format)
>
> comments or thoughts?
>
> regards,
>
> John
>
>
>
Jean-Marie Saurel
I hope it's not too late, but I would like to submit this comment and
ask for a slight change in the webservice specification for starttime
and endtime options, regarding dataselect only.
http://www.fdsn.org/webservices/FDSN-WS-Specifications-1.1.pdf
Currently, for dataselect, it says (page 6) that starttime selects any
data on or after the value specified.
And endtime selects any data on or prior the value specified.
So the user have at most the data requested.
I would like to suggest that, for dataselect only, the starttime selects
any data starting from a block including the starttime.
And endtime selects any data ending on a block including the endtime.
The user then have at least the data requested.
* Rationale
-----------
When you have a webservice that doesn't trim the miniseed records (which
is good), the current specification implies that you will end up with
less data than you requested.
The data will start at the first block after the starttime and end at
the last block before the endtime.
If you request several channels for, let's say, some cross-correlation
computation, you will then need to trim your data to the smallest common
data portion, which might not be enough.
If you have slightly more data than asked as suggested, the user can
trim the data to the exact starttime and endtime it has requested.
Finally, from an implementation point of vue, it's way easier to find
the miniseed blocks that include the start and end time than to find the
first miniseed block that start at or doesn't include the starttime and
the last miniseed block that ends at or doesn't include the endtime.
Regards.
Jean-Marie SAUREL.
--
--------------------------------------
Pete Evans
On 07/06/2017 09:04 AM, Jean-Marie Saurel wrote:
> I hope it's not too late, but I would like to submit this comment and
> ask for a slight change in the webservice specification for starttime
> and endtime options, regarding dataselect only.
>
> http://www.fdsn.org/webservices/FDSN-WS-Specifications-1.1.pdf
>
> Currently, for dataselect, it says (page 6) that starttime selects any
> data on or after the value specified.
> And endtime selects any data on or prior the value specified.
> So the user have at most the data requested.
>
> I would like to suggest that, for dataselect only, the starttime selects
> any data starting from a block including the starttime.
> And endtime selects any data ending on a block including the endtime.
> The user then have at least the data requested.
This is what our (SeisComp) fdsnws-dataselect implementation
in fact does. See the illustration at Note 5 on
http://geofon.gfz-potsdam.de/waveform/webservices.php
This means
(1) our server doesn't have to break up mini-SEED records,
(2) users may receive more data than they requested, but
never less, if we have it.
So GEOFON would support Jean-Marie's suggestion above, I think.
P.
--
Dr. Peter L. Evans, Sect. 2.4 Seismology
GFZ German Research Centre for Geosciences
pev...@gfz-potsdam.de Tel. +49 (0)331 288-1261
http://geofon.gfz-potsdam.de/ Fax +49 (0)331 288-1277