Thread: event query by catalog, no results for PDE for old time ranges

"Under no circumstances should information about an event from one catalog
be mixed with that from another catalog (e.g., magnitude or depth from GCMT
mixed with location or origin time from another catalog). "

Unfortunately, this is how quakeml works now. Magnitudes and Origins are
both top level entities in an Event. Magnitudes do know the origin they
"came from" but Origins have no notion of magnitudes and there is no
requirement that the "primary" magnitude be connected to the "primary"
origin. And in fact the current rules of priority at the DMC will give the
GCMT as the primary magnitude, but the ISC origin as primary origin. The
GCMT is lowest priority for origin. So, the only way you would have an
origin and magnitude from the same catalog as "primary" would be if the
CGMT had an origin that nobody else did! (obviously assuming the GCMT
exists, smaller events might have them the same.)

I am not sure myself what the right way to do things is. There are likely
good seismological reasons for using GCMT as the "more gooder" magnitude
estimate, and reasons for not using its location (GCMT is a "centriod"
location) but it also feels weird to me to have the origin and magnitude
returned not have any connection. In the old DHI system, magnitudes were
contained in the origin from which they were generated, which had the
advantage that the magnitude origin connection was very strong. The
disadvantage is that the magnitude-origin connection was very strong.

I guess I am starting to come around to the new way of doing things, and so
I think I would argue that disconnecting magnitude from origin as the
current event web service does it is the right way to go, but it does still
feel a bit odd and leads to this mixing that you want to avoid.

One possible work around would be to include the origin that the primary
magnitude came from if it is different from the primary origin. But then
you get some confusing as to why there are two origins when I only asked
for the primary.

The devil is very much in the details here.

Philip



On Mon, Mar 18, 2013 at 12:38 PM, David Simpson <simpson<at>iris.edu> wrote:

Web Service aficionados

The question of how IRIS deals with catalogs and especially the issue of
authoritative sources and preferred hypocenters has been of concern for
some time.

The USGS is in the process of developing a comprehensive catalog (COMCAT)
( http://earthquake.usgs.gov/earthquakes/eqarchives/epic/ ) that will
eventually provide the dynamic updates (and rules of engagement) that some
of you have indicated would be useful. This group should track that
development and provide input to NEIC on how this develops and how it is
linked to any parallel developments within the FDSN.
In the meantime, I do not think that IRIS should be the business of
defining "preferred solutions" from multiple catalogs.

I would prefer that for use in selecting events for waveform collection
(the primary IRIS DMC application) we should limit ourselves to a carefully
defined set of no more than three catalogs (NEIC, ISC and GCMT) with a
careful and well-understood definition of how they are used. When using
the ISC catalog, only the ISC processed and preferred solution should be
used (these are clearly indicated in the ISC catalog). Under no
circumstances should information about an event from one catalog be mixed
with that from another catalog (e.g., magnitude or depth from GCMT mixed
with location or origin time from another catalog).
This should avoid some of the confusion that is demonstrated under this
current thread of discussion.

It is fine for IRIS to archive and provide access to multiple catalogs,
but complex algorithms for selecting, mixing and defining preferred
solutions should be left to the user or done by others (i.e. ISC or NEIC).

David Simpson

On Mar 14, 2013, at 2:20 PM, Chad Trabant <chad<at>iris.washington.edu>
wrote:


Hi,

This is also a bug and will be addressed in our soon-to-be released FDSN
event service. It was not as simple as searching the cached primary
origins only, but a little deeper.

Thanks for reporting.

Chad


On Mar 13, 2013, at 8:18 AM, Philip Crotwell <crotwell<at>seis.sc.edu> wrote:


Hi

This query (generated by the url builder) returns no events, even though
there was a mag 7.6 earthquake in Turkey in that time range. Even odder,
there is an origin in the NEIC PDE-M catalog for this event,
originId=4908041, but it is not returned.


http://www.iris.edu/ws/event/query?starttime=1999-08-17T00:00:00&endtime=1999-08-17T23:59:00&minmag=7&contributor=NEIC+PDE-M&orderby=time&output=xml

I am assuming that what happens is that I did not select
"includeallorigins", and so this query only looked at "primary" origins.
But it seems to me that if I say "use NEIC PDE-M", then the query should
use that contributor even if it is no longer considered "primary".

I suppose "includeallorigins" is a workaround, but it seems counter
intuitive to not be able to retrieve from a specific catalog/contributor.

thanks,
Philip


_______________________________________________
webservices mailing list
webservices<at>iris.washington.edu
http://www.iris.washington.edu/mailman/listinfo/webservices


_______________________________________________
webservices mailing list
webservices<at>iris.washington.edu
http://www.iris.washington.edu/mailman/listinfo/webservices



_______________________________________________
webservices mailing list
webservices<at>iris.washington.edu
http://www.iris.washington.edu/mailman/listinfo/webservices