Summary
Tracking (#1469) links detections and merges occurrences, but there is no way to undo a run on a session. That makes it hard to compare settings inside Antenna: once a session has been tracked, a second run with different settings is skipped by the "only track sessions that have not been tracked" guard, and turning the guard off only adds links and merges on top of the first run. Detections added to a session after it was tracked are also never tracked by default.
Proposal (to discuss)
An admin action, and later a job option, that resets tracking on selected sessions:
- Clear
next_detection on the sessions' detections.
- Split every occurrence the tracking run merged back into one occurrence per detection, copying identifications to each piece (the same rule regrouping uses when it splits an occurrence).
- Mark the sessions' tracking results as not current, so the history keeps them.
Open questions: what to do with occurrences a person edited or identified after tracking (skip the session, or keep those occurrences whole), and whether the split should restore the exact occurrences that existed before tracking, which needs the merged ids stored on each tracking result.
Related: #1469, #1468, #1416.
Summary
Tracking (#1469) links detections and merges occurrences, but there is no way to undo a run on a session. That makes it hard to compare settings inside Antenna: once a session has been tracked, a second run with different settings is skipped by the "only track sessions that have not been tracked" guard, and turning the guard off only adds links and merges on top of the first run. Detections added to a session after it was tracked are also never tracked by default.
Proposal (to discuss)
An admin action, and later a job option, that resets tracking on selected sessions:
next_detectionon the sessions' detections.Open questions: what to do with occurrences a person edited or identified after tracking (skip the session, or keep those occurrences whole), and whether the split should restore the exact occurrences that existed before tracking, which needs the merged ids stored on each tracking result.
Related: #1469, #1468, #1416.