Next generation miniSEED - 2016-3-30 straw man change proposal 1 - Combine Location and Channel codes

[Chad Trabant]

Hi all,

Change proposal #1 to the 2016-3-30 straw man (iteration 1) is attached: Combine location identifier with channel codes.

Please use this thread to provide your feedback on this proposal by Wednesday August 24th.

thanks,
Chad

[Chad Trabant]

Hi all,

The main concern I have with this idea is that channel designations would be unwieldy, too complex. The current channel codes are already packed with information, with each code meaning something. Combining this with arbitrary location identifier(s) makes them pretty messy.

In addition, the proposed allowed patterns, where the length must be 3,5,6,7 or 8, requires knowing which length implies which parts are (arbitrary) location versus (defined by convention) channel and recognizing a single versus double Instrument codes. Fairly ugly but probably parseable by machine. Confusing to read for a human and probably very difficult to talk about coherently (which I find to be a decent guideline).

Also, it is quite common to select data based on channel codes. For example, LHZ, ?HZ or BH? for a given time and area. Adding multiple variations to the pattern could make this pretty difficult for the user to get right.

There is an advantage of dealing with the empty location ID problem. But the more I think about it this may not be worth it.

Chad

> <1-Crotwell-CombineLocChanCodes.pdf>
>
> ----------------------
> Posted to multiple topics:
> FDSN Working Group II (http://www.fdsn.org/message-center/topic/fdsn-wg2-data/)
> FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)
>
> Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
> Update subscription preferences at http://www.fdsn.org/account/profile/

[Philip Crotwell]

Hi

Perhaps I should have split this into two proposals. I was under the
impression that one item that needed attention was extra space for new
instrument codes. If this is not the case, then this would be much
simpler. Combine location and channel codes into a single string,
minimum length 3, maximum length 7, last 3 characters corresponds to
the existing channel code, remaining 0-4 characters (at beginning)
correspond to the existing location code.

This has the advantage that the band, gain/instrument and orientation
codes are at fixed offset from the end of the string.

For me at least, when I talk about a channel with locid 00 and channel
code BHZ, I say "0 0 B H Z", and if I say "0 0 B H Z" I suspect most
people parse that as loc id 00 and channel BHZ. I think this also
allows fairly easy wildcarding in requests, so "*LHZ", "*?HZ" or
"*BH?" would be the equivalent queries where you don't care about loc
id.

I just feel that a solution that eliminated the empty loc id
problem/argument, but in a way that does not require renaming old
channels, has merit.

thanks
Philip

[Tim Ahern]

I would favor keeping the location and channel codes as separate entities. There really is not any penalty in terms of space and it is what the community is used to.

Cheers

Tim Ahern

Director of Data Services
IRIS

IRIS DMC
1408 NE 45th Street #201
Seattle, WA 98105

(206)547-0393 x118
(206) 547-1093 FAX