Offer POI list functions (filter etc) in "search in points" result list, same for tracks
Gathering feedback
Condensate of several real life situations: It would be great to have similar tools available in the result list of a "search in points" as we have in POI list, e.g. selection that is independent of visibility, filter, export, move etc. The required implementation work is probably very limited as the GUI and functionality already exists.
Example use cases:
- Imagine you want to show someone the mountain whose name / spelling just does not want to be memorized by your brain. As the POI could be in several POI folders (e.g. because you're having one folder per region and the mountain is the border of 4 regions) you would prefer to use search in POIs. Sadly, there you cannot filter by icon "mountain" - would it not be great to have the same filters from POI folders available here?
- A friend is going to a location I've been and I want to export him a selection of my POIs of that area, which are of course scattered across several folders. Currently, you've to make one export per folder. After implementation of this idea, you could simply do a search around the center of the area, tap export, and adapt the selection to the relevant POIs without altering their map visibility.
I like this idea 
And a natural extension is to offer similar features for tracks. I am thinking of the "nearest POI" feature, which already works regardless of visibility setting since some releases.
Findings nearest track points is way too costly (runtime), but (depending on the data model/DB setting used - again: computational complexity/runtime question), either a bounding box for the track, or a rectangle formed by start/end point would work in practical terms.
And the inclusion of tracks should be optional, of course :-)
And a natural extension is to offer similar features for tracks. I am thinking of the "nearest POI" feature, which already works regardless of visibility setting since some releases.
Findings nearest track points is way too costly (runtime), but (depending on the data model/DB setting used - again: computational complexity/runtime question), either a bounding box for the track, or a rectangle formed by start/end point would work in practical terms.
And the inclusion of tracks should be optional, of course :-)
Replies have been locked on this page!