Thread: event web service

Started: 2011-11-07 18:18:52
Last activity: 2011-11-07 18:43:58
Topics: Web Services
John West
2011-11-07 18:18:52
Hi.

If an event is updated (refined location info, recalculated magnitude,
etc.) does the event publicID remain the same?

Thanks!
-- John

  • Chad Trabant
    2011-11-07 05:16:57

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



    • Philip Crotwell
      2011-11-07 16:19:52
      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



      • Chad Trabant
        2011-11-07 18:43:58

        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



14:10:48 v.01697673