[webservices] event web service

[Philip Crotwell]

Hi

Grouping origins into events is indeed a hard problem. But I wonder if
the criteria you use might be too restrictive.  Were these numbers
based on some analysis of existing data, or just guesses as to maximum
errors?

When I set up the removeDuplicates origin subsetter in SOD, I too
thought that the USGS wouldn't be more than 1/2 a degree or 30 seconds
off for a moderately large earthquake, but that turned out to not be
true. Take the QED and FINGER results for the recent Turkey
earthquake:

43.4900 38.6730 29.2 2011_296_10_41_24 7.3MS QED NEIC
43.4800 38.6200 20 2011_296_10_42_21 7.2M FINGER NEIC

They are almost a minute apart and this is a 7. Obviously QED and
FINGER are going to be the most inaccurate locations as they happen
quickly, but the grouping the early inaccurate locations
with the later more accurate ones is very useful.

A second example from the other end of the time scale are these
locations for almost a mag8 in the ISC catalog where there are origins
with up to 50 seconds offset and location differences of over a
degree. I know the ISC catalog can have some oddball locations, but it
would be nice if the criteria could handle them.

154.0500 46.7000 30 2006_11_15_11_14_09_600 7.9UNKNOWN JMA ISCCD ISC
East Of Kuril Islands
153.2700 46.6900 9 2006_11_15_11_14_11_900 7.2MB BJI ISCCD ISC Kuril Islands
153.2617 46.5504 10 2006_11_15_11_14_12_270 7.84MS ISCJB ISCCD ISC Kuril Islands
153.4330 46.4600 10 2006_11_15_11_14_12_700 7.7MS BGS ISCCD ISC Kuril Islands
153.2660 46.5920 10 2006_11_15_11_14_13_570 7.8ME NEIC ISCCD ISC Kuril Islands
155.0000 46.5000 33 2006_11_15_11_14_13_600 7.4MB SZGRF ISCCD ISC East
Of Kuril Islands
153.2920 46.5710 26 2006_11_15_11_14_14_500 8.0MS MOS ISCCD ISC Kuril Islands
153.2106 46.6810 12.2 2006_11_15_11_14_14_540 7.84MS ISC ISCCD ISC Kuril Islands
153.3100 46.6400 41 2006_11_15_11_14_15_700 7.5MB SKHL ISCCD ISC Kuril Islands
154.3300 46.7100 13.5 2006_11_15_11_14_17_800 8.3MW GCMT ISCCD ISC
East Of Kuril Islands
153.6000 46.6000 8 2006_11_15_11_15_00_000 7.8MW NIED ISCCD ISC Kuril Islands

Doesn't the ISC catalog contain event grouping information that they
do? Do you use that in the algorithm?

Running a db query to see what the minimum time and distance
separation between two distinct events in a single catalog is would be
interesting. If that turns out to be significantly larger than the
criteria, then that might argue for increasing them.

On the other hand, it is probably best to err on the side of making
one earthquake appear as two rather than accidentally lumping two
distinct earthquakes into one event.

But it is a hard problem, so take my $0.02 at no more than its value.

thanks,
Philip


On Mon, Nov 7, 2011 at 12:16 AM, Chad Trabant <chad at iris.washington.edu> wrote:
>
> Hi John,
>
> The intention is that the publicID will remain the same, in particular the integer event ID value will remain the same.
>
> That being said the process of receiving updates is not as clear cut as one would hope.  For each event there are one or more origin and associated magnitude estimates.  In order to associate or group origins together by event  we currently employ a simple space-time envelope of 30 seconds and 0.5 degrees.  When a new origin arrives at the DMC our system searches the current primary origins for a match to this criteria and if a match is found the origin is associated with the other origin(s) for that event, otherwise a new event is created.  If more than one origin is submitted for the same event, the original association/grouping is retained.  Also, a simple algorithm based on catalog name is applied to determine which origin is the "primary" for the given event.  This process is completely automated.  It's not perfect but it does properly group most moderate to large earthquakes, when it does miss it usually means that we'll have more than one event ID for what was actuall!
>  y the same event.
>
> Chad
>
> On Nov 6, 2011, at 4:18 PM, John D. West wrote:
>
>> Hi.
>>
>> If an event is updated (refined location info, recalculated magnitude, etc.) does the event publicID remain the same?
>>
>> Thanks!
>>      -- John
>> _______________________________________________
>> 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
>