Routing difference between GraphHopper and ORS

openrouteservice
1

Hi everyone, thanks for this awesome tool.

I know that ORS is developed under GraphHopper routing library. But comparing those two heavy truck queries, i founded approximately the same distance but with a difference of two hours driving!

https://maps.openrouteservice.org/directions?n1=48.4184&n2=2.284057&n3=7&a=50.632786,3.059524,43.603902,1.440694&b=4a&c=0&k1=en-US&k2=km

https://graphhopper.com/maps/?point=50.635635%2C3.063008&point=43.605637%2C1.448693&locale=en-US&vehicle=truck&weighting=fastest&elevation=true&use_miles=false&layer=OpenStreetMap

Why am i having this difference and how can i have the same results please?

Thanks in advance!

2

Hi hamzaerhaiem,

The travel time is calculated for each segment by using speed-limits for different waytypes [see Travel Time Calculation] (https://github.com/GIScience/openrouteservice-docs).
The reason why both queries output a different driving time is that the ORS determines different speed-limits to the ways.

Best Tahira

1 Like
3

Thanks for your answer, is there a way to change those speed limits before depolying my docker image so they can fit OSM?

Best Hamza

4

According to GitHub, OpenRouteService was forked from GraphHopper 0.10 which in turn had been released in March, 2018. Both their source code and their driving profile parameters are different. Likewise, their map data is most likely not from the same date. Do you think that can affect the result too?

5

Thanks for your answer, is there a way to change those speed limits before depolying my docker image so they can fit OSM?

Best Hamza

6

Sure. You gotta dig into the code a bit. And it’s not super deterministic, as it depends on a lot more things than just road type.

Not so sure if this is even used these days:

This one here definitely does the job:
https://github.com/GIScience/openrouteservice/blob/master/openrouteservice/src/main/java/heigit/ors/routing/graphhopper/extensions/flagencoders/HeavyVehicleFlagEncoder.java

1 Like
7

We don’t use much of Graphhopper tbh. Mostly a few algorithms and most of the OSM Reader logic.

ALL the profile specific stuff is redone in ORS, we do not share any profile-specific code with Graphhopper.

1 Like
8

I stumbled upon this post by @hamzarhaiem by chance. I was also wondering about the crazy differences in drivetimes using the original examples:

  1. ORS says 13h32m - link
  2. Graphhopper.com gives 11h41m - link
  3. Google maps gives a range of 7 h 40 min - 10 h 20 min - link
  4. Bing maps gives 8h51m - link

These are absolutely crazy discrepancies! In my experience as a driver, Google Maps is very accurate because they use GPS traffic data (live and historic) from google mobile users to increase the accuracy of road network speed estimations.

So I guess the question is, has anyone done any testing or validation on OSM-based routing like ORS or Graphhopper? A difference of potentially 4 hours is quite striking is it not? I’m having a hard time reconciling these differences. Just saying that they use different data doesn’t go far enough - we need to know which is the most accurate. I’d be grateful if anyone could let me know what kind of validation or field testing has been carried out. Thanks

9

The main reason for the distance in the time here is that for openrouteservice and GraphHopper you are selecting the HGV profile, whereas for Google and Bing you are using the car profile. In normal circumstances (especially on highways) HGVs travel slower than cars. Changing to a car profile with the above route for openrouteservice will give you a duration of 8 h 31 min - link

In terms of validation, it is often a combination of looking at the routes generated and times and comparing them to ones from Google to make sure that in general they are similar, but of course there are circumstances where there are some large differences. We had an example in America where speeds were’nt placed on ways in OSM data, so the code had to assume a generic global speed for the road as doing spatial calculations to determine the actual country a road is in can add a lot of time to the build time of graphs. Perhaps @andrzej can give more information about testing as he has done quite a bit for various testing for features that we implement.

If you want to know which is more accurate, that is a very difficult thing to determine on a global scale. In Germany (and much of Europe) OSM data is very good so the road network coverage in openrouteservice has a pretty high accuracy. We also have a number of things that attempt to make routes and durations more realistic, but though these work well in most circumstances, there are always some where they have a more detrimental effect. Obviously, companies like Google and Bing have billions of dollars to throw at validation and tweaking algorithms, whereas openrouteservice is a small group of 4 or 5 developers. So for highly validated routing, the larger companies (Bing and Google) are normally your safest bet, whereas we try to provide more cutting edge opensource algorithms and features (e.g. avoid border crossings, prefer green areas for pedestrian) which are free to use and deploy.

1 Like