Make History Information Accessable and Usable

As it has come up repeatedly, saqc does not really give the user possibilities to make use of its complex history/tracking mechanics. Currently only the dmp-comment field and the plot function do really profit from the history. Since a lot of work went into the implementation, and also ultimately the flags tracking is what makes saqc unique - i find this a pitty.

I also think, there are easy ways to enable flags tracking, without much extra work - what makes me feel it even more of a pity, that it isnt there:

  1. Dont hide the history Object:
  • Is there any reason, why we dont allow any history-accessor, like, returning a dataframe, upon, for example qc.history[field]? This would at least allow a user to construct a history-sensible pipeline by manually inspecting the history and reinstantiating saqc objects.
  1. Allow keyword based labeling.

  • As it works with the plot-label workflow, I think it can be futile to allow the option to associate history columns with user defined IDs. By this, the following work flows can be easily implemented:

  • Make isFlagged sensible for the ID, so that flagGeneric can be passed logical conditions based on variables and tests. This enables a lot flagging workflows that may appear too complex for saqc on first sight, because it allows for more complex logical dependencies, and a lot of flagging worflows is of the type: "Flag this, if testX did that and testY did this". So it would look like:

qc.flagFuncY(field,parameters,id='testY')
qc.flagFuncX(field,parameters,id='testX')
qc.flagGeneric(field, field1, func=lambda x: isflagged(field, 'testY') & isflagged(field, 'testX'))
  • Basically any function that does history-sensible operations (such as the flags Repeater) can be easily implemented and used in a syntactical atomic way, by allowing it evaluation of the ID keyword.
qc = qc.flagRange(field, min=-10, ID='min_test')
qc = qc.flagAfter(field, '3H', 'min_test')

Since we wont be able to work extensively on saqc development in the near future, i feel even more that this things should be considered to bring in soon, since it are options, both feasable in implementation effort and futile in tracking enabling.

Edited by Peter Lünenschloß