[webservices] event query by catalog, no results for PDE for old time ranges

[Philip Crotwell]

"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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iris.washington.edu/pipermail/webservices/attachments/20130318/7150528a/attachment-0001.htm>