Snap to highways/cities on low-zoom placement of navigation markets

[tomFlowee]

Problem

On the website you can drag the navigation marker for routing, the from and the to.

On low zoom levels it becomes quite tricky to actually do what is expected and the market often ends up slightly off of the location you want. Basically a random location anywhere from 50 to 2000 meters from the actually wanted location.

The best known issue there is if you want to route not from an address to an address, but only roads and you drop the icon on a big multi-lane road. There is a pretty good chance you just dropped it on the lane going the opposite direction and this causes your routing to be quite different than expected.

Or if you want to route to a town, not a specific address, just from one town to another. It would make a LOT of sense to just route to the outskirts of the town and not to the exact address where I randomly dropped my marker. Because at low zoom I can't really be accurate. I use low zoom because I just want to route to the town, not a specific address.

Description

Using high zoom, the user has all the control they need.

Using low zoom, however, I think it would be nice if OSM would add snapping to big elements. Elements like highways and towns.

What I'd expect then is that if I drop my navigation marker 5 pixels left of the highway, the website assumes I wanted to hit the highway. Because at low zoom it is extremely unlikely the user was actually trying to hit that barn next to the road. And thus snaps the marker back to the main road.

In a second stap it might be nice for the communication between the OSM model and the routing services to have marker saying "this is a snapped marker!". Because that allows the routing service to assume that my marker is on the entire highway, not on one specific lane. Avoiding the silly problem of starting to route south while we wanted to drive north.. Similarly, a "snapped-to" value of a town could also be smarter routed to simply the general area of the town instead of all the way into the center where the town dot happens to be located.

Screenshots

No response

[tomhughes]

This is really something you would need to take up with the routing engines - we just send them the coordinates and it's up to them how they resolve that to a routeable object.

I know that at least some of them do in fact do exactly the sort of snapping you're referring to so if you think it's not good enough for a particular engine then you should raise an issue with that engine.

[daniel-callejas-sevilla]

we just send them the coordinates

The "we just send them the coordinates" is probably where the magic should happen (either in the website, or in the routing engine) to select target coordinates that match user intent.

some of them do in fact do exactly the sort of snapping

Could you mention an example? Thanks!

[tomhughes]

Well the web site is just working with a picture - it doesn't have any vector data to snap to and the OSM editing database is not structured in a way to make that easily possible which is why it's better to let the routers (which have a suitable database of routeable objects already) make the decision.

As far as an example goes there is https://github.com/valhalla/valhalla/issues/4419 which while it starts out being about implicit connections between footpaths and roads does go on to include a discussion of the search radius that valhalla uses when looking for the best object to route to/from.

[tomFlowee]

Well the web site is just working with a picture - it doesn't have any vector data to snap to and the OSM editing database is not structured in a way to make that easily possible which is why it's better to let the routers (which have a suitable database of routeable objects already) make the decision.

Ok, thats fair.

At the same time the routing engines don't have the information available to decide if they should snap or not. And at what accuracy. Which is where the suggestion of zoom comes in.

Let me ask this; if the usecase that is described in the bugreport is to be written, do you think it is possible without changes to the website?

And then to follow up, what kind of report could i make to the routers to make this usecase happen? It would be nice if there was a way to include what the website could do to facilitate this.

[tomhughes]

I think you're wrong about routing engines as I already explained...

OSRM's API is documented here and it has a several options like radiuses and snapping relating to matching locations to the routing graph. We don't currently set any of them.

Valhalla's API is documented here and it has a whole set of parameters like radius, rank_candidates etc that are all about how it matches locations to edges in the routing graph. The only one we currently set is radius which we set to five metres.

Graphhopper's API is documented here and although it doesn't seem to have a search radius it obviously does do snapping because it has parameters like point_hint and snap_prevention which influence the algorithm.

So it seems all three routers do in fact do some sort of snapping.

It may well be that we could tune the parameters that we pass to some of them better - if you do find better values then please do let us know and we can consider them.

[tomFlowee]

the routing engines don't have the information available to decide if they should snap or not

It may well be that we could tune the parameters that we pass to some of them better

The intent I'm going for is that the snap radius passed to them is based on the zoom level that the website is at when the user moved the marker.

Now, unless I'm completely mistaking the design here, this is knowledge that is only available to the website (well, the JavaScript) and thus has to be forwarded to the search.

That is the essence of what this bug report is about; the usecase that if you are zoomed out further, the snap radius becomes larger.

[tomhughes]

We should be able vary it with the zoom yes, at least for those backends which support an explicit search radius.

Whether that's a good idea I don't know - you really want to be zoomed in enough to see where you're putting the start and end when routing.

[tomFlowee]

Whether that's a good idea I don't know - you really want to be zoomed in enough to see where you're putting the start and end when routing.

It is good to know your normal usecase wants to be zoomed in far when you place the marker, as that means that there is no conflict between the two usecases.

In my usecase (quickly figure out a generic route or distance / duration) I really don't care if I'm too accurate. I'm going to have to have the exact details when I set it on my car GPS, but on the website I don't.

And, as the "Problem" topic in the initial report explains, this can be improved quite a bit by adding snapping.
Silly problems like the distance or time being wrong because I dropped the marker on the lane going in the opposite direction can be avoided and user confusion minimized.

Granted, maybe the search engines need some more work too, but when the osm website starts using those features that work is much easier to prioritize and thus get an overall good experience for another set of usecases.

[woodpeck]

I really don't understand why this is a problem. If I am zoomed out so that my map covers hundreds of kilometers, and i randomly click somewhere in the middle of two cities, then yes, the routing will be computed from one particular location in one city to another particular location in the other; and yes, if I happen to "snap" to the wrong side of a dual carriageway, this could mean a few kilometers detour. But what is a few kilometers when I'm looking at a distance of 100s of kilometers? One the one hand you say you expect the algorithm to somehow magically snap to a point "on the outskirts" of the place (which can easily mean 10km less), on the other hand you're concerned about going a few kilometers in the wrong direction because your random click snapped to the wrong thing.

If you're zoomed out you will get a rough estimate of the distance, if you zoom in you can request a more precise measurement. The modifications that you are suggesting will not fundamentally change this. So why bother?

[tomFlowee]

But what is a few kilometers when I'm looking at a distance of 100s of kilometers?

In mainland Europe this is more like adding 10 km to a 75km trip. It is about finding a route into a city, not about having to move the item around various times to find out if I happen to just have placed the marker on the wrong side of a canal and that changes the route. Stuff that matters for those old cities.

Not everywhere is the same in this big world.

This item has been issued as a wishlist item. If nobody wants to do it, then nobody wants to do it. But I don't think anyone disagrees that the problems (referring here to the topic-name on the main report) actually exist. And I hope that this is a smart solution that gives the most bang-for-the-buck.

Please consider reopening this.

[systemed]

I wouldn't really suggest anyone implements this now because this gets significantly easier once vector tiles are in use - you can then take the start lat/lon from the clicked feature, which will hopefully be a placename label at a node positioned with some degree of thought as to the "town centre".

Of course, if you're asking for a car route then hopefully the town centre will be closed to cars anyway ;)