I think I have found an issue with the estimated travel time calculated by Kurviger.
I read this documentation, and couldn’t find anything regarding this issue, or travel time estimation in general.
This issue appears to be most prevalent when using the fastest available setting.
Route 1 below, when set to the fastest available option, provides a travel time estimate of ~6-6.5 hours in Kurviger when in reality, they are closer to 4.5 hours.
Route 2 estimates 2.5 and ~2 hours for Kurviger (fastest available) and GMaps respectively.
For the two examples provided below, the estimate provided by GMaps is accurate (or at least very close). The route I drove yesterday (similar to route 1) was generated with the extra curvy setting, which provides an estimate of ~10 hours. This estimate proved to be much more accurate, although with the stops I made along the way, it is a bit hard to say for certain. My best guesses are that the speed limits in the OSM database for these sections of the interstate are incorrect, or there is some kind of global max speed.
There are a few different things to consider in this case.
Especially for high speed roads like motorways, Google has a lot of data, including statistical data for travel times and usually they are very accurate with this.
Kurviger uses data from OpenStreetMap, we don’t have statistical or live traffic data. So travel times can differ significantly.
I have added these samples to our todo list to double check and see what we can do about improving the ETA for these routes. We are constantly improving our ETA calculations, but these changes typically take a bit of time and a lot of testing, so I hope you can understand that this is not something we can change short-term.
I compared two long sections. It seems that
gmaps calculates with quite exact 70 mph, while graphhopper/kurviger with quite exact 50 mph on motorways. I double checked on the graphhopper page, result as in kurviger.
I am getting wildly inflated drive times from Kurviger (website interface)
There seems to be two issues:
a) Kurviger does not seem comprehend the speed limits of the roads so drive times are estimated too long.
b) kurviger does not seem to know how to use ramps that connect highways leading to poor route choices
to demonstate both issues issues
here are the GPS of two gas stations each near connecting highyways.
start…: 40.89968,-81.437487
finish…: 41.876007,-80.765564
Plug the above into:
google maps… 96.50 miles 1hr 27min Google Maps
Kurviger (fastest route)… 96.75 miles 2hr 15min https://kurv.gr/Twe4W
Kurviger (Fastest route w ramp hint… 96.61 miles 2hr 14min https://kurv.gr/dmHRR
The above issue is from the first leg of last weekends 1700Km event.
Everyone who completed within 24 hrs got tee-shirt,pin,patch
per Google the estimate was:
part 1 of 3) 437mi 7:45 Google Maps
part 2 of 3) 438mi 8:38 Google Maps
part 3 of 3) 189mi 2:59 Google Maps
totals…1064mi 19:22 (leaving 4.5 hrs for getting lost/gas/breaks)
per Kurviger…1068mi 25 hrs (leaving negative time for getting lost/gas/breaks)
turns out google was right actual drive time was 18:50 hrs
(we lost quite bit of time and had to speed at end to make sure we completed in 24 hrs
had we not lost time then the 19.x hours estimate without speeding would have been correct) REVER Ride 11/06/23 – REVER
I find that the app is too conservative when it comes to estimating the time of arrival. This is when driving on highways in norway.
I understand that this is a complicated topic and one estimate for the same type of road can be good in one country and bad in another. And without live traffic it will never be 100%.
Still I think that the app can improve by learning. I dont see an improvement if I drive the same route multiple times.
E.g. can the app take into account previous trips of the driver? Or can the app store in my profile at what speed I normally drive on different types of roads? Thanks for the great support.
Hi Herman, you’re right “learning” would be a cool feature, but this is a non-trivial problem in computer science and I guess google has tens of thousands of employees for a reason
We have it on our to-do list to look into the arrival time issue, as mentioned above
In the meantime, if you have any test routes for us to add into our collection (where you can tell us how long it actually took) then please do send them