-
Notifications
You must be signed in to change notification settings - Fork 2
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
Conformity with other documents #26
Comments
Interesting stuff, thanks for sharing. OBS do provide unique challenges for sure. Lots of this feels like it needs to be taken care of within either a stationxml revision and/or future miniseed3 spec. Perhaps filing issues on the stationxml github would be helpful? A stationxml revision will probably be needed at some point to take advantage of this spec, and so having issues lined up in github makes it more likely they can be addressed at the same time. |
Interesting that the structual monitoring part of that document has:
as opposed to the Z12 convention. Oh well.... |
Yes, I had discussions with John Clinton of GFZ who really wanted the horizontals to be '23' instead of '12'. I think we're up against institutional practices in the lack of a global guideline. I think it would be good to establish a global guideline (we'll anger GFZ if we say '12', the US OBS community if we say '23') but clearly say that in either case the true references will be the dips and azimuths. Azimuths are useful even if the uncertainty is 180° because the relative azimuth between two channels can be specified.
…_______________________________
Wayne Crawford
CNRS Researcher
Institut de Physique du Globe de Paris
1, rue Jussieu
75238 Paris Cedex 05
+33 6 5151 1054
On 4 September 2020 at 16:52:22, Philip Crotwell ([email protected]) wrote:
Interesting that the structual monitoring part of that document has:
HN[Z23] for orthogonal sensors with horizontal sensors oriented in the principal directions of the structure (standard practice in structural monitoring),
as opposed to the Z12 convention.
Oh well....
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
It would be best if the FDSN document covers some sujects broached in other documents since the SEED 2.4 manual was published. Being an OBS guy, I'm specifically thinking of two documents that I include below, but there are probably others as well.
Doc 1: White Paper on OBS data, specifically the sections on "Proposed modifications to the StationXML and miniSEED formats" and "OBS data/metadata standards and best practices"
Doc 2: : SERA deliverable on metadata problems and proposed solutions (chapter 4 is extracted from the White Paper)
Of course, this is a lot to read and I have tried to provide the OBS stuff, but the other sections of Doc 2 are probably closer to your specialities than to mine.
Does anyone know of any other documents that should be parsed? The idea is that a good FDSN document could allow these documents to be greatly simplified, as they are in many cases responses to elements lacking from the present documentation.
By the way, I call my ephemeral networks "XX" so I probably saw the document mentioning this at some point, but I could never re-find it when I needed to justify my actions!
The text was updated successfully, but these errors were encountered: