Re: fdsnws-event - add support for event type in query and text format
Jeremy Fee
The USGS fdsnws-event web service already supports an "eventtype" parameter
as an extension, and it is included in our extension output formats csv and
geojson:
http://earthquake.usgs.gov/fdsnws/event/1/
I recommend using the actual quakeml values ("earthquake" instead of
"Earthquake").
Thanks,
Jeremy
On Thu, Jul 21, 2016 at 11:23 AM, John Clinton <jcli...@sed.ethz.ch> wrote:
> Dear FDSN WG III,
>
> I would like to propose a change to fdsnws-event. Currently, there is very
> limited support for event type. This information is given in the quakeML
> XML output, but it is missing from the text output. Also, it would be very
> useful to be able to query catalogues by event type.
>
> I know there is a long story about what is the correct nomenclature for
> event type, but quakeML1.2 supports the following event types as seen in
>
> https://quake.ethz.ch/quakeml/docs/notes?action=AttachFile&do=view&target=quakeml-1.2-classdiag-AI.pdf
>
> I would suggest if eventype is not specified in a query, the default would
> be ‘Earthquake’ (many of us offering fdsnws-event only support
> EventType=Earthquake anyway).
>
> Is there any established procedure to manage changing versions of fdsnws?
> It hasn’t changed since 4/2013.
>
> John
>
>
>
> ----------------------
> FDSN Working Group III (
> http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)
>
> Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
> Update subscription preferences at http://www.fdsn.org/account/profile/
>
Jeremy Fee
USGS event web service?
Thanks,
Jeremy
On Thu, Jul 21, 2016 at 2:13 PM, Glenn Thompson <thom...@mail.usf.edu>
wrote:
> Slightly off topic perhaps but I am wondering why volcano-seismic event
> types are omitted? By this I mean some labels that identify events as
> volcano-tectonic, hybrid, long-period, and rockfall/pyroclastic flow. These
> are common to most volcano observatories. For example, I classified much of
> the Montserrat catalog (a 15 year eruption) and there were several tens of
> thousands of events in each of these categories, and much of the downstream
> automated and manual analysis relies on these categorizations.
Jeremy Fee
I suspect the simplest way forward is to use a generic quakeml event type,
and implement a quakeml extension that allows more flexibility.
Thanks,
Jeremy
On Thu, Jul 21, 2016 at 3:52 PM, Glenn Thompson <thom...@mail.usf.edu>
wrote:
> QuakeML, but it is a generic point too for any system or data format that
> aims to be useful for volcano-seismology. Much of my own work at different
> observatories has involved taking systems and database schema designed for
> regional earthquake monitoring and expanding them to support
> volcano-seismic monitoring needs. But maybe QuakeML isn't meant to support
> the exchange of volcano-seismic event metadata because many such events are
> small - which leads to other issues.
John Clinton
Glenn Thompson
On Jul 21, 2016, at 6:31 PM, Jeremy Fee <jm...@usgs.gov> wrote:
Hello,
The USGS fdsnws-event web service already supports an "eventtype" parameter as an extension, and it is included in our extension output formats csv and geojson:
http://earthquake.usgs.gov/fdsnws/event/1/
I recommend using the actual quakeml values ("earthquake" instead of "Earthquake").
Thanks,
Jeremy
> On Thu, Jul 21, 2016 at 11:23 AM, John Clinton <jcli...@sed.ethz.ch> wrote:
> ----------------------
> FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)
>
> Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
> Update subscription preferences at http://www.fdsn.org/account/profile/
----------------------
FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)
Marcelo Belentani de Bianchi
In the frame work of changes of the text format, one issue that has been
affecting us (@USP/Brazil) is the lack of EvaluationMode in the text format.
Also, ability to filter by eventType could potentially be more explored.
Today we just filter then out, before serving other events than
earthquakes because of the lack of such a feature.
On the other hand, what fields go into the text format could be trick
discussion and we could end-up with a quite huge list of fields in the
future. Each DC could have its own needs. Maybe, a more natural approach
in my view would be if the text-format (as an alternative format of the
event-ws service) could be configured by the client by a parameter like:
textfields="EventID,Time,Latitude,Longitude,Depth,Author,EvaluationMode".
this parameter would have its default value as it is established today,
but would be extensible to fit everyone needs. Another option would be
to name this parameter fields="" and would control all secondary formats
exported by the server.
best regards,
Marcelo Bianchi
On 21-07-2016 19:03, Jeremy Fee wrote:
> We're having similar discussions over more specific landslide event types.
>
> I suspect the simplest way forward is to use a generic quakeml event
> type, and implement a quakeml extension that allows more flexibility.
>
>
> Thanks,
>
> Jeremy
>
>
>
> On Thu, Jul 21, 2016 at 3:52 PM, Glenn Thompson <thom...@mail.usf.edu
> <mailto:thom...@mail.usf.edu>> wrote:
>
> QuakeML, but it is a generic point too for any system or data format
> that aims to be useful for volcano-seismology. Much of my own work
> at different observatories has involved taking systems and database
> schema designed for regional earthquake monitoring and expanding
> them to support volcano-seismic monitoring needs. But maybe QuakeML
> isn't meant to support the exchange of volcano-seismic event
> metadata because many such events are small - which leads to other
> issues.
>
> On Jul 21, 2016, at 9:32 PM, Jeremy Fee <jm...@usgs.gov
> <mailto:jm...@usgs.gov>> wrote:
>
> Are you asking why those are omitted from the Quakeml spec, or from
> the USGS event web service?
>
>
> Thanks,
>
> Jeremy
>
>
> On Thu, Jul 21, 2016 at 2:13 PM, Glenn Thompson
> <thom...@mail.usf.edu <mailto:thom...@mail.usf.edu>> wrote:
>
> Slightly off topic perhaps but I am wondering why
> volcano-seismic event types are omitted? By this I mean some
> labels that identify events as volcano-tectonic, hybrid,
> long-period, and rockfall/pyroclastic flow. These are common to
> most volcano observatories. For example, I classified much of
> the Montserrat catalog (a 15 year eruption) and there were
> several tens of thousands of events in each of these categories,
> and much of the downstream automated and manual analysis relies
> on these categorizations.
>
> On Jul 21, 2016, at 6:31 PM, Jeremy Fee <jm...@usgs.gov
Centro de Sismologia ~ http://www.moho.iag.usp.br
Inst. Astro. Geof. e Cien. Atms. ~ http://www.iag.usp.br/geofisica
Universidade de São Paulo ~ http://www.usp.br/
Glenn Thompson
On Jul 21, 2016, at 9:32 PM, Jeremy Fee <jm...@usgs.gov> wrote:
Are you asking why those are omitted from the Quakeml spec, or from the USGS event web service?
Thanks,
Jeremy
> On Thu, Jul 21, 2016 at 2:13 PM, Glenn Thompson <thom...@mail.usf.edu> wrote:
> Slightly off topic perhaps but I am wondering why volcano-seismic event types are omitted? By this I mean some labels that identify events as volcano-tectonic, hybrid, long-period, and rockfall/pyroclastic flow. These are common to most volcano observatories. For example, I classified much of the Montserrat catalog (a 15 year eruption) and there were several tens of thousands of events in each of these categories, and much of the downstream automated and manual analysis relies on these categorizations.
>
> On Jul 21, 2016, at 6:31 PM, Jeremy Fee <jm...@usgs.gov> wrote:
>
> Hello,
>
> The USGS fdsnws-event web service already supports an "eventtype" parameter as an extension, and it is included in our extension output formats csv and geojson:
> http://earthquake.usgs.gov/fdsnws/event/1/
>
> I recommend using the actual quakeml values ("earthquake" instead of "Earthquake").
>
>
> Thanks,
>
> Jeremy
>
>
> On Thu, Jul 21, 2016 at 11:23 AM, John Clinton <jcli...@sed.ethz.ch> wrote:
>> Dear FDSN WG III,
>>
>> I would like to propose a change to fdsnws-event. Currently, there is very limited support for event type. This information is given in the quakeML XML output, but it is missing from the text output. Also, it would be very useful to be able to query catalogues by event type.
>>
>> I know there is a long story about what is the correct nomenclature for event type, but quakeML1.2 supports the following event types as seen in
>> https://quake.ethz.ch/quakeml/docs/notes?action=AttachFile&do=view&target=quakeml-1.2-classdiag-AI.pdf
>>
>> I would suggest if eventype is not specified in a query, the default would be ‘Earthquake’ (many of us offering fdsnws-event only support EventType=Earthquake anyway).
>>
>> Is there any established procedure to manage changing versions of fdsnws? It hasn’t changed since 4/2013.
>>
>> John
>>
>>
>>
Florian Haslinger
Dear all,
there seem to be two discussions required:
a) event-types overall (and in QuakeML)
b) utlizing of event-types in the fdsn-webservices
While connected, they are in my view distinct / independent…
A few comments on both, anyway:
a)
I would agree that the addition of more specific ‘volcanic events’ (beyond the currently included ‘volcanic eruption’) would make sense - in particular in comparison with the granularity that is available for some other types. (Of course the definitions have a history that reflects the ‘user group’ that came up with them…), and also looking forward to the attempts to enhance interoperability of services…
QuakeML event types seem to map largely to the IASPEI/CoSOI proposal (from 2012/2013, discussed at the Gothenburg assembly, and (as far as I recall) approved there or shortly after). In that proposal the event type has a hierarchy - i.e. an ‘explosion’ would be _any_ of the various specific explosion types. Is this also clear in QuakeML?
It would be good if the ‘event type’ definitions would not only exist as part of a data model, but also as a well defined vocabulary (with some explanation what exactly is meant, e.g. making the difference between a landslide and a rockslide (and specifying that a rockfall should be classified as rockslide?) (Maybe they are and I just don’t know it…)
In order to not become infinite, perhaps introducing an ‘other_specific’ type which can then have a ‘free’ text entry (character-limited to something reasonable…) could work (would probably require that QuakeML EventType gets a hierarchy…) - and once some type establishes itself as a ’standard’, then introduce it to the standard type set?
the ‘evaluation_mode’ would be useful for event type (agree with Marcelo) - in particular as we see more and more ‘automatic classficiation’ attempts… (I guess initially the thinking was that anything that has an event type specified would be assumed to be ‘manual’ )
b)
Seems that query-able event types would indeed be a good thing… (and returning the type :-)
- Should then the queries also respect hierarchies (return all types of induced events, when queried for ‘anthropogenic event’ / return all types of explosions, when queried for ‘explosion’)? Or would the user have to know & accept that if she wants all explosions, she’d have to query for ‘explosion’ AND all specific explosion types?
- query default (no event type specified): return everything (only if there is an ‘any’ parameter allowed, in the query I would agree to return ‘only earthquake’ by default, if nothing specified)
- query exclude should be implemented (return anything that _is-not_ a given type)
- should simultaneous querying for multiple types be possible? (is that useful?)
Kind regards,
Florian
> ----------------------
> FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)
Dmitry Storchak
developed in 2012 jointly by the ISC, NEIC and EMSC and discussed at the
appropriate IASPEI commission - CoSOI. It is attached. I believe it was
passed on to the QuakeML proprietors for inclusion in the next (at the
time) version. It is used by the NEIC as far as I know.
Regards,
Dmitry
Dr. Dmitry A. Storchak
Director
International Seismological Centre (ISC)
United Kingdom
www.isc.ac.uk
+44 (0)1635 861022
On 22/07/2016 10:31, Joachim Saul wrote:
> Jeremy Fee wrote on 07/22/2016 12:03 AM:
>> I suspect the simplest way forward is to use a generic quakeml event
>> type, and implement a quakeml extension that allows more flexibility.
> The extension would then be part of the XML document but unaware QuakeML
> parsers would yield the generic event type. A better way would be to
> raise the issue on the QuakeML mailing list and propose inclusion of
> those additional event types into QuakeML.
>
> The current list of event types is the result of discussions between
> several European and American institutions heavily involving the USGS.
> It would be good if the USGS could continue to contribute to the
> development of core QuakeML rather than filling gaps by using
> proprietary extensions.
>
> That said, I would be glad to see the USGS eventtype extension to
> fdsnws-event added to the standard.
>
> Regards
> Joachim
>
> ----------------------
> FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)
Florian Haslinger
[ I had tried to send below text earlier today - but apparently it didn’t go through (non-registered sender address used, realized that after Joachim’s & Dmitry's messages came in…). It is somewhat redundant to points raised by Joachim & Dmitry (and Dmitry already now sent the document that I had also wanted to attach, so it’s omitted) …]
there seem to be two discussions required:
a) event-types overall (and in QuakeML)
b) utlizing of event-types in the fdsn-webservices
While connected, they are in my view distinct / independent…
A few comments on both, anyway:
a)
I would agree that the addition of more specific ‘volcanic events’ (beyond the currently included ‘volcanic eruption’) would make sense - in particular in comparison with the granularity that is available for some other types. (Of course the definitions have a history that reflects the ‘user group’ that came up with them…), and also looking forward to the attempts to enhance interoperability of services…
QuakeML event types seem to map largely to the IASPEI/CoSOI proposal (from 2012/2013, discussed at the Gothenburg assembly, and (as far as I recall) approved there or shortly after). In that proposal the event type has a hierarchy - i.e. an ‘explosion’ would be _any_ of the various specific explosion types. Is this also clear in QuakeML?
It would be good if the ‘event type’ definitions would not only exist as part of a data model, but also as a well defined vocabulary (with some explanation what exactly is meant, e.g. making the difference between a landslide and a rockslide (and specifying that a rockfall should be classified as rockslide?) (Maybe they are and I just don’t know it…)
In order to not become infinite, perhaps introducing an ‘other_specific’ type which can then have a ‘free’ text entry (character-limited to something reasonable…) could work (would probably require that QuakeML EventType gets a hierarchy…) - and once some type establishes itself as a ’standard’, then introduce it to the standard type set?
the ‘evaluation_mode’ would be useful for event type (agree with Marcelo) - in particular as we see more and more ‘automatic classficiation’ attempts… (I guess initially the thinking was that anything that has an event type specified would be assumed to be ‘manual’ )
b)
Seems that query-able event types would indeed be a good thing…
- Should then the queries also respect hierarchies (return all types of induced events, when queried for ‘anthropogenic event’ / return all types of explosions, when queried for ‘explosion’)? Or would the user have to know & accept that if she wants all explosions, she’d have to query for ‘explosion’ AND all specific explosion types?
- query default (no event type specified): return everything (only if there is an ‘any’ parameter allowed, in the query I would agree to return ‘only earthquake’ by default, if nothing specified)
- query exclude should be implemented (return anything that _is-not_ a given type)
- should simultaneous querying for multiple types be possible? (is that useful?)
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
> <event_types.pdf>
Joachim Saul
> type, and implement a quakeml extension that allows more flexibility.
The extension would then be part of the XML document but unaware QuakeML
Tim Ahern
I think a couple of issues have come up but I think John intended this comment to be related to the FDSN event service invocation more than the QuakeML issue that is also being discussed.
Working Group III is responsible for the specification of the service. Valid eventtype values should be part of the QuakeM specification.
So given the discussion of this request from John please let me know if there are any objections to having the FDSN Event service modified to require support for another parameter called
eventtype.
By default if eventtype is not specified in the users request then it should return all event types. Output formats would have to be modified to support the display of the event type. Following the USGS current implementation seems to make good sense.
Please respond if you are in favor of this modification by Friday August 12, and please respond to the FDSN WGIII list.
Dr. Tim Ahern
t...@iris.washington.edu
Chair of FDSN WG III on
Products, Tools and Services
Fabian Euchner
> QuakeML event types seem to map largely to the IASPEI/CoSOI proposal (from
> 2012/2013, discussed at the Gothenburg assembly, and (as far as I recall)
> approved there or shortly after).
This proposal was adopted in QuakeML 1.2 without changes.
> In that proposal the event type has a
> hierarchy - i.e. an ‘explosion’ would be _any_ of the various specific
> explosion types.
I would rather say: any of the various specific explosion types is an
explosion (not the other way round)
> Is this also clear in QuakeML?
In XML Schema, enumerations are flat, thus the hierarchy is not visible.
Unfortunately, the fact that a hierarchy exists was not pointed out clearly in
the standard document of QuakeML. There is a reference to the proposal, which
was not publicly available at that time.
For the next version of QuakeML, we plan to provide SKOS ontology descriptions
for all enumerations (for an early example, see the attached file, concept
scheme http://quakeml.org/vocab/bedt/1.3/EventType). This is a machine-
readable representation of the hierarchy which can be expanded with additional
information, e.g., longer descriptions, links to equivalent concepts in other
vocabularies, etc.
>
> It would be good if the ‘event type’ definitions would not only exist as
> part of a data model, but also as a well defined vocabulary
(see paragraph above)
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
-----------------------------------------------------------------------------