[AlainKnaff]

📝 Possibility to show track of an older hike along with current track

📖 Description

This adds the possibly to overlay an older track over the current track. Older track will be shown in red (versus dark blue for the current). Accessible from the map display activity using the "hamburger" (3 dots) menu at top right, and choosing "Overlay other".

This is useful when walking near a place where you've been before, in order to compare.

✅ Pull Request Checklist

• The PR is proposed to the DEVELOP branch.
• The changes have been tested on the target Android API and minimum Android API.
• Automated tests have been added (if applicable).
• The feature is well documented.
• There is a reference to the original ISSUE and related work.

[AlainKnaff]

I've rebased on the latest develop to account for recent schema changes.
Also cleaned up lots of messy test commits.

Ready for review whenever.

Thanks

[jamescr]

This contribution is awesome! The ability to overlay a track on top of the current one opens up contexts that I can see being used in systematic participatory mapping. For example, when a mapping campaign distributes sectors or routes among different volunteers (similar to how drone flight planning splits tasks across operators, or how a tasking manager assigns areas), being able to see the route you were assigned while recording your own is a huge help. In that kind of workflow, the overlay becomes a coordination tool, not just a visualization feature. That's a direction I'd love to explore, and I think this PR is a great starting point for it. To get there, though, we'd need to redesign the functionality so it can support these other use cases.

The current implementation runs into some friction for the next release (2026.11). The main point is the data model: the overlay is a visualization preference for the map screen, not a property of the track itself that requires being persisted in the DB. If the track requires an association with an overlay, at this step it would be better to use a SharedPreferences entry.

For the 2026.11 release specifically, I'd like to include the functionality in a simplified form: show the overlaid track without persisting the relation in the database. That keeps the migration out of the release, reduces the surface area of the change, and still delivers the core value (seeing another track on the map). The rest of the design (how overlays interact with tasking managers, whether multiple overlays should be supported, and how the UI communicates which track is overlaid) can be developed in a follow-up issue/discussion and added in a next release.

On the implementation side:

• Remove the unrelated changes in GPSLogger and ExportTrackTask. They don't belong to this feature (the refactor should be in a separate commit).

• Keep the overlay selection in-memory in DisplayTrackMap (or in SharedPreferences), and drop DataHelper.updateOverlay/queryOverlay, the overlay table, and the TrackContentProvider URIs for it.

• Add tests: at minimum, that DisplayTrackMap draws the overlaid polyline with the correct points.

I'm happy to do the cherry-pick myself and adapt the code to this simplified form or to give you room to do it in a new PR. Either way works for me. Please let me know which you prefer.

I'm very excited about the potential of this contribution. Thanks!

[AlainKnaff]

This contribution is awesome! The ability to overlay a track on top of the current one opens up contexts that I can see being used in systematic participatory mapping. For example, when a mapping campaign distributes sectors or routes among different volunteers (similar to how drone flight planning splits tasks across operators, or how a tasking manager assigns areas), being able to see the route you were assigned while recording your own is a huge help. In that kind of workflow, the overlay becomes a coordination tool, not just a visualization feature. That's a direction I'd love to explore, and I think this PR is a great starting point for it. To get there, though, we'd need to redesign the functionality so it can support these other use cases.

Thanks for your enthusiasm :-)

The current implementation runs into some friction for the next release (2026.11). The main point is the data model: the overlay is a visualization preference for the map screen, not a property of the track itself that requires being persisted in the DB. If the track requires an association with an overlay, at this step it would be better to use a SharedPreferences entry.

ok, and that will also solve the issue about the patch going "stale" whenever an unrelated database schema change happens :-)

For the 2026.11 release specifically, I'd like to include the functionality in a simplified form: show the overlaid track without persisting the relation in the database. That keeps the migration out of the release, reduces the surface area of the change, and still delivers the core value (seeing another track on the map). The rest of the design (how overlays interact with tasking managers, whether multiple overlays should be supported, and how the UI communicates which track is overlaid) can be developed in a follow-up issue/discussion and added in a next release.

ok. I'll prepare an update without the DB.

But independently from that we need a way to have faster turnaround for any future PRs where we'd have a database schema change. DB schema changes cannot always be avoided as easily as here.

On the implementation side:

* Remove the unrelated changes in GPSLogger and ExportTrackTask. They don't belong to this feature (the refactor should be in a separate commit).

Not sure what is going on here. GPSLogger was old stuff from the segment id PR (that later got discarded => so just unused methods). ExportTrackTask was just spacing changes

I pushed a commit which undid that (by copying the 2 files from the develop branch)

Another commit for removing the DB stuff will follow.

* Keep the overlay selection in-memory in DisplayTrackMap (or in SharedPreferences), and drop DataHelper.updateOverlay/queryOverlay, the overlay table, and the TrackContentProvider URIs for it.

* Add tests: at minimum, that DisplayTrackMap draws the overlaid polyline with the correct points.

I'm happy to do the cherry-pick myself and adapt the code to this simplified form or to give you room to do it in a new PR. Either way works for me. Please let me know which you prefer.

For the moment, I prefer to continue with this one, unless you prefer to start another one.

Sorry for the rebase instead of merge. I was following bad advice, and later learned that this is a big no-no for code that has potentially already been shared.

I'm very excited about the potential of this contribution. Thanks!

Thanks for having considered this.

Regards,