Add 300 level rule: Seimic Instruments must include azimuth and dip

[timronan]

We should add a 300 level rule that uses the instrument code to determine if azimuth and dip must be included in the stationxml document.

[timronan]

The rule should read:
320: IF Channel:Code[2]==(H | L | M) THEN Channel:Azimuth and Channel:Dip must be included.

[rcasey-earthscope]

I think N should also be included. Is this a complete enough instrument list, these three/four letters?

…

On Apr 7, 2020, at 11:02 AM, timronan ***@***.***> wrote: The rule should read: 320: IF Channel:Code[2]==(H | L | M) THEN Channel:Azimuth and Channel:Dip must be included. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#97 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFL4VN53I3KV6IWSHITXKXTRLNTFHANCNFSM4KUHLOGA>.

[timronan]

This issue has been addressed by rule:
320: If Channel:Code[2]==(H | L | M | N) THEN Channel:Azimuth and Channel:Dip must be included.

Refer to commit: 14d82eb

[metempleton]

We might want to think about whether to include “M” in this as well. Right now, dip and azimuth are most frequently set to 0. cheers, Mary

…

On Apr 27, 2020, at 4:21 PM, timronan ***@***.***> wrote: This issue has been addressed by rule: 320: If Channel:Code[2]==(H | L | M | N) THEN Channel:Azimuth and Channel:Dip must be included. Refer to commit: 14d82eb — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[timronan]

This rule does not enforce any specific values, it only enforces that the dip and azimuth element are included in the StationXML file.

Rule 320 throws an error, so the file will not pass validation or be loaded if this rule fails. @metempleton do you think this rule should be reduced to a warning? Also, do you think we should remove M?

Thanks

[metempleton]

Those are the questions I’m asking myself. Since it’s required already for SEED (people just side step it), it probably won’t hurt to leave it if none of the other rules will be unhappy with 3 “orthogonal channels having the same dip and azimuth”. It definitely needs to be an error for the seismic channels. Mary

…

On Apr 27, 2020, at 5:00 PM, timronan ***@***.***> wrote: This rule does not enforce any specific values, it only enforces that the dip and azimuth element are included in the StationXML file. Rule 320 throws an error, so the file will not pass validation or be loaded if this rule fails. @metempleton do you think this rule should be reduced to a warning? Also, do you think we should remove M? Thanks — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[timronan]

If the channel codes are labeled as NEZ than the channels with the E and Z labels will trigger warnings 333 and 334 respectively. If the orthogonal channels follow a different naming convention, which they maybe should, than the warnings won't be triggered.

If "M" instruments use the NEZ naming convention we should consider removing M from this rule, otherwise we will receive a lot of unnecessary unresolvable warnings.

[metempleton]

With just a quick perusal of large networks, it looks like those who do use NEZ are writing appropriate dips and azimuths. Those who use UVW or 0-6 are writing 0 for all. So we might not receive too many unnecessary complaints. Probably worth a try…

…

On Apr 27, 2020, at 5:45 PM, timronan ***@***.***> wrote: If the channel codes are labeled as NEZ than the channels with the E and Z labels will trigger warnings 333 and 334 respectively. If the orthogonal channels follow a different naming convention, which they maybe should, than the warnings won't be triggered. If "M" instruments use the NEZ naming convention we should consider removing M from this rule, otherwise we will receive a lot of unnecessary unresolvable warnings. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[timronan]

We will leave this rule as is and close the issue. We can revisit this rule if it turns out to be too sensitive. Thanks for checking the metadata. We will remove M from rule 321 referenced in issue #96. Thanks @metempleton for reviewing the additional rules added to the validator.