I would like to understand what algorithm is used to calculate time to destination as this is always extremely optimistic. I can only assume that it continuously calculates based on zero delays and maximum road speed which is not what happens in the real world. I have tried reworking the vehicle profiles but to no avail. I have tried reworking the vehicle profiles to give a more realistic time but these do not appear to affect the app (Android).
That is strange - I just tested it in PCnav, where I have 15km route via yellow "Local connecting road". When I changed the speed (extra urban) to half I got double time in itinerary??
Note, there are two basic speeds: average and speed limit. In OSM data there are only speed limits so the average is "guessed" based on speed limit (if available) and road type.
In TomTom data the speed average should significantly improve with release of version 14.
I recently completed a journey from Ledbury, UK to Bnin, Poland over 3 days and no matter how I tried to change the time to destination, it was always wrong at the end of the journey by a significant amount (underestimating the time). Surely, the algorithm should also take into account actual driving speeds once the journey has started.
I have just compared Navigator with Via Michelin for the same route and via gives a total time of 2h 17mins whereas Navigator gives 1hr 48mins (and that with slower speeds as set by me) so something is obviously wrong. Maybe it's the maps used but would like to know for sure.
Sorry I haven't responded sooner but have been away. Try navigating from HR82FU to DE61QU using both Navigator OSM and any other app. I know they aren't using the same maps but the times should still be similar. This is only a short journey. The time differences are very significant for longer ones. My trip to Poland meant that I had an extended time traveling on the 2nd day and would have split into 3 had I known the real journey time.
I just discussed it yesterday with a friend who very regularly uses MFN and found the calculation of MFN too optimistic to.
In now created an additional car profile based on the existing car profile und reduced the speeds for each and any road there to something hopefully more realistic. The preset values there are mainly max speeds.
That means, that I reduced all speeds within a city to about 25 km/h (preset 50). Highway speed reduced to 100 km/h (from 130 km/h). And so forth.
Having done this MFN calculates a substantially longer (more realistic) travel time for the modified car profile (50 min on a 380km distance). Its very easy to compare if you let MFN recalculate the route just using the two different car profices. To my surprise the profiles calculated different routes on parts of the journey.
So the solution may be to adjust the profile speeds quite substantially and not by minor margins. Hopefully this helps.
I have also seen MFN substantially underestimate the times it takes to travel.
E.g. the following route in Colorado, USA http://osrm.at/80r, MFN estimates 33 minutes, where as the same route in OSRM (also using OSM data) gives an estimate of 52 minutes, which is much closer to the time it actually takes to traval that route.
I haven't adjusted the speed profiles, so this is with the default car profile.
I give up. I have tried reducing the speed significantly in the profile but still get far too much of a discrepancy in the time. The maps can't be that much out!
For me it works well (on PC and WinCE). Although it isa bitconfusingwhat is meant byspeed limits. Legal limits or limits of a driver :)? How it is used by application? What is the meaning of checkbox 'Use speed limits'? In version11 were given 'speed limit' and 'average speed', which is stillalso indicatedin the manual forversion 12! Is this just a mistake in the manual?
I just repeated it with two other OSM based Android navigation apps for the mentioned postcodes: 2:03 2:09
So it is not a map problem. It is a navigator issue although all calculate shorter times than TomTom (which could also mean that Tomtom is too conservative)