Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feature request] automatically re-sort markers in top bar when (a) the chosen sort order is by distance, and (b) user clicks to expand / display the full list #6860

Open
warren-bank opened this issue Apr 23, 2019 · 0 comments
Labels
Nice to Have Should be fixed but there is no priority or no possibility to fix it within current horizon planning

Comments

@warren-bank
Copy link

Hi. I'm a huge fan of this project.. I use it.. and I love it.

That said, I'm currently preparing for a vacation with a lot of travel. I've prepared several GPX routes. I've added them to OsmAnd+ and then extracted all of the waypoints as markers. All of which works beautifully. I display these markers in the top bar, and sort it by distance (closest first).

My expectation is that as I drive around, this would automatically be re-sorted periodically (ex: once every 5 minutes) AND that it would automatically trigger a re-sort when the top bar is explicitly expanded (ie: by clicking the hamburger icon) to display the full list of sorted markers.

This automatic re-sorting is only relevant when the sort is based on distance. For other sort orders, it can be skipped.

I totally understand the desire to save as many CPU cycles as possible, but this feels like an over-sight. It currently necessitates manually triggering a re-sort to be able to see relative distance to other nearby waypoints, which is an easy thing to forget to do.. and (imho) an unreasonable expectation of users.

@vshcherb vshcherb added this to the 3.4 milestone May 10, 2019
@vshcherb vshcherb modified the milestones: 3.4, 3.5 Jul 7, 2019
@vshcherb vshcherb modified the milestones: 3.5, 3.6 Oct 28, 2019
@vshcherb vshcherb modified the milestones: 3.6, 3.6.5 Feb 3, 2020
@vshcherb vshcherb modified the milestones: 3.7, 3.8 Mar 9, 2020
@vshcherb vshcherb self-assigned this Jun 3, 2020
@vshcherb vshcherb modified the milestones: 3.8, 3.9 Jun 15, 2020
@vshcherb vshcherb modified the milestones: 3.9-android, future-android Nov 2, 2020
@vshcherb vshcherb removed their assignment Nov 2, 2020
@vshcherb vshcherb added the Nice to Have Should be fixed but there is no priority or no possibility to fix it within current horizon planning label Nov 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Nice to Have Should be fixed but there is no priority or no possibility to fix it within current horizon planning
Projects
None yet
Development

No branches or pull requests

3 participants