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