Thread: ws-station and obviously wrong sensitivity

Started: 2011-05-11 19:21:18
Last activity: 2011-05-17 21:01:18
Topics: Web Services
Philip Crotwell
2011-05-11 19:21:18
Hi

One of our stations has an "unknown" sensor. I know that sounds weird,
but it is old, 50 meters down a borehole backfilled with concrete and
no records left from the installation. So, in order to get the data to
the archive, we had to submit dataless where the response was filled
in, but in a way that says "we don't know". Mary said that the correct
way to do this was a unity gain blockette53 with no poles or zeros. If
you have the full response, this is a pretty noticeable oddball. But
in the channel level of the station web service, you get just the
overall sensitivity. It is probably still relative clear that this is
bogus, but not quite as clear as it is the 1 from the sensor combined
with the actual gain from the digitizer, so you get something like
629129.0 for the sensitivity. As this appears to be somewhat of a
standard, it might be better if the station web service could tell the
difference between this type of "syntactically correct, but obviously
wrong" response and just not publish a value for those stations to
avoid sending out wrong values.

If you are interested, the stations with this issue from our network
are CO.CSB and CO.RGR.

thanks,
Philip

  • Chad Trabant
    2011-05-11 20:25:33

    Hi Philip,

    The "obviously wrong" is the sticky part that's usually impossible to quantify and generalize. As I'm sure you known, the root of this particular problem is that SEED does not have any way to mark values as "unknown" or null, for required fields this means filling in something bogus. ws-station is not the appropriate place to be making judgements of the validity of response information, in general ws-station returns what's in the database. In your response information for CSB the sensitivity for the sensor is set to 1, we wouldn't be comfortable filtering out responses based solely on that, some of them might be correct!

    In the future, if we SEED standard adopts some way to represent unknown values or similar I can see us filtering stuff, we need good documented rules though. For now problems like these are much better addressed upstream in my opinion.

    Chad

    On May 11, 2011, at 9:21 AM, Philip Crotwell wrote:

    Hi

    One of our stations has an "unknown" sensor. I know that sounds weird,
    but it is old, 50 meters down a borehole backfilled with concrete and
    no records left from the installation. So, in order to get the data to
    the archive, we had to submit dataless where the response was filled
    in, but in a way that says "we don't know". Mary said that the correct
    way to do this was a unity gain blockette53 with no poles or zeros. If
    you have the full response, this is a pretty noticeable oddball. But
    in the channel level of the station web service, you get just the
    overall sensitivity. It is probably still relative clear that this is
    bogus, but not quite as clear as it is the 1 from the sensor combined
    with the actual gain from the digitizer, so you get something like
    629129.0 for the sensitivity. As this appears to be somewhat of a
    standard, it might be better if the station web service could tell the
    difference between this type of "syntactically correct, but obviously
    wrong" response and just not publish a value for those stations to
    avoid sending out wrong values.

    If you are interested, the stations with this issue from our network
    are CO.CSB and CO.RGR.

    thanks,
    Philip
    _______________________________________________
    webservices mailing list
    webservices<at>iris.washington.edu
    http://www.iris.washington.edu/mailman/listinfo/webservices



    • Doug Neuhauser
      2011-05-11 21:51:36
      I believe the way we handle this for "unknown" sensors or
      calibration info is to represent the full SEED output
      with an overall sensitivity of 1. This way it is obvious to
      users that we cannot provide a known velocity sensitivity.
      However, the user loses the knowledge that this may be a
      velocity sensor.

      - Doug N

      On 05/11/11 13:25, Chad Trabant wrote:

      Hi Philip,

      The "obviously wrong" is the sticky part that's usually impossible to quantify and generalize. As I'm sure you known, the root of this particular problem is that SEED does not have any way to mark values as "unknown" or null, for required fields this means filling in something bogus. ws-station is not the appropriate place to be making judgements of the validity of response information, in general ws-station returns what's in the database. In your response information for CSB the sensitivity for the sensor is set to 1, we wouldn't be comfortable filtering out responses based solely on that, some of them might be correct!

      In the future, if we SEED standard adopts some way to represent unknown values or similar I can see us filtering stuff, we need good documented rules though. For now problems like these are much better addressed upstream in my opinion.

      Chad

      On May 11, 2011, at 9:21 AM, Philip Crotwell wrote:

      Hi

      One of our stations has an "unknown" sensor. I know that sounds weird,
      but it is old, 50 meters down a borehole backfilled with concrete and
      no records left from the installation. So, in order to get the data to
      the archive, we had to submit dataless where the response was filled
      in, but in a way that says "we don't know". Mary said that the correct
      way to do this was a unity gain blockette53 with no poles or zeros. If
      you have the full response, this is a pretty noticeable oddball. But
      in the channel level of the station web service, you get just the
      overall sensitivity. It is probably still relative clear that this is
      bogus, but not quite as clear as it is the 1 from the sensor combined
      with the actual gain from the digitizer, so you get something like
      629129.0 for the sensitivity. As this appears to be somewhat of a
      standard, it might be better if the station web service could tell the
      difference between this type of "syntactically correct, but obviously
      wrong" response and just not publish a value for those stations to
      avoid sending out wrong values.

      If you are interested, the stations with this issue from our network
      are CO.CSB and CO.RGR.

      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

      --
      ------------------------------------------------------------------------
      Doug Neuhauser University of California, Berkeley
      doug<at>seismo.berkeley.edu Berkeley Seismological Laboratory
      Office: 510-642-0931 215 McCone Hall # 4760
      Fax: 510-643-5811 Berkeley, CA 94720-4760
      Remote: 530-752-5615 (Wed,Fri)

    • Philip Crotwell
      2011-05-12 15:57:58
      Humm, ok. Well I would love to have it taken care of "upstream" but of
      course the only thing "upstream" of the dmc for these stations is me!
      :)

      SEED is the real problem, as you say. I guess getting that changed
      would require a filibuster-proof majority, and we all know how
      politics are these days. I understand your reluctance to put a "rotten
      seed" checker into ws-station. It does feel wrong to do that, but I
      don't see a good alternative.

      The only other thought I have is that the only place less appropriate
      to judge the validity of the response is in the clients of ws-station.
      But given that nothing can be done about the inputs and nothing can be
      done in the server, the only place left is the client, but the client
      doesn't have enough information to make that decision.

      I guess we just live with the garbage?

      thanks,
      Philip


      On Wed, May 11, 2011 at 4:25 PM, Chad Trabant <chad<at>iris.washington.edu> wrote:

      Hi Philip,

      The "obviously wrong" is the sticky part that's usually impossible to quantify and generalize.  As I'm sure you known, the root of this particular problem is that SEED does not have any way to mark values as "unknown" or null, for required fields this means filling in something bogus.  ws-station is not the appropriate place to be making judgements of the validity of response information, in general ws-station returns what's in the database.  In your response information for CSB the sensitivity for the sensor is set to 1, we wouldn't be comfortable filtering out responses based solely on that, some of them might be correct!

      In the future, if we SEED standard adopts some way to represent unknown values or similar I can see us filtering stuff, we need good documented rules though.  For now problems like these are much better addressed upstream in my opinion.

      Chad

      On May 11, 2011, at 9:21 AM, Philip Crotwell wrote:

      Hi

      One of our stations has an "unknown" sensor. I know that sounds weird,
      but it is old, 50 meters down a borehole backfilled with concrete and
      no records left from the installation. So, in order to get the data to
      the archive, we had to submit dataless where the response was filled
      in, but in a way that says "we don't know". Mary said that the correct
      way to do this was a unity gain blockette53 with no poles or zeros. If
      you have the full response, this is a pretty noticeable oddball. But
      in the channel level of the station web service, you get just the
      overall sensitivity. It is probably still relative clear that this is
      bogus, but not quite as clear as it is the 1 from the sensor combined
      with the actual gain from the digitizer, so you get something like
      629129.0 for the sensitivity. As this appears to be somewhat of a
      standard, it might be better if the station web service could tell the
      difference between this type of "syntactically correct, but obviously
      wrong" response and just not publish a value for those stations to
      avoid sending out wrong values.

      If you are interested, the stations with this issue from our network
      are CO.CSB and CO.RGR.

      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



      • Meredith Nettles
        2011-05-17 19:44:28
        Hi,

        This is not only a problem for sensors installed a long time ago and
        stuck under a lot of concrete. It is also a problem for systems where
        the response from a previous epoch is now known to be wrong, and cannot
        properly be reconstructed; and for current epochs with realtime data
        where the response is known to be wrong but the right response info
        can't be obtained before a field visit is made, etc.

        For one of these latter cases, we have previously used Blockette 51
        (Station Comment) to indicate an unknown response, following advice from
        Rick Benson. This is not ideal, since many people never read the info
        in Blockette 51, but at least it does get the information into the SEED
        volume.

        I think it is actually highly desirable to figure out a way to indicate
        "unknown response" or "unreliable response" in SEED.

        (Why does the channel level of the station web service only return the
        overall sensitivity, and not the full response? I guess that is a
        separate issue.)

        Meredith


        From: crotwell<at>seis.sc.edu
        Subject: Re: [webservices] ws-station and obviously wrong
        sensitivity
        Date: May 12, 2011 8:57:58 AM EDT
        To: webservices<at>iris.washington.edu
        Reply-To: webservices<at>iris.washington.edu

        Humm, ok. Well I would love to have it taken care of "upstream" but of
        course the only thing "upstream" of the dmc for these stations is me!
        :)

        SEED is the real problem, as you say. I guess getting that changed
        would require a filibuster-proof majority, and we all know how
        politics are these days. I understand your reluctance to put a "rotten
        seed" checker into ws-station. It does feel wrong to do that, but I
        don't see a good alternative.

        The only other thought I have is that the only place less appropriate
        to judge the validity of the response is in the clients of ws-station.
        But given that nothing can be done about the inputs and nothing can be
        done in the server, the only place left is the client, but the client
        doesn't have enough information to make that decision.

        I guess we just live with the garbage?

        thanks,
        Philip


        On Wed, May 11, 2011 at 4:25 PM, Chad Trabant
        <chad<at>iris.washington.edu> wrote:


        Hi Philip,

        The "obviously wrong" is the sticky part that's usually impossible
        to quantify and generalize. As I'm sure you known, the root of
        this particular problem is that SEED does not have any way to mark
        values as "unknown" or null, for required fields this means
        filling in something bogus. ws-station is not the appropriate
        place to be making judgements of the validity of response
        information, in general ws-station returns what's in the
        database. In your response information for CSB the sensitivity
        for the sensor is set to 1, we wouldn't be comfortable filtering
        out responses based solely on that, some of them might be correct!

        In the future, if we SEED standard adopts some way to represent
        unknown values or similar I can see us filtering stuff, we need
        good documented rules though. For now problems like these are
        much better addressed upstream in my opinion.

        Chad

        On May 11, 2011, at 9:21 AM, Philip Crotwell wrote:


        Hi

        One of our stations has an "unknown" sensor. I know that sounds
        weird,
        but it is old, 50 meters down a borehole backfilled with concrete
        and
        no records left from the installation. So, in order to get the
        data to
        the archive, we had to submit dataless where the response was filled
        in, but in a way that says "we don't know". Mary said that the
        correct
        way to do this was a unity gain blockette53 with no poles or
        zeros. If
        you have the full response, this is a pretty noticeable oddball. But
        in the channel level of the station web service, you get just the
        overall sensitivity. It is probably still relative clear that
        this is
        bogus, but not quite as clear as it is the 1 from the sensor
        combined
        with the actual gain from the digitizer, so you get something like
        629129.0 for the sensitivity. As this appears to be somewhat of a
        standard, it might be better if the station web service could
        tell the
        difference between this type of "syntactically correct, but
        obviously
        wrong" response and just not publish a value for those stations to
        avoid sending out wrong values.

        If you are interested, the stations with this issue from our network
        are CO.CSB and CO.RGR.

        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



        • Rob Casey
          2011-05-17 17:46:58

          Thanks for your input, Meredith. To answer your simple question at
          the end, we distinguish 'channel' level from 'response' level in the
          station output, for reasons of sheer volume of information. Many
          people are fine with computing sensor units from the overall
          sensitivity, so providing this along with the channel identifier means
          that you have a lightweight means of getting to ground motion values.

          -Rob


          (Why does the channel level of the station web service only return the
          overall sensitivity, and not the full response? I guess that is a
          separate issue.)

          Meredith


          • Rob Casey
            2011-05-17 17:47:53


            Thanks for your input, Meredith. To answer your simple question at
            the end, we distinguish 'channel' level from 'response' level in the
            station output, for reasons of sheer volume of information. Many
            people are fine with computing sensor units from the overall
            sensitivity, so providing this along with the channel identifier means
            that you have a lightweight means of getting to ground motion values.

            -Rob


            (Why does the channel level of the station web service only return the
            overall sensitivity, and not the full response? I guess that is a
            separate issue.)

            Meredith



        • Philip Crotwell
          2011-05-17 21:01:18
          We did the comment thing as well, but that only helps if people get
          the data as full seed and read the comment. And, although SEED is
          mandated as the "input" data format to the dmc for metadata, the
          output formats are many and varied and in many cases there is no place
          to put such a comment to go even when it exists. My concern was
          exactly this in that the ws-station gives a "sensitivity" number, but
          any other information that might allow the client to infer that this
          number is meaningless has no place to sit.

          Lots of garbage out there...
          Philip



          On Tue, May 17, 2011 at 12:44 PM, Meredith Nettles
          <nettles<at>ldeo.columbia.edu> wrote:
          Hi,

          This is not only a problem for sensors installed a long time ago and
          stuck under a lot of concrete. It is also a problem for systems where
          the response from a previous epoch is now known to be wrong, and cannot
          properly be reconstructed; and for current epochs with realtime data
          where the response is known to be wrong but the right response info
          can't be obtained before a field visit is made, etc.

          For one of these latter cases, we have previously used Blockette 51
          (Station Comment) to indicate an unknown response, following advice from
          Rick Benson. This is not ideal, since many people never read the info
          in Blockette 51, but at least it does get the information into the SEED
          volume.

          I think it is actually highly desirable to figure out a way to indicate
          "unknown response" or "unreliable response" in SEED.

          (Why does the channel level of the station web service only return the
          overall sensitivity, and not the full response? I guess that is a
          separate issue.)

          Meredith


                 From:     crotwell<at>seis.sc.edu
                 Subject:        Re: [webservices] ws-station and obviously wrong
          sensitivity
                 Date:   May 12, 2011 8:57:58 AM EDT
                 To:       webservices<at>iris.washington.edu
                 Reply-To:         webservices<at>iris.washington.edu

          Humm, ok. Well I would love to have it taken care of "upstream" but of
          course the only thing "upstream" of the dmc for these stations is me!
          :)

          SEED is the real problem, as you say. I guess getting that changed
          would require a filibuster-proof majority, and we all know how
          politics are these days. I understand your reluctance to put a "rotten
          seed" checker into ws-station. It does feel wrong to do that, but I
          don't see a good alternative.

          The only other thought I have is that the only place less appropriate
          to judge the validity of the response is in the clients of ws-station.
          But given that nothing can be done about the inputs and nothing can be
          done in the server, the only place left is the client, but the client
          doesn't have enough information to make that decision.

          I guess we just live with the garbage?

          thanks,
          Philip


          On Wed, May 11, 2011 at 4:25 PM, Chad Trabant <chad<at>iris.washington.edu>
          wrote:


          Hi Philip,

          The "obviously wrong" is the sticky part that's usually impossible to
          quantify and generalize.  As I'm sure you known, the root of this particular
          problem is that SEED does not have any way to mark values as "unknown" or
          null, for required fields this means filling in something bogus.  ws-station
          is not the appropriate place to be making judgements of the validity of
          response information, in general ws-station returns what's in the database.
           In your response information for CSB the sensitivity for the sensor is set
          to 1, we wouldn't be comfortable filtering out responses based solely on
          that, some of them might be correct!

          In the future, if we SEED standard adopts some way to represent unknown
          values or similar I can see us filtering stuff, we need good documented
          rules though.  For now problems like these are much better addressed
          upstream in my opinion.

          Chad

          On May 11, 2011, at 9:21 AM, Philip Crotwell wrote:


          Hi

          One of our stations has an "unknown" sensor. I know that sounds weird,
          but it is old, 50 meters down a borehole backfilled with concrete and
          no records left from the installation. So, in order to get the data to
          the archive, we had to submit dataless where the response was filled
          in, but in a way that says "we don't know". Mary said that the correct
          way to do this was a unity gain blockette53 with no poles or zeros. If
          you have the full response, this is a pretty noticeable oddball. But
          in the channel level of the station web service, you get just the
          overall sensitivity. It is probably still relative clear that this is
          bogus, but not quite as clear as it is the 1 from the sensor combined
          with the actual gain from the digitizer, so you get something like
          629129.0 for the sensitivity. As this appears to be somewhat of a
          standard, it might be better if the station web service could tell the
          difference between this type of "syntactically correct, but obviously
          wrong" response and just not publish a value for those stations to
          avoid sending out wrong values.

          If you are interested, the stations with this issue from our network
          are CO.CSB and CO.RGR.

          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


          _______________________________________________
          webservices mailing list
          webservices<at>iris.washington.edu
          http://www.iris.washington.edu/mailman/listinfo/webservices



Page built 02:14:21 | v.090361a2