[webservices] ws-station and obviously wrong sensitivity

Meredith Nettles nettles at ldeo.columbia.edu
Tue May 17 09:44:28 PDT 2011


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




More information about the webservices mailing list