International Federation of Digital Seismograph Networks

Thread: Next generation miniSEED - 2016-3-30 straw man change proposal 16 - Retain and reorganize bit flags

None
Started: Aug. 11, 2016, 5:28 p.m.
Last activity: Aug. 12, 2016, 4:37 p.m.

Hi all,

Change proposal #16 to the 2016-3-30 straw man (iteration 1) is attached: Retain and reorganize bit flags.

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

thanks,
Chad

P.S. The next 10 proposals/comments (#16 through #25) from KMI/Qaunterra are prefixed with the following general comment:

Paraphrase: "Omit information that is in some cases vital or at least useful to detailed understanding of the data acquisition environment and quality of the recorded data"

Recommendation: Understand the detailed SOH information that should be synchronously attached to waveform data, and suppress the urge to simplify to the point of loss of essential or useful information.

While developing and improving the widely accepted format revisions should be careful not to eliminate or force into the opaque “gray market” information that currently is defined and documented in the readily-accessible published format specification and is relevant and useful for the proper interpretation of the data and for understanding of the recording environment.




Attachments
  • HI

    I am not a fan of bit flags except in very narrow circumstances. Very
    few things can really always be reduced to a single yes versus no
    value, and so I would much prefer most of the information from
    miniseed2 flags that needs to be stored be done so as an
    opaque/optional header where there is room for fuller information.

    Just as an example, the event detector flags are potentially
    troublesome. Why should it be assumed that only one event detector
    will be run on a channel? If I have several and one triggers but a
    second doesn't, how should the bit be set? Moving this to a optional
    header allows room for more information and more flexibility in how it
    is represented.

    I feel the fixed section of the header should really be limited to
    just the absolute bare essentials. Just because information is stored
    in the opaque/optional headers does not mean that it is unimportant,
    nor does it mean that it cannot have structure defined for it.

    I would support the creation of storage structures for very commonly
    used items within the optional headers, and several of these items
    probably should have standard representations. But not everything
    useful or important needs to live in the fixed section. In addition,
    it may be better to separate out the definition of these common
    structures into a separate recommendation document from the core
    miniseed3 file format specification.

    thanks,
    Philip

    On Thu, Aug 11, 2016 at 8:29 PM, Chad Trabant <chad<at>iris.washington.edu> wrote:

    Hi all,

    Change proposal #16 to the 2016-3-30 straw man (iteration 1) is attached:
    Retain and reorganize bit flags.

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

    thanks,
    Chad

    P.S. The next 10 proposals/comments (#16 through #25) from KMI/Qaunterra are
    prefixed with the following general comment:

    Paraphrase: "Omit information that is in some cases vital or at least useful
    to detailed understanding of the data acquisition environment and quality of
    the recorded data"

    Recommendation: Understand the detailed SOH information that should be
    synchronously attached to waveform data, and suppress the urge to simplify
    to the point of loss of essential or useful information.

    While developing and improving the widely accepted format revisions should
    be careful not to eliminate or force into the opaque “gray market”
    information that currently is defined and documented in the
    readily-accessible published format specification and is relevant and useful
    for the proper interpretation of the data and for understanding of the
    recording environment.





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