[webservices] ws-station and obviously wrong sensitivity

Tue May 17 11:01:18 PDT 2011

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
>