Repository navigation
Track import: keep handovers as indices into the recording - #103
Merged
Merged
Conversation
Moving a handover bounded the tap by its neighbours, which were looked up again by coordinate with indexOf. A handover read off an entry's own position lies beside the line rather than on it, so the lookup returned -1, the upper bound became -2, and every tap snapped to the recording's first point; after that no tap could move it again. The import screen now holds each handover as a cut index, resolved once when it opens (trackCutIndices, which also keeps room for open ones), and derives the bounds, the preview and the written division from those indices (splitTracksAt). The mark is drawn on the line where it cuts; the coordinate is kept only as what gets written onto an entry that had none. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When a recording is divided among several entries, a handover that was read off an entry's own coordinates could not be moved. Tapping to move it threw it back to the recording's first point, and after that no tap moved it at all.
The trigger was a return trip by train with short walks at Malmö and Copenhagen. Every handover came from a leg's station coordinates, and the walk at each stop was a loop that started and ended at the station. The automatic division put the handovers on both sides of each walk five seconds apart, which is expected for a loop. The bug is that they then could not be corrected.
Cause
_placebounded a moved handover by its neighbours and found them again withindexOf(coordinate). A coordinate taken from an entry lies beside the line, not on it. So the lookup returned −1, the upper bound became −2, and the snap clamped to index 0.Fix
trackCutIndices, which also keeps room for open handovers), so moving one handover never moves another.splitTracksAt,snapIndexOnTrack). What is drawn is exactly what gets written.splitTracksandsnapToTrackkeep their signatures.trackIndexOfis removed.The automatic proposal for a loop that starts and ends at one station is still ambiguous by position alone. That is out of scope here: it can now be corrected by hand, and using the GPX timestamps could improve it later.
Tests
track_import_screen_test: a handover read off an entry's coordinates moves to where it was tapped, can be moved again, and leaves the other handover in place. On the old code this test fails because the handover lands on the first point.track_split_test: an open handover keeps its room, dividing by index equals dividing by point, and snapping on a there-and-back line picks the pass inside the bounds.flutter analyzeis clean and the full suite passes.🤖 Generated with Claude Code