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

require azimuth and dip either both or none #154

Open
crotwell opened this issue Aug 15, 2022 · 2 comments
Open

require azimuth and dip either both or none #154

crotwell opened this issue Aug 15, 2022 · 2 comments
Labels

Comments

@crotwell
Copy link
Collaborator

Current schema has azimuth and dip as optional within a Channel, which makes sense for non-seismic channels that do not have an orientation. However, if one of azimuth or dip is present, the other should be as well. Schema should enforce that.

@chad-earthscope
Copy link

In the case of a vertical sensor (dip = -90), any azimuth value is not meaningful and so just "fill". In the SEED standard, azimuths for vertical channels were supposed to be 0 (which is the same as for a "north" channel) and was necessarily as empty/unknown was not allowed.

In StationXML we have a chance to fix this. I suggest that omitting the azimuth value when it is inappropriate (for non-seismic channels or vertical channels) or unknown is informationally more correct.

@crotwell
Copy link
Collaborator Author

While what you say is correct, I think structurally it is easier if it is "both or neither," as opposed to
"both if dip != -90 or just dip or neither." Asking a client parser to have 3 possible ways is harder than two even if that means one case is degenerate. Also it is simpler to express in the schema.

To compare to another convention, when using polar coordinates in math, you always give both theta and phi, even in the degenerate cases of r=0 or theta=0.

In general I am in favor of removing unneeded elements, but in this case I think that requiring the structure to be there has merit even if the value is degenerate. That said, it is a small difference, so I would be ok with your style as long as the schema enforces it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants