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 · 4 comments
Open

require azimuth and dip either both or none #154

crotwell opened this issue Aug 15, 2022 · 4 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
Member

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.

@peacocks
Copy link

peacocks commented Dec 5, 2024

I should like to be clear about omitting the dip for scalar quantities. For vector quantities, is there a rule in the StationXML Schema that the InstrumentSensitivity and any StageGain values must be positive, and the azimuth and/or dip be set to point to the direction of motion that gives increasing digital values, as seems to be the rule in SEED (manual, p. 68: "If instruments are reversed in the field, reverse the dip/azimuth fields")? For scalar quantities, which the SEED manual doesn't seem to cover, if you omit the azimuth and dip, then a negative value of InstrumentSensitivity/StageGain is needed when an increase in the digital values is caused by a decrease in the quantity (e.g. pressure in a microbarometer or hydrophone). Does the schema say anything about this? If you don't want the inconsistency of allowing negative InstrumentSensitivities for scalar but not vector quantities, then is there a protocol for the (otherwise meaningless) dip value to indicate the "polarity" of the scalar quantity?

@crotwell
Copy link
Collaborator Author

crotwell commented Dec 5, 2024

I do not believe there is any requirement in stationXML that overall gain or stage gains be positive. I do think that in the case of "vector" channels, where az and dip are meaningful, that positive should be in the direction of the az/dip. But for scalar channels, postive and negative gains should be used to express the amplification that best matches the instrument and az/dip elements should not be used.

That said, if the overall gain (InstrumentSensitivity) might not be meaningful in this case, ie you need to know the zero point, then it is probably important that the correct Polynomial stage be given. Use of a Polynomial stage then implies that you should use InstrumentPolynomial instead of InstrumentSensitivity.

See the docs for Polynomial stage here:
http://docs.fdsn.org/projects/stationxml/en/latest/reference.html#polynomial

In addition, an InstrumentPolynomial element must be present at Response level to represent the whole acquisition process, which contains the same Maclaurin coefficients, but scaled by powers of the overall gain for all stages.

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

3 participants