The temporal scale triplet for LUBW data needs a statement about support, which is set to 1.0 by default.
This is the doc about support in a temporal context:
The support gives the temporal validity for a single observation. It specifies
the time before and after observation, that is still represented by the observation.
It is given as a fraction of resolution. I.e. if support=0.5 at resolution='10min',
the observation supports 5min (2.5min before and after the timestamp) and the
resulting dataset would not be exhaustive. Defaults to support=1.0, which would
make a temporal exhaustive dataset, but may not apply to each dataset.
We have Split-datasets for LUBW, 1 hour and 15 min data. Having support = 1.0 would mean that each measurement is representative for 1 hour or 15 min respectively. This is hard to believe for basically the same hardware used. I think the gauge measurements are just a time-snapshot, that does not integrate over 15min or 1 hour. The gauge might well have been very different.
I think this whole issue is very academic, but nevertheless, as we are academics we should think about this. To be really strict, we would have to replace this number with the actual time support of a measurement. @AlexDo1, @sihassl Thoughts?
And: the docs are not correct: (2.5min before and after the timestamp) is wrong it would be the 5min before the measurement. That is important for Eddy (but only a documentation issue). Can you update the docstring of TemporalScale, @AlexDo1 ? Thanks
@AlexDo1 @sihassl
The temporal scale triplet for LUBW data needs a statement about
support
, which is set to1.0
by default. This is the doc about support in a temporal context:We have Split-datasets for LUBW, 1 hour and 15 min data. Having
support = 1.0
would mean that each measurement is representative for 1 hour or 15 min respectively. This is hard to believe for basically the same hardware used. I think the gauge measurements are just a time-snapshot, that does not integrate over 15min or 1 hour. The gauge might well have been very different. I think this whole issue is very academic, but nevertheless, as we are academics we should think about this. To be really strict, we would have to replace this number with the actual time support of a measurement. @AlexDo1, @sihassl Thoughts?And: the docs are not correct:
(2.5min before and after the timestamp)
is wrong it would be the 5min before the measurement. That is important for Eddy (but only a documentation issue). Can you update the docstring ofTemporalScale
, @AlexDo1 ? Thanks