Bug #808
FDSN StationXML has a restriction about azimuth - excludes 360, SEED does not
0%
Description
We have discovered we have users who want to specify azimuth as 360. But we can't make FDSN StationXML for them because the schema excludes 360 (includes 0).
According to the SEED manual p68
"Traditionally, the mass (boom) on vertical seismometers is oriented to the north, but sometimes this is not possible. If you know the vertical orientation, place it in the azimuth field. If the orientation is 0 degrees, use an azimuth of 360.0. If you do not know the orientation, set the azimuth to 0.0.”
My question is -- if we need to modify our StationXML schema to permit 360 -- will this be an issue for the converter?
Also - should I log an issue with the FDSN StationXML schema on GitHub?
History
#1 Updated by Ellen Yu over 8 years ago
Hi, I was wondering if there was any status change on this issue.
It would appear if we do not want to make a change to the FSDN StationXML schema -- for example, if the user does not know the orientation, they ought to leave azimuth null in FDSN StationXML -- that the converter would need to determine whether to take a null azimuth and make it 0 and like wise - if the azimuth is 0 - populate dataless SEED with the value 360 for certain situations.
What approach should the converter take?
Ellen
#2 Updated by Chad Trabant over 8 years ago
Hi Ellen,
In this particular case the SEED rule is a kludge to differentiate known from unknown that is much clearer in StationXML. As you say, if the azimuth is unknown the element can be left out of the XML. Furthermore, there is an uncertainty attribute. We should use these features instead of carrying along the dataless SEED oddity in my opinion.
If you disagree, you'll need to submit a change request to the FDSN following the procedure outlined in the Github repository README.
Otherwise, what you describe as a decision process or the converter is exactly what I think we should do. You can plan on us making the following change:
- If converting from StationXML -> SEED
- If StationXML Azimuth is not present
- Set SEED value to 0
- If StationXML Azimuth is 0 and the dip is 90 or -90 (vertical)
- Set SEED value to 360
- Otherwise
- Set SEED value to StationXML value
- If StationXML Azimuth is not present
- If converting from SEED -> StationXML
- If SEED azimuth is 0 and the dip is 90 or -90 (vertical)
- Do not include an Azimuth element in StationXML
- If SEED azimuth is 360
- Set StationXML Azimuth value to 0
- Otherwise
- Set StationXML Azimuth value to SEED value
- If SEED azimuth is 0 and the dip is 90 or -90 (vertical)
Thanks for bringing this issue up.
Chad
#3 Updated by Yazan Suleiman over 8 years ago
- Status changed from New to Resolved
#4 Updated by Robert Weekly over 8 years ago
- Status changed from Resolved to Feedback
- File BILL_aztest_2seed.dat BILL_aztest_2seed.dat added
If converting from SEED -> StationXML If SEED azimuth is 0 Do not include an Azimuth element in StationXML
This behavior is still incomplete. The converter will take a zero-value SEED azimuth and create the <Azimuth>
element with a value of 0.0 instead of leaving it out of the XML.
Attached is the input dataless SEED used for testing. The 1st and 5th epochs in the file contain zero-value azimuths, so the resulting XML should only have 3 <Azimuth>
elements.
#5 Updated by Chad Trabant over 8 years ago
An important detail was left out of the rules: I believe the description from the SEED manual in the original issue report means that this is only for vertical sensor orientations. In other words, this rule should only apply when the dip value is -90 or 90.
#6 Updated by Chad Trabant over 8 years ago
OK, after a re-read of the SEED Manual this mapping rule should only apply to vertical channels.
To be clear: the converter should only apply the "SEED azimuth is 0" and "StationXML Azimuth is 0" mappings when the dip value is 90 or -190. I have edited the rules above to reflect this in bold.
Rationale: There are many, many channels described in SEED with an azimuth of 0, in particular many horizontal channels. I believe that the intention of most of them are to indicate that the orientation is truly North. We should not be dropping those values when converting to StationXML. On the other hand, for vertical channels if we drop the azimuth values it is not critical.