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

Started: 2013-03-13 18:18:47
Last activity: 2013-03-18 20:24:12
Topics: Web Services
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


  • 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


    • 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


      • "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



Page built 01:35:51 | v.8ffa3d95