Thread: Re: fdsnws-event - add support for event type in query and text format

On 22 Jul 2016, at 3:09 AM, Marcelo Belentani de Bianchi <m.bianchi<at>iag.usp.br> wrote:

Dear List,

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 <thompsong<at>mail.usf.edu
<thompsong<at>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 <jmfee<at>usgs.gov
<jmfee<at>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
<thompsong<at>mail.usf.edu <thompsong<at>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 <jmfee<at>usgs.gov
<jmfee<at>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
<jclinton<at>sed.ethz.ch <jclinton<at>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

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

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

Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
Update subscription preferences at http://www.fdsn.org/account/profile/