OSRM: Zoom level 14 causes loss of precision for very close-by locations

[mmd-osm]

Please compare the following two OSRM routing results for the same start/end location:

• OSRM routing result on OSRM project site

• OSRM routing result on OSM web site

Issue: while the OSM website calls OSRM router with zoom level 14, the OSRM project site on map.project-osrm.org calls the OSRM router a second time with zoom level 18. By using zoom level 18, the routing results look more reasonable and in this specific case avoid a navigation right through a playground via car.

If you watch very closely, map.project-osrm.org actually triggers 2 routing calls: one with zoom level 14 and a second one with zoom level 18. I guess this additional step is somehow triggered if objects are very close to each other. I would assume that a similar logic needs to be put in to place on osm.org as well, to get similar results.

Just for clarification: when I talk about zoom level, I actually refer to the parameter z= in the viaroute call, like in the following example: /viaroute?z=14&output=json&instructions=true&loc=51.85956%2C6.50017&loc=51.85939%2C6.49886

This topic was originally discussed on the German OSM forum

[tomhughes]

They offer an API and we use it. We really shouldn't have to try and guess and re-call it with different parameters based on something that you can't even describe clearly.

This sounds like an issue that should be fixed upstream in OSRM.

[mmd-osm]

I'd like to ask you to reopen this ticket and further evaluate this topic for the following reasons:

• http://map.project-osrm.org already has some client side javascript code to deal with this situation. This site is just another consumer of the OSRM backend viaroute call, like osm.org.
• The OSRM server component works as expected here, limiting the precision of the route via the z= parameter is a feature rather than a bug and is also described in the OSRM API documentation.

To my understanding, this is not an upstream issue, but simply a not quite perfect implementation of viaroute calls on the osm.org part. If additional input is needed, I would suggest to contact the OSRM project for additional support.

To me it looks like, the osm.org site is always using z=14 as a hard-coded value, whereas map.project-osrm.org passes the current map.zoomLevel back to the OSRM backend and triggers a second viaroute call, after the map extent has been adjusted to the current routing result. Maybe just take a look at that site and watch the XHR calls in Firebug to get a better understanding how this works.

I think it might be an option to trigger that second viaroute call, if the map zoom level is > 14 - simply to have more precise routing instructions and avoid the situation outlined in my second screenshot.

I hope I somehow got the idea across. Thanks for considering this.

[tomhughes]

Well if you could actually explain what it is you want, and why you think it is the correct solution then we could consider it, but currently you proposal amounts to "if unspecified thing happens retry at higher zoom".

Before we can even consider it we need a definition of what the trigger condition is.

Even better would be to understand what the problem is and why retrying at high zoom fixes it so that we can consider if there is a better solution.

If we wanted to just copy what the OSRM site does then we would just have used their code in the first place rather than writing our own.

[mmd-osm]

Yes, sorry, you're right. I somehow got a bit carried away with lots of details. Let's try a fresh start and focus on the issue first, which has been raised by a newbie on the OSM forum.

In his words:

When I calculate a route on osm.org from:

• 1, Mersmannstraße, Bocholt, Kreis Borken, Regierungsbezirk Münster, Nordrhein-Westfalen, 46399, Deutschland

to

• 6, Die Liene, Bocholt, Kreis Borken, Regierungsbezirk Münster, Nordrhein-Westfalen, 46399, Deutschland

OSRM will route me through a playground. here's the link to osm.org.

Next thing I did was to check the same route on the OSRM Project site: here's the link

And then magic happens: osm.org did get it wrong: it presented a car route right through the playground, whereas map.project-osrm.org showed the proper route, avoiding the playground. See both screenshots I posted above.

That's basically the issue. (let's start with that for the time being, without talking about possible solutions or any implementation details yet).

Do you buy this story so far? If not, what exactly is still unclear to you? Take your time to visit both links and compare the results. That's essential to understand the issue, imho.

[tomhughes]

It hasn't actually "routed through the playground" actually. The route, as described, is to follow "Die Liene" it's just that because that name continues around a right angled corner it regards it as a single segment and hence when it simplifies the graphical version of the route (as it does at lower z values) it treats that as a single segment in the graphical rendering.

So the real solution is that OSRM should realise that at a four way junction with three roads called "Die Liene" like that and a 90 degree turn that it really ought to treat that as a turn to be announced, which would also fix the rendering.

The solution for us is probably just to use a larger Z value - if that is supposed to be the zoom (what does the OSRM doco say?) then why are we always passing 14 there?

I don't see some attempt to refetch at higher Z as a sensible solution, especially as you still haven't managed to say what the criteria should be for making that decision...

[systemed]

osm.org specifies a constant zoom level of 14 because OSRM is more likely to find a route that way: https://github.com/Project-OSRM/osrm-backend/blob/develop/data_structures/static_rtree.hpp#L580

At z15 and above, OSRM will potentially snap your start/end co-ordinates onto a "tiny component", i.e. a small, unconnected piece of routing graph from where you can't route anywhere else. At z14 and below, tiny components are ignored.

You could take the view that tiny components are actually useful for debugging routing errors in OSM, of course, but weighed against that is the consistently worse user experience when a significant proportion of routing queries fail.

I thought that there was a plan to break out the "tiny components" detection into a separate parameter, but looking at the OSRM source it still appears to be hardcoded to z<=14.

[danpat]

As usual with OSRM, things are more complicated than that :-)

Calls to /viaroute use this logic for tiny components:

https://github.com/Project-OSRM/osrm-backend/blob/develop/plugins/viaroute.hpp#L125-L155

That logic was added in Dec 2014, so it might be newer than osm.org's decision to use Z14.

Anyway, long story short, calls to /viaroute will attempt to select common connected networks for potential viapoint snapping, the z= parameter doesn't affect it at all. There is no reason for osm.org to stick to z=14 any more, except for the bandwidth savings achieved by line simplification that adding a z= parameter triggers.

The /locate plugin still uses the method that @systemed referred to, but /viaroute does not.

[systemed]

Aha, that's good.

That logic was added in Dec 2014, so it might be newer than osm.org's decision to use Z14.

Indeed - the initial PR for routing on osm.org was in March 2014: #716 .

Thinking it through today, I'm still sceptical about rerequesting whenever the user zooms, but I wonder if osm.org should perhaps select zoom level based on great-circle distance between start and end points: z14 is probably a reasonable default for a trans-America route, z18 is probably good for home-to-shops. A compromise, yes, but perhaps a reasonable one.

[mmd-osm]

Thanks everyone for your feedback on this issue! The proposal made by @systemed sounds indeed plausible to me. Maybe this is even better than constantly recalculating routes when zooming. The best threshold distance for switching between different z= levels might need a bit of trial and error, though.

Now that the ticket is still somehow in status closed, I wonder how to proceed from here.

[tomhughes]

Personally I don't see a problem with rerequesting on zoom (other than that it's a bit of a pain to do) as OSRM is nice and fast.

[mmd-osm]

With the introduction of a new OSRM API version in August 2016, this issue no longer occurs. Closing.