Philip Crotwell
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
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
-
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
-
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)
-
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
-
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
-
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
-
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
-
-
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
-
-
-
Chad Trabant
Doug Neuhauser
Meredith Nettles
Robert Casey
