For a lot of applications it is very helpful to know not only when a disturbance was confirmed (which nrt.disturbed_date is tracking at the moment), but also when the process value "left control" for the first time.
For users this is non-trivial to keep track of in an operational context, since it requires knowledge of how process and boundary values work for each algorithm. This is why I would say it makes sense to implement in nrt.monitor(). It should be relatively cheap to implement.
There's two cases to consider: recursive process values (MOSUM, CUSUM, EWMA) and independent process values (CCDC, IQR). For independent values, which test each new acquisition, the date when the disturbance was first detected is straightforward: As long as the pixel is monitored the "first disturbed" date is the date where the process value changes from 0 to 1.
For recursive process values the answer is a bit harder. Since the theory is that the process value in this case should oscillate around 0, I would propose to set the "first disturbed" date to the last time the process value switched signs (+,-) or was 0. This however might put the "first disturbed" date quite a lot before the date of the actual disturbance.
I have a draft PR here: jonasViehweger#1
I was also thinking of only implementing this only for monitors with independent process values (CCDC, IQR). This would make implementation a bit more complicated though.
Let me know what you think of this proposal.
For a lot of applications it is very helpful to know not only when a disturbance was confirmed (which nrt.disturbed_date is tracking at the moment), but also when the process value "left control" for the first time.
For users this is non-trivial to keep track of in an operational context, since it requires knowledge of how process and boundary values work for each algorithm. This is why I would say it makes sense to implement in
nrt.monitor(). It should be relatively cheap to implement.There's two cases to consider: recursive process values (MOSUM, CUSUM, EWMA) and independent process values (CCDC, IQR). For independent values, which test each new acquisition, the date when the disturbance was first detected is straightforward: As long as the pixel is monitored the "first disturbed" date is the date where the process value changes from 0 to 1.
For recursive process values the answer is a bit harder. Since the theory is that the process value in this case should oscillate around 0, I would propose to set the "first disturbed" date to the last time the process value switched signs (+,-) or was 0. This however might put the "first disturbed" date quite a lot before the date of the actual disturbance.
I have a draft PR here: jonasViehweger#1
I was also thinking of only implementing this only for monitors with independent process values (CCDC, IQR). This would make implementation a bit more complicated though.
Let me know what you think of this proposal.