[webservices] event web service

Mon Nov 7 10:43:58 PST 2011

On Nov 7, 2011, at 5:19 AM, Philip Crotwell wrote:

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

We retain any grouping in the original submission, so the grouping that comes in the ISC catalog remains.  We compare their primary origin to our primary origin and lump all the origins together when they "match".

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

We thought so as well, and the result in the current criteria.  Keep in mind that the number of significantly large earthquakes that would not be grouped by the criteria do not happen very often, we can manually intervene to fix these when they happen such as happened with the NEIC alter and GCMT for the Turkey quake.

Chad

> 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
>> 
> 
> _______________________________________________
> webservices mailing list
> webservices at iris.washington.edu
> http://www.iris.washington.edu/mailman/listinfo/webservices