Mismatch in route shown on maps and the api for same locations

I just started using v2 of the api. I’m looking at the routing information between
[[77.6415833,12.9117682],[77.6783283,13.3697002]] (lng,lat) for profile “driving-car”.

This is the API request I made :

For which I received this route :

However for the same two locations, maps shows a very different route which seems more correct.


On further examination, If I set profile as “driving-hgv” for the api then I receive the same route as shown on the maps.

Is this a bug or am I missing some parameter in the API?


Hi @abhiank,

this has nothing to do with different API versions, but with the fact that you did not request the exact same route.
If you use maps on the right coordinates, it produces the same result as the api : https://maps.openrouteservice.org/directions?n1=13.141987&n2=77.712401&n3=11&a=12.911768,77.641583,13.3697,77.678328&b=0&c=2&k1=en-US&k2=km

Best, Amandus

Hi @amandus, Thanks for the prompt reply.

I do see my mistake. The coordinates were not the same. However, I have a follow up question. The difference in distance between those points is just about a km or so, but the route returned is massively different in terms of path and distance. Why is that so?

For eg. consider these two:


What can I change in the api params so that both start locations provide similar results? Sorry if my question is vague.


As you are requesting the fastest route, even a tiny distance between the start points could change the outcome and distance of a route massively.
This is due to different speed limits for different roads. Using a motorway you can travel a great distance in a very short time which explaines the difference in distance.

Currently we offer no feature like “prefer motorways”. You could add a waypoint on the street you want to use like

Ah I understand it now. From some more experimentation, I found that using “shortest” was giving consistent results since it does not take into consideration the road speed limits.

Thanks for your help @amandus.