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

Graf Geo shared this problem 5 months ago
Known

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

https://forum.locusmap.eu/index.php?topic=7362.0

https://forum.locusmap.eu/index.php?topic=7328.0


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 (14)

photo
0

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

photo
1

Hello,

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.

photo
1

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.

photo
1

@freischneider:

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.

photo
1

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

How or where can I do this?

photo
photo
1

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.

photo
1

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

photo
1

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:

10km_Kraemerwald_LM4_Routenplaner_editiert.gpx

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.

photo
1

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 ...

photo
1

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!

/6d1118186b32bb0a1793aedc281fdf7f

photo
1

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.

photo
1

Hello,

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 web.locusmap.app). 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?

photo
1

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).

photo
1

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 http://www.DeepL.com/Translator (free version)

photo
1

Hello,

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 ...

photo
1

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.

Leave a Comment
 
Attach a file