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: 2016-08-12 00:28:05
Last activity: 2016-08-12 23:37:26

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/


    • I agree with Change proposal #16 to retain and reorganize the status bits.
      Since only four bits of the proposed 16 bits are currently defined the
      specification should be explicit that all undefined bits must be set to 0.

      With respect to:

      ... 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 submit we can talk about opaque headers and we can talk about optional
      headers, but never as if the two were interchangeable. They are not. If a
      header is opaque then, by definition, there is no structure defined for it
      and is of no value to anybody other than the data producer. If the wish is
      to communicate the information in an opaque header to a broader audience,
      then it should be done via an optional header with a defined structure.

      I see the use of opaque headers as being of value solely to the data
      producer. If it is intended that the contents are for general consumption
      then they should be in a well defined, optional header.

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


      I agree completely. And so to address your specific example of having
      multiple event detectors, why not choose interpret the "event in progress
      bit" to mean simply that "an algorithm has determined, possibly correctly,
      that an event is in progress". You, as the data producer and running
      multiple event detectors, are then free to generate an opaque blockette
      that told *you* everything *you* wanted to know about the state of all your
      event detectors. In fact, I would argue that is a good example of the
      utility of opaque headers as part of the specification.

      David Chavez
      Project IDA
      UC San Diego