Closed sstucker closed 2 years ago
Would a brief example help clarify that this is not intended to replace the use of ACCEL_X
, ACCEL_Y
, ACCEL_Z
? Something like:
If multiple channels of related data are generated by a system, they may be encoded in the second dimension of the time series. For example, a system containing more than one accelerometer may output this data as a set of
ACCEL_X
/ACCEL_Y
/ACCEL_Z
auxiliary time series, where each has the dimension of<time points> x <no. accelerometer>
. Alternative uses of the channel data include storing complex numbers, ...
Yes, your example is more clear, I like it
Proposing this because of request #107 and because of the overhead of HDF5 groups in the Indexed Groups format defined by the SNIRF spec. (#103)
The language describing the ndim of
aux/dataTimeSeries
was already ambiguous, suggesting a unit 2nd dimension was required (this is different than an array of ndim=1 in the HDF5 format, see #99). This change allows for "channels" in an auxdataTimeSeries
with a caveat that 3-dimensional accelerometer sensors should still use individual aux blocks to be more backwards compatible.We could also introduce a new
"ACCEL_XYZ"
name in the appendix. The current names are intended to mirror the BIDS nomenclature for the same data, see #81