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

Strike and dip versus azimuth and inclination or dip #2

Open
chad-earthscope opened this issue Nov 14, 2024 · 0 comments
Open

Strike and dip versus azimuth and inclination or dip #2

chad-earthscope opened this issue Nov 14, 2024 · 0 comments

Comments

@chad-earthscope
Copy link
Member

Submitted by @anowacki

The spec currently suggests that the orientation of the fibre at each channel be given in strike ('degrees clockwise from east positive') and dip (angle downwards from the horizontal?).

Firstly, it feels unnatural to define an orientation or direction in space using 'strike'; it is usually used to define planes. (Trend and plunge are more common for directions or orientations.) Secondly, strike is more commonly measured as an azimuth from north, not from east. Finally, there are multiple geological conventions on how strike is measured, making this more ambiguous than need be.

I propose that we match existing conventions. SEED defines channel directions with azimuth (degrees east from local north) and dip (degrees down from the local horizontal; both in blockette 52). SAC uses inclination (degrees downwards from the local vertical direction) instead of dip.

My own preference is for the SAC convention, but would be happy with either as an improvement over the current proposal.

Tangentially, it is worth considering that strain(-rate) systems are orientational, not directional, so the direction of measure is 180°-ambiguous. In other words, it doesn't matter whether a channel is defined as pointing one way or the other in space.

Given than, should the spec constrain azimuths to be in the range [0°, 180°) (or [–90°, 90°))? Or is it better to leave the possibility of specifying the channel orientation in two ways? Or perhaps should it be defined as being the direction in which the laser travels? This would then remove the directional ambiguity.

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

No branches or pull requests

1 participant