Unmatching results with OSM (Python)

I am new to ORS so maybe I am missing a point.
I would like to get the cost of traveling from A to B in terms of distance and duration. The Python code I’m using looks like this:

from openrouteservice import client
clnt = client.Client(key=api_key)
coord= [[13.372582, 52.520295], [13.391476, 52.508856]]
regular_route = clnt.directions(coordinates= coord, profile= ‘driving-car’, geometry= ‘false’)
distance, duration = regular_route[‘routes’][0][‘summary’].values()
out: distance/1000 = 4.81389, duration/60= 8.5483

However, by deploying the same coordinates in OSM I am getting these values:
Distance: 2.7km. Time: 0:06

The differences are huge. I tried different preferences to choose the route but nothing seems to help.

What is the reason for that and how can I correct it?
Thank you in advance.

Can you please put some links, i.e.


Though, the output: distance/1000 = 4.81389, duration/60= 8.5483 I get it from my python code. I didn’t test it in ORS website until you suggested so.


Now I see that ORS did a retoure but OSM didn’t. Why? the same coordinates are deployed! How can I fix that?

Too sloppy mate:

It does the right thing. When you supply coords, it depends on the service how it snaps to the roads. Millimeters can matter.

Did you change the coords of the starting point manually?

I have thousands of trips that I have to deploy. Is there anyway to turn around this problem?

Yeah, I did, because you didn’t supply the same coordinate for both sites. If you do use the exact same, you get the same results.

With ORS there’s unfortunately no way to give hints on which street you prefer, it just snaps to the closest one. The only way around it is to provide accurate coordinates. There’s a few more options like radius which constricts the radius with which it snaps coordinates, but just try around a little with the options:

I supplied the same coordinates on both sites. I used copy paste so no way they are different. However, as you said, each service snaps the coordinates differently. OSM snapped it to the street on the right but OSR on the left. I will try with the available suggested options.

Thanks for help!

Click again on both links you posted. The starting point is not the same in both links. In ORS the starting is in the center of the building, with OSM it’s in the middle of the actual road you want.

I understood you. But I supplied the same coordinates in the both services. OSM automatically snaps the coords to the middle of the road. OSR doesn’t. Try to copy paste the coordinates I have written in my question in both services and you see what I mean.

Here is another example with coords directly on the road (so the don’t have to be snapped). The suggested way for the car is alright. However, the one for the pedestrian is totally unrelaible.



I do agree here as well.

@andrzej @HendrikLeuschner, is there some hard-coded preference for side streets in pedestrian? It really feels ridiculous a little that it always sends you the much longer way on side streets. That’s what the quiet preference should be for (if it was working…).

From what I remember, we had to make it so that main roads with no sidewalk tags were marked as lower preference due to complaints from other users where the routes for pedestrians were going down main roads that were not suitable at all

Yeah that makes sense. Seems like that’s a main road but it must have a sidewalk, as there’s shops etc Too lazy to look it up.

So, @Hekdab it’s OSM fault, not ours:) Add sidewalk tags, that should get rid of this it seems.

Indeed, both cycling and walking profiles prioritize certain streets based on road class and OSM way tags. It works only as good as the underlying OSM data. As @adam pointed out, typically you wouldn’t want to send people down a busy street if there is a safer alternative.

ok, thanks guys for the rapid response