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.
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.
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.
Chad Trabant
Philip Crotwell
David E. Chavez