Allow setting a custom location to use for distances in search results

[joachim-n]

⚠ Have you searched for similar, already existing issues?

Is your feature request related to a problem? Please describe.

I am using search to look for amenities in a place I will be travelling to. The categorised search is very useful, but the results in the sidebar show a distance from my current physical location, which is not useful.

It would be useful to be able to set a temporary location, such as the train station, or the hotel, and then search results show the distance from that.

Describe the ideal solution

1. Set a point on the map as the current 'home' location.
2. search results and other distances compute from that point until the home location is cleared.

Describe alternatives you have considered

• How do you solve this issue now with Organic Maps or other apps?
• Attach any examples, screenshots, or screen recordings from other apps that help us to better understand the idea.

Additional context
Add any other context or screenshots about the feature request here.

[Jean-BaptisteC]

Did you already see this feature in another gps app?

[biodranik]

Can you use a ruler tool to measure the distance?

[muralito]

I think that OM already does that distance alculation for the sorting, but just does not display it to the user.

1. Click in some distant city.
2. Search for "hotel"
3. The results lists hotels sorted somehow by distance around the coordinates clicked in 1)
4. but the distance shown on that list is the distance from my current location.
   I suppose that the user wants to see the distance used for the ordering, and not the distance from current position, or maybe both, or switch between them.

[joachim-n]

Yes, that's right -- when I search, the results are for the portion of the map I'm looking at.

Set a point on the map as the current 'home' location.

A simpler solution, with less additional UI, would be to take the centre of the visible map as where to measure distance from.

[biodranik]

To make it obvious, the distance to the center of the screen should be drawn as a line from the selected object with a distance number on it.

[muralito]

The issue is not in the map view. Is in the results view.
You can replicate the issue for any point near you.

1. Click in the map in a city distant from you. (I clicked in https://www.openstreetmap.org/node/302608039 to take the following screenshot)
2. Search for hotel (or any other POI or string)
3. OM shows the following result. As you can see the distance displayed is measured from my current location (340km)
   The order of the items in the result list seems to be a distance from the point of the map clicked in the first step and these results (https://overpass-turbo.eu/s/1IJ0) are within 2 or 3 km from that centre.

What @joachim-n wants it that the search result shows that distance, and not from the current location. I saw this behaviour sometime ago, but i did'nt see as an issue, but now that another user reports the same, maybe it's a goog idea to be able to show one distance, or the other, or both of them depending on users choice.

[pastk]

3. As you can see the distance displayed is measured from my current location (340km)
The order of the items in the result list seems to be a distance from the point of the map clicked in the first step and these results (https://overpass-turbo.eu/s/1IJ0) are within 2 or 3 km from that centre.

Mmmm, this is hardly possible as a user can't start a search unless the currently selected map point / POI is reset/deselected. Right?

I agree that when a viewport is far away from the current device location then those distance numbers are not very useful. Well, they could be useful still to distinguish results around the viewport from the results found close to the location...

Still, I don't see a good non-confusing and user-friendly way to make this behavior changeable by a user.

[muralito]

Yes, i haven't noticed that you have to deselect it. But anyways.

The search, as it is implemented now, always took as it starting point the center of the viewport (which it could be the location of the user or in any other part of the world), and uses distance from that starting point to sort the items in the results list. right?
So the user implicitly selects the center of the viewport as the distance measurement center.

OM could choose what distance to display first depending in the zoom level and the distance of the viewport centre from the user location and the distance of the first item from the user and the center of the seach. And the user could switch to the other distance clicking in the distance itself (now if you click in the distance OM switchs to the map with the item selected). Maybe is helpful to add a tooltip or short text to the distance: "340 km from here" or "1 km from center" or "1 km from there"

[pastk]

The search, as it is implemented now, always took as it starting point the center of the viewport (which it could be the location of the user or in any other part of the world), and uses distance from that starting point to sort the items in the results list. right?

Viewport results are prioritized for sure, but the logic is probably more comlicated than that - @vng knows better.

OM could choose what distance to display first depending in the zoom level and the distance of the viewport centre from the user location and the distance of the first item from the user and the center of the seach.

It sounds like a quite complex heuristics which won't be understood by users and a "border" between two approaches will be blurry / not obvious..

And the user could switch to the other distance clicking in the distance itself (now if you click in the distance OM switchs to the map with the item selected). Maybe is helpful to add a tooltip or short text to the distance: "340 km from here" or "1 km from center" or "1 km from there"

Its very important to hint a user very clearly what kind of distance is displayed at the moment. E.g. I find "from here" or "from center" (center of what?) quite confusing. Do any other maps apps have such a feature? How do they solve it?

[muralito]

OM could choose what distance to display first depending in the zoom level and the distance of the viewport centre from the user location and the distance of the first item from the user and the center of the seach.

It sounds like a quite complex heuristics which won't be understood by users and a "border" between two approaches will be blurry / not obvious..

And the user could switch to the other distance clicking in the distance itself (now if you click in the distance OM switchs to the map with the item selected). Maybe is helpful to add a tooltip or short text to the distance: "340 km from here" or "1 km from center" or "1 km from there"

Its very important to hint a user very clearly what kind of distance is displayed at the moment. E.g. I find "from here" or "from center" (center of what?) quite confusing. Do any other maps apps have such a feature? How do they solve it?

Yes, it is important and it needs to be not confusing. Don't know about other apps. Maybe it's a feature that is better to have in the "trip planning" use case.

It's a completely different interfase, but i will try to post the screenshots of nuvi interfase, at it solves this use case and this one too #7616
Let me charge the device and remember how to take screenshots. :-)

[muralito]

Nuvi screenshots (map data is from OSM compiled with mkgmap)

The home screen:

Clicking the "Where to" takes to:

you can enter a text, switch the center of the search ("Searching near" button)

Clicking "Searching near" takes to (2 screenshots):

[muralito]

The other screen of "Searching near:"

Also in the search screen you decide to search for categories, address, intersection, coordinates, etc.

If you click in "Address" it takes you to enter the components of the address:

and the result list:

[muralito]

If you click in "Where to" -> "Restaurants" it takes you to a screen to enter a text, or select cuisine, or quick search some items.

[muralito]

What i mean posting all these screenshots is to show how another navigator guides the user to what he need.
Obviously this is an 12+ years old device, with no power to do the natural language processing.

If you only expose a textbox to search, the application needs to understand what the user is searching for.

By the way, the "searching near" shows the "other app" you asked for, but most of the screenshots are related to the defects that some users are reporting in other issues, like the #7616 refered before. It seems that most of the issues with search are not that OM or OSM has bad data, but that OM doesn't fully understand what the user is looking for.

[muralito]

These screenshots are when you click on "Searching near" to change the center of the search, and then "A Different City" and select Paysandú city (339 km away from me, same city of the previous OM screenshots)
when you select the city

the interface returns to the search (but note that the Searching near has changed)

Then select "Categories" (just to show which categories are offered, hotels are in the latest ones)

Then select logding

and "Hotels and Motels" takes me to the following screen. As you can see distances showed are measured from "search center"

Note that is an screen of 480 x 272 pixel, far from the 1080x2400 of the android device which has almost 20 times more pixels.

[pastk]

Thanks for the screens!

I think this "Searching near..." button approach might work indeed!
But perhaps it could be simplified to just a toggle between "where I am now" and "where I am looking at" (need better wording).

But first would be good to understand better how many users need this feature / will actually use it, to understand is it worth UI complication and development effort. Maybe a poll in OM chats can give some hints.

[muralito]

Sure. No need to rush to code it. :-)
It's useful in the context of a trip planning.
E.g. the "Search around: My active route" is also useful when you are in a trip and need a hotel, restaurant or any other amenity like a tire repair shop near your route (this is a little different, because the search is not around a center point, but around a polyline)
The others options seems that is the same old search but with a different center in each case.

[pastk]

E.g. the "Search around: My active route" is also useful when you are in a trip and need a hotel, restaurant or any other amenity like a tire repair shop near your route (this is a little different, because the search is not around a center point, but around a polyline)

When in the navigation mode, a distinction between "search along the route" (starting from the current position) and "search around the destination" might be helpful also.

[pastk]

(39 votes)

(34 votes)

I personally interpret it like "while users see it useful for e.g. trip planning, it doesn't justify added complexity".

(Also I'm surprised that some people expect to see results from around the current gps location first...
And quite a lot of people want to see current location results mixed in despite browsing a far away location)

[muralito]

When I click on search button OM displays the following screen. Do an additional option button or any UI component to switch the behavior (in the free spaces I marked in red) adds complexity? Yes.
It this this added complexity a reason to not implementing the feature?

How could be an over-complication an option that only users interested in it will choose to configure or change? Just keep the default as it is now, and the new feature will only be used if a user needs another search center.

[muralito]

And if you don't want to add a complexity to the "standard" UI, just put an configurable setting, that users can choice "Show advanced search" "yes/no", so users that want that configurables searches can activate it.

I'm assuming (maybe wrongly) that the complexity of the implementation is to add a few items to the interface (to let the user choice between search centers), and that the search algorithm uses the same code as always, but just using another coordinates for the center.

[biodranik]

It is straightforward to replicate another OSMand by building complex things. Making it easier for everyone is more tricky.

[muralito]

:-) you make me check OSMand...

I have not used it in a long time, but I see that it has implemented a search with tree mayor tabs. "History" and "Categories" like OM, and a third one, "Addresses", and it solves the problem seen in #7616 guiding the user to choose city, street, and housenumber, in the same steps as the Nuvi interface.

Obviously a third tab would not be necessary if OM had the ability to recognize an address typed by the user, and obtain the search components to find good results. Anyway, since the input is so dependent on territories or languages, a guided search with these steps is a way to let the user find what he is looking for. A guided input also avoids typos in the user input. Sometimes the user doesn't know the exact spelling of a city or street name.

OSMand is overcomplicated, I prefer to use OM, and OM should not replicate it, but strictly in this search issue, it solves the need to locate an address reasonably well, and OM sometimes fails (in some cases it recognizes/find an address, mostly with addresses in the same city as you are, and in others not, in particular if fails when searching for addresses in another city)

[pastk]

And if you don't want to add a complexity to the "standard" UI, just put an configurable setting, that users can choice "Show advanced search" "yes/no", so users that want that configurables searches can activate it.

This might be an option indeed.
Though this your suggestion looks like an easier "hidden" option for advanced users:

And the user could switch to the other distance clicking in the distance itself

Note that besides extra UI complexity and required implementation effort, there is an ongoing maintenance of expanded code and handling of users' support queries..

That being said, if someone will contribute an implemented PR then I see no problem to beta test it and gather real feedback. Maybe people will love it? But a potential contributor need to be prepared there is a chance it won't be accepted..