Allow editing of recorded data

[c33s]

just made a long walk recorded and forgot to turn off recording after i was back at the car. so the last 30secs of the recorded data ruin all the statistics (no i was not walking with a speed of 30km/h :joy:

would love to simply edit the entry and delete the wrong data.

[dennisguse]

Would be really cool - let's see how much effort it would be.

If we need a map for this, then it is likely out of scope as the integration with OSMDashboard will be kind of difficult.

[pstorch]

Maybe trimming function by time (remove 30 seconds from the start and 35 minutes from the end)?

[dennisguse]

@pstorch Nice idea! Something like that would feasible. We could use the diagrams to set a trim points.

[dennisguse]

Blocked by #192 as we cannot recompute the TrackStatistics at the moment.

[dave-kennedy]

Is this feasible now that #192 is closed?

[dennisguse]

@dave-kennedy Yes, the internal data structures would support this. The complicated part is actually the UI...

[Pulau-Komodo]

This addition would help me a lot as well.

To keep the discussion going, I came up with two different proposals for the UX:

Proposal A

The user goes to the edit screen for the particular activity. The edit screen has a "trim" button, below the description field. The user presses it, and he goes to a screen with "by time" and "by distance" tabs. They are the usual ones, but now two vertical bounds bars that start out on the far sides of it, that can be dragged to select a smaller region. When these are adjusted, internally it is determined which nodes would be eliminated by that, and the bars snap to reflect the actual resulting trim. Then, the user can go between the two tabs and see the same trim (which will look different, unless the track had a constant pace) represented in both.

At the bottom there is a bar with the options "cancel" and "trim", like the "cancel" and "save" on the edit screen. "cancel" goes back to the edit screen with the trim discarded, and "trim" goes back to the edit screen with the trim remembered. If it was not discarded, the "trim" button on the edit screen now says "adjust trim", and pressing it will allow the user to resume dragging the bounds from where he left them before. Cancelling when resuming editing the trim then will only discard the latest set of changes, not the trim previously submitted.

The edit page then also has a small summary of the trim below the "adjust trim" button, saying something like "Trimmed to a/b nodes, c/d distance, e/f time". Then if the user presses "save", the trim applies to the file permanently, deleting any excess nodes. If the user presses "cancel", nothing is saved.

Proposal B

The regular "by time" and "by distance" tabs have the permanent addition of the aforementioned vertical bounds bars. When they are adjusted, they are remembered across all screens but not yet saved to the file. For the "by time" and "by distance" tabs, it means the same as in proposal A, but for the "stats" and "intervals" tabs, the information reflects only the selected range. The map icon button also reflects only the selected range.

If the bounds are not in their default position, the overflow menu has the new options "trim to selected range", which applies the trim to the file permanently as above, and "new track from selected range", which adds a new track to the list. The new track is essentially the same as the outcome from trimming, but the original track is untouched. The new track has a generated name, like " trimmed", which can of course be edited like any track's. The date of the track is adjusted to reflect only the values still included.

Closing thoughts

As I wrote these out, I came to like proposal B better, for the flexibility and functionality it adds. It could be used to split multiple activities from one track. It would even allow a user to keep the track running all day, only to split out the actual activities later. Proposal B also involves fewer user actions to achieve the outcome. But proposal A is a more direct implementation of the desired feature for the use case of leaving it running a little too long, and does not change any of the existing UI, beyond the button on the edit screen.

[c33s]

i know that as soon as it comes to frontend, gui and error handling (yes users can really do a lot of things you haven't thought about) it it getting tough.

so i thought about to adding a flag to the settings menu "enable trimming" (to prevent polluting the menu for regular users). if you enable it you may even get a warning like "there are dragons here" like when you go to about:config in firefox.

if enabled you get a "trim start, trim end, trim start by, trim end by" menu entries (or maybe not all four but only the last two to simplyfy it even more). when clicking on the "by" menu entries, a simple textbox popup let you enter plain integer seconds which will be cut from the start/end of the track. for the other two entries there could be some logic like cut everything with a speed of zero from the beginning/end.