International Federation of Digital Seismograph Networks

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

None
Started: Aug. 11, 2016, 12:39 p.m.
Last activity: Aug. 19, 2016, 12:47 p.m.

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




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


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


      • 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




        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/