The ETA calculation in LM4 gives nonsensical results and is inconsistent.

Graf Geo shared this problem 3 years ago
In Progress

The topic has already been discussed in the German-speaking forum and under "Trouble and Questions" with many examples and files:

The ETA calculation does not work properly. First of all, much too low times are estimated for a certain distance. This affects navigation to a destination and, to a worse extent, track navigation. It is unclear when and how Locus uses actual speeds.

I often walk (and cycle) using a route previously created with the route planner and like to be navigated along it. So I use the track navigation. But I don't understand the "system" that calculates the remaining time or estimated time of arrival.

What I expect: I open any route with e.g. 20 km route length and start the navigation in "walking" mode. The arrival time is first calculated with a realistic value, (approx. 4-4.5 km/h). This is a fixed value or ideally an average value of my previous walking speed. After a short walking time, the actual speed is taken into account and the ETA is continuously adjusted accordingly. In my opinion, other navigation systems, e.g. for cars, work like this and many simpler map apps also manage this. Locus does not.

It is absolutely incomprehensible how Logos calculates the times. After several walks, Locus had recently calculated realistic times for me and I thought Locus had now "learned" my actual pace.

This afternoon I went for a walk of aprox. 9 km, navigated several short routes and the ETA times were always correct. Along the way I recorded the entire route. Then I cycled another 4 km, but without navigation.

After that, suddenly completely nonsensical times are calculated again (5 km route - 0:32 h). For the same route created and saved with the route planner, which was still calculated correctly this morning with 1h:04m.

The ETA calculation is an important basic function in navigation and should work reliably. At the moment, this is absolutely not the case.

Furthermore, I noticed that routes created with the web planner get a timestamp for each coordinate (for whatever reason and wherever it comes from).

But not with the app in the route planner. (You can see this when you export the respective route as a gpx file.

The ETA calculated for the route created with the web planner is thus displayed completely differently (in some cases completely unrealistically) than for the exact same route created with the route planner.

In my opinion, a route should always be calculated as I start the navigation.

I.e. in walking mode with my average walking speed, when hiking with my average hiking speed, etc. and not according to any timestamps stored in the track.

How does Locus calculate the ETA? What information and individual parameters are used? How is an individual speed determined? Only during navigation or also during track recording?

The entire ETA calculation is an black box and currently non-transparent, inconclusive and sometimes delivers completely unrealistic results.

Replies (17)


Supplement: You can see it immediately in the route planner, time calculation ist absolutely unrealistic. See Screenshot



firstly thanks for the post. I've changed the private ticket to the public topic so more people may involve here.

How this works since app 4.1

Integrated and also online LoRouter now supplies estimated times for planned routes based on the selected profile. Compare to older app versions, there should be no kind of personalization for now. So values returned by the LoRouter are always used without any modifications.

In older versions, there was some kind of inner logic (still used under some circumnutation), but it is not reliable at all, trust me.

So firstly, give me please start/end coordinates and your routing profile. I'll firstly check with @Radim Večerek , if there isn't any problem in precomputed times by LoRouter. Thanks.


The personalization of the ETA (as it has since) has advantages and disadvantages.

Advantage. The ETA is adjusted according to my personal speed.

Disadvantage: If I have a day on which I am traveling significantly faster or slower (e.g. I have children with me or a very sporty person who always lets me be a little faster). In this case, the times are not correct.

I think you should have different profiles for MTB, hiking, about 2-3 pieces each. I can store speed in every profile.



But that should be exactly the point: The ETA should adapt to the actual speed during the tour. So I start a 10 km tour, ETA is first calculated with a sensible initial value (e.g. "walking" 4 km/h) and then estimated at 2.5 hours. If I then walk only 3 km/h for the first kilometre, the elapsed time is increased accordingly. If I then walk faster again, it is reduced accordingly. If I take a break, the time is added accordingly. In my opinion, car navigation systems also do this.


Again @freeischneider: "I can store speed in every profile."

How or where can I do this?


Hello Menion,

first of all you are right, the ticket should of course be public. Sorry.

More information about the problem:

The main problem seems to be the ETA calculation with the route planner in the Locus app.

It doesn't matter which service I choose (LoRouter, BRouter, GraphHopper, online/offline). And it always affects the "walking" and "hiking" modes.

GraphHopper: I can choose between "walking" and "hiking" (no profiles).

BRouter: I can choose between "Walking" and "Hiking". In "Walking" I have set profile "shortest", in "Hiking" it is "Trekking-Fast".

LoRouter offline: Walking": "shortest", "Hiking": "LoHiking".

LoRouter online: Walking", "Hiking": no other settings are offered.

It doesn't matter what I use, LM4 currently always calculates the same (unrealistic) ETA in the route planner: approx. 6m:40s per km. (e.g. 5 km: 32m:30s).

Of course, the modes and profiles provide different routes, but always the same ETA.

For example, I plan a route with a length of 10 km, the route planner gives 1h:05m. I save the route and the track navigation also gives 1h:05m.

If I create the same 10-km route with the web planner, it calculates 2 hours in the web planner. So about 5 km/h - a bit fast, but at least not completely unrealistic.

If I synchronise and then navigate this route with LM4 (track navigation), 2h:32m is calculated (approx. 4 km/h).

(Normal navigation from GPS position to any destination also provides ETA on the basis of approx. 5 km/h).

If I import an external track (GPX file e.g. from Rother Verlag) and start the track navigation, a realistic ETA is calculated (3h:40m for 15.4 km = 4.2 km/h).

I can sometimes see that when setting an intermediate point, a sensible value is displayed very briefly (< 0.1 sec), but this is immediately changed to an unrealistic value.

Attached are 4 gpx files, 5 km and 10 km long:

Both routes were created once with the Route Planner and once with the Web Planner. (The file names should be self-explanatory).

The 5-km routes are calculated as follows in my track navigation:

Route planner: 32m:46s, Web planner: 1h:11m.

The 10-km routes are calculated as follows for track navigation:

Route planner: 1h:05m, Web planner: 2h:23m.

The routes created with the web planner have time stamps for each coordinate, those created with the route planner do not. Why?

Again the information: after I did 3 longer hikes with track navigation at the weekend, the ETA was calculated increasingly realistically and fitted quite well in the end.

Yesterday evening, however, the nonsensical ETA was suddenly calculated again, without me being able to explain it.

If further information is needed, please let me know.


One more comment: Route Planner with manual mode (straight line between waypoints) calculates with ca. 4.2 km/h.


Sorry for the constant supplementary posts, but I keep trying around and I have now noticed the following:

As described, a route created with the route planner will calculate the ETA incorrectly (approx. 9.8 km/h) during track navigation.

If I export the route, then in the GPX file in the header just this line delete:

  • <locus:rteComputeType>3</locus:rteComputeType>

Then save and import the GPX file again, the track navigation calculates a reasonable ETA (2h:23m for the 10 km, approx. 4.2 km/h).

I edited this previously uploaded GPX file (10km_Kraemerwald_LM4_Routenplaner.gpx) to:


EDIT: Export as GMX v1.0 (instead of GMX v1.1 like I did before) - Here it is not necessary to edit the file. After the re-import, a reasonable 4.2 km/h is estimated for ETA.

But if I modify the imported track in the route planner, even minimally, then a nonsensical time is immediately recalculated for the entire route.


After I didn't know what else to do, I have now completely reinstalled LM4. After everything was finally set up as usual, I could test the route planner again.

Now 3.6 km/h are used for the ETA calculation in the walking and hiking modes. So much too slow.

I wonder if LM4 dices these values. :)

Is it not possible to store realistic values?

E.g. 4.2 km/h for walking, 4.5 km/h for hiking.

Routes created with the web planner are calculated even slower during track navigation: 3.1 km/h

(20 km 6:25 hours)

Web planner itself: 4:01 hours

Everything goes completely wrong ...


I was surprised that more people do not complain after app update. And now I know why. You use a route planner to compute navigation routes, but you do not use navigation points! You simply compute routes without these points right? But these points are bearers of a lot better time estimates so without them, the app uses the same old logic as before, nothing has changed in this case. What happens to you is the result of the unreliable old system that I now try to change!!

And how this old system works? App register average moving time for the last cca 1 hour, based on the route type you navigate along. It registers three categories: walk, bike, car. But, if you plan a route with cycle profile and then use it for walking, the result will be wrong time estimates when you next time plan the cycle route.

So please, give a try and use navigation commands in the app!



Hello Menion,

thanks for your answer and the explanations.

That's right, I usually create routes without navigation points, because they always annoyed me on the map and the track instructions that Locus generates during track navigation are absolutely ok for me. Recently, you can hide the navigation instructions in the settings, so I will be happy to plan routes with navigation points in the future.

1. You write that the old system takes into account the average movement time of the last approx. 1 hour. Is only the movement time during a navigation taken into account, or also during a track recording?

I have a suspicion that the track recording is also taken into account, but I will check this. In principle, I quite like the system, if it would work reliably like this.

2. Now I have tried route planning with navigation points (as in your screenshot), but the results are even worse and more illogical!

Here is the comparison with the always exactly the same 10 km route ("walking" mode):

  • without navigation points: 2:03:18
  • with navigation points, 2 shaping points (clicks, green triangles) only start and finish: 2:00:34
  • with 5 further shaping points: 1:38:51
  • with 10 more shaping points: 1:10:42

The more shaping points I use when planning the exact same route, the shorter the ETA is calculated. That is absolute nonsense!

The same thing happens in cycling mode (always the same route):

  • 10 km without navigation points: 41m:54s
  • 10 km with navigation points, (5 shaping points incl. start/finish): 29m:24s
  • 10 km with navigation points, (12 shaping points incl. start/finish): 25m:26s

3. GPX file: For routes created with navigation points (whether web planner or route planner), GPX files with timestamps for each individual coordinate are written during export. For routes that were created without navigation points, no timestamps are entered either. Right?

The timestamps obviously correspond to the times when the route was created. Once these are wrong, the navigation along this route will always take these wrong times into account. This is bad.

I still maintain that the ETA calculation is opaque and does not provide reliably realistic results. Especially the results for routes with navigation points are more than strange...

I will continue to test and observe, but from current experience I get more realistic results with routes without navigation points.



1. average speed is computed when you have active navigation (then this navigation defines if you are walking, cycling, or riding a car) or when you have active track recording (then recording profile defines the type of activity).

2. 10 km route, computed by LoRouter (online, offline) should always give the same results, no matter if you use the app or web planner (at So, may you please plan a route on the web and share it with me so I can check why times are incorrect? Thanks.

3. I'm not aware that the app writes timestamps to trackpoints. This is really unexpected and if this happens, it has to be an issue. How should I simulate this behavior?


How should I simulate this behavior?

Ask the helpdesk or read the manual ? ;-) ;-) ;-)

@ GraF Geo.

According to a test in the Pro app, timestamps are also present in the track points if you export to gpx without the navigation instructions.

However, I suspect that you may run your many tests directly from internal app design data direct into the database, so without those gpx transfers playing a role? I should check again but I thought Brouter web gpx out does not contain timestamps. Instructions in the navigation waypoints are provided by the Locus extension, so no need for tight time association in that Brouter web gpx out transfer file.

No ?

If you think that timestamps provided with a gpx import play a strange role for your estimated time of arrival, you might be able to also run a gpx import from www.plotaroute website planner ?

Always is a gpx export by the full association (position and timestamps) between gpx trackpoints and the navigation waypoints. And I think the timestamps applied there are quite accurate for the selected activity.

By the way Plotaroute also generate tcx exports. Always has full association by the standard. (Garmin).


Thank you Menion for the explanations!

Re 1: Ok, then I can confirm this to some extent. For me, this is a useful calculation, I just have to remember to finish a recording after a hike before I get on the bus or train. 😊

To 2 and 3: Please have a look at the attached PDF and the gpx files. I have tried to describe the problems in detail with numerous screenshots, so I think the inconsistencies should become clear.

The 4 GPX files:

Tour created with the web planner (mode: walking): 7,72 km, 5 Waypoints

Length. 7.72 km, time: 1:32 Export from Webplaner: lietzensee_webplanner_5Zwp.gpx

File contains 5 waypoints with timestamps, all other trackpoints without timestamps.

After synchronisation and opening the tour in LM4:

Route contains navigation instructions.

Export from LM4: Lietzensee_webplanner_5Zwp_2.gpx

All trackpoints have timestamps!

Then I create the exact same route with the route planner in LM4. LoRouter offline, mode "walking", profile LoWalking, without navigation commands. The route corresponds as closely as possible to the route I previously created with the web planner.

Length. 7.7 km, time: 1:26:19 (6 minutes less than in the web planner!)

Export from LM4: Lietzensee_LM4_5Zwp.gpx

Trackpoints without timestamp.

Recalculation of the route with LM4 with navigation commands:

Length. 7.7 km, time: 1:23:56 (again 3 minutes less).

Export from LM4: Lietzensee_LM4_5Zwp_NP.gpx

All trackpoints with timestamp!

Translated with (free version)



I had already written a long answer and by accident, it was removed, damn ... so again ...

Firstly thanks for the nice PDF, appreciate the time you've invested into it.

I see there a few problems:

  1. track exported from the web planner as GPX has a time attached to waypoints: reported to Ondřej (the guy behind the web), he will look at it.
  2. track with navigation instructions exported from LM has a time attached to trackpoints: this is the result of the old tool that generated times for some Garmin devices
  3. app does not correctly compute times for segments without navigation instructions

Generally, computed times are not reliable, agree.

What may be done on the app side better:

  1. always use times computed by the router. In case, there is no navigation command, find a method to keep valid time in all cases
  2. allow to define reliable fallback "time compute" method in cases, you draw a route manually (without any router) or for imported routes
  3. optionally create some system where the app may learn how you as a user walk/ride etc compare to computed times by the router and modify these times a little bit to match reality better

Hmm, quite a complex task ...


Hi Menion, thanks for the reply and for acknowledging the unreliability.

I am not a programmer and cannot estimate the effort of an improvement.

Suggestion: Please keep the simple system at least as an option (planning without navigation command): … App registers average moving time for the last cca 1 hour, based on the route type you navigate along. It registers three categories: walk, bike, car. But, if you plan a route with cycle profile and then use it for walking, the result will be wrong time estimates when you next time plan the cycle route

For flat and slightly hilly terrain, this is sufficient for my needs.

Perhaps a fourth category "running/jogging" could be implemented.

Maybe the option to be able to use this simple system also for planning with navigation commands would be useful. Simply set the average speed in relation to the remaining distance. Better a halfway plausible result than a completely unrealistic one.

Alternatively, it would be practical to be able to set an initial speed, during the tour the actual speed should then be used to update the calculation.

For tour planning in mountainous terrain, it would make sense to use a correction for gradients and steep descents, as plotaroute does, for example.

I don't understand why it is calculated differently when planning a route with or without navigation instructions. I don't run faster or slower just because navigation instructions are available.

For the time being, I will continue to use route planning without navigation commands. I can live with that. Especially as I cannot see any difference in the quality of the navigation commands if they are created immediately during planning or later during track navigation.


I'm love Locus Maps and I'm happy to pay for Gold subscription... but it's really annoying that there is no solution for the ETA issue. Also for me the ETA is usually far to low. :-(

I'm using the Offline LoRouter with custom routing profile and GPX tracks that have been planned by external tools. I always record tracks.

Example: In the attached file you see on the left that the average speed overall and in motion in 17,5 km/h ("Tempo / Tempodurchschn.(Bewegung)"), i.e. I did not make a break yet. On the right you see that there are still 20,5 km to go ("Entfernung bis zum Ziel"); i.e. if I continue with the same speed I would definitely need more than an hour, but it predicts less than 24 minutes ("Zeit bis zum Ziel"). Ridiculous! I will need about 3-times 24 minutes!

I think we need a setting so that users can choose how the ETA should be calculated; e.g.

  • Based on average speed in motion (without breaks). - Useful if you don't plan for breaks anymore or breaks are usually very short. - My favorite!
  • Based on average overall speed (incl. breaks). - Especially useful for long tours where you probably make regular breaks for eating/drinking etc.
  • Based on timestamps/speed in GPX file (if available). -- Works quite well if it's a recorded track with real value, but not if it's planned... or from somebody else that goes faster or slower than you or makes more or less breaks.
  • Based on estimations of routing engine and selected profile. -- Is that what we have now? Does not seem to work too well.
  • Of course, more sophisticated methods like long-time observation of my personal speed (per profile) in relation to current % of slope, could be implemented, but for the time being I would be happy with much more simple mechanisms as described above.

Personally, I would really appreciate calculation based on speed in motion (and optionally speed in motion) of the current track recording. Should be a quite easy solution to implement, shouldn't it?

Looking forward to a solution!

Thanks in advance.

Kind regards,



Hello guys,

old topic I would like to resurrect a little.

During the last months, Radim made significant changes in the computing of the routing times for online and offline LoRouter. Values are now united for them and also for the Android & the Web platform. So you should now get identical times no matter what you use (external BRouter and GraphHopper lives own lives ...).

This topic was a lot about computing time estimates when "not using navigation points". I consider this as a minor use-case. The question is if it makes sense at all.

For now, I would appreciate confirmation, that time estimates make sense and are useful. Thanks.


Hm. In flat areas, the route planner in the LM4 app and the web planner (both LoRouter) always calculate 5 km/h for the planned route, which is too fast in my opinion.

In the mountains (Alps) I have a small deviation: 5 km and 725 metres in altitude with the app 2:00 h and with the web planner 1:52 h. Exactly the same route, both with the hiking profile.

In the app, it doesn't matter whether I plan with or without navigation instructions. Both calculate 2:00.

For me personally, planning without navigation instructions is more suitable, as it adapts to the actual speed you are walking at and calculates a realistic target time. This applies to flat and hilly terrain. Of course, if there is a steep climb at the end of the route, it no longer fits. I then have to take that into account myself.

I haven't tested a route planned with navigation instructions on the way, so I can't say anything about it at the moment. Maybe I'll do that when I'm back in the mountains.

Translated with deepL

Leave a Comment
Attach a file