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

On Aug 19, 2016, at 6:41 AM, Philip Crotwell <crotwell<at>seis.sc.edu> wrote:

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

On Thu, Aug 18, 2016 at 9:19 PM, Chad Trabant <chad<at>iris.washington.edu> wrote:

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

On Aug 11, 2016, at 12:41 PM, Chad Trabant <chad<at>iris.washington.edu> wrote:


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


<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/




----------------------
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/

----------------------
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/