Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

warn on channel at depth if elevation is station elevation #121

Open
crotwell opened this issue Sep 4, 2020 · 10 comments
Open

warn on channel at depth if elevation is station elevation #121

crotwell opened this issue Sep 4, 2020 · 10 comments
Labels
Discussion A solution to this issue is currently being deliberated. Expect a delay in resolution.

Comments

@crotwell
Copy link
Contributor

crotwell commented Sep 4, 2020

Channel elevation is supposed to be elevation of the sensor, but it is easy to mess this up and put in the ground elevation in instead. For the majority of cases, channel elevation + channel depth == station elevation but this probably shouldn't be required, especially for sensors installed laterally away from a stations location in hilly terrain.

Two ideas to catch common errors:

  1. Warn if channel elevation + channel depth != station elevation

  2. Warn if channel elevation == station elevation AND channel depth != 0

First is a more comprehensive check, but might generate to many false positives. The second would miss some errors, but would catch the most common error of misunderstanding the meaning of channel elevation. I, at least, have been guilty of this.

@crotwell
Copy link
Contributor Author

crotwell commented Sep 4, 2020

See #122 for example where I did this incorrectly.

@timronan
Copy link
Collaborator

timronan commented Sep 9, 2020

This rule seems like it would throw a number of false positives and should likely not be included in the validator, even as a warning. We need to be careful about discrediting the validator warnings with false positives. It seems that potentially missing an instance of this error is better than having false positives thrown and having the community discredit the validator.

Example false positives: An infrasound microphone at the Earth's surface that is not colocated with it's datalogger does not have to be at the same elevation as the datalogger.

Deviated boreholes where the channel's surface location is different than the station's surface location.

@crotwell
Copy link
Contributor Author

crotwell commented Sep 9, 2020

You could take care of your false positives by only doing this check if the channel lat/lon was the same as the station lat/lon.

@timronan
Copy link
Collaborator

timronan commented Sep 9, 2020

Making a latitude and Longitude check does seems like it would eliminate the false positive issues. So the rule would be:

IF Station:Latitude = Channel:Latitude and Station:Longitude = Channel:Longitude THEN Station:Elevation must equal Channel:depth + Channel:Elevation

If a sensor was above the Earth's surface, in a building for example, would the user have to use a negative depth value for this check to hold true?

@crotwell
Copy link
Contributor Author

crotwell commented Sep 9, 2020

Yep, that looks right to me.

And above ground sensors would have negative depth.

@chad-earthscope
Copy link

The proposed rule is based on an interpretation that the Channel:Elevation is the "true" elevation of the Channel/sensor and not equal to Station:Elevation when Channel:Depth != 0. When I read the tea leaves of the SEED manual that does appear to be what is meant, and it makes sense from a data usability perspective.

Unfortunately, spot checking a number of borehole stations from many operators, it appears that many have assumed that Station:Elevation and Channel:Elevation are equal and the true elevation of the sensor must be calculated by adding the Channel:Depth value. Not one odd-ball network, but major permanent networks.

Regardless what the "right" answer is it would be difficult to have such a rule until a consensus is determined. This is a good bookmark for the issue.

@timronan timronan added the Discussion A solution to this issue is currently being deliberated. Expect a delay in resolution. label Sep 23, 2020
@crotwell
Copy link
Contributor Author

Should this be addressed in a stationxml revision? At least clarify in the docs?

@rcasey-earthscope
Copy link

I have attached an explanation to the 'Discussion' label attached to this issue. We currently do not have a clarification or solution worked out so will not yet modify anything in the docs or logic until this is formulated.

@crotwell
Copy link
Contributor Author

crotwell commented Oct 2, 2020

Just a note, if this interpretation of channel elevation is not followed, then rule 223 no longer checks to see if the channel is within 1 km cube of station and so should also be modified.

@rcasey-earthscope
Copy link

rcasey-earthscope commented Oct 2, 2020 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Discussion A solution to this issue is currently being deliberated. Expect a delay in resolution.
Projects
None yet
Development

No branches or pull requests

4 participants