The ETA calculation in LM4 gives nonsensical results and is inconsistent.
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.
The same problem 
Supplement: You can see it immediately in the route planner, time calculation ist absolutely unrealistic. See Screenshot
Supplement: You can see it immediately in the route planner, time calculation ist absolutely unrealistic. See Screenshot
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.
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.
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.
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.
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.
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.
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:
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.
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:
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.
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 ...
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!
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):
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):
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.
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):
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):
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.
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?
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?
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).
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 http://www.DeepL.com/Translator (free version)
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)
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:
Generally, computed times are not reliable, agree.
What may be done on the app side better:
Hmm, quite a complex task ...
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:
Generally, computed times are not reliable, agree.
What may be done on the app side 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.
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.
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,
-Stefan-
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.
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,
-Stefan-
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.
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
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
I'm sorry if I'm annoying you again with this topic. I'm surprised that nobody else has reported the problem.
Over the last few weeks I have been testing Locus very intensively and have also been looking at the vexed subject of ETA. I have often reported that a realistic ETA when navigating along a planned route is the big problem with Locus.
My usual use case is: I plan routes using the route planner in the Locus app. I then hike them and let the track navigation navigate me. On Menion's recommendation, I have recently mostly planned the routes with navigation instructions.
Unfortunately, I still get a much too short ETA in the majority of the planned routes. Usually about 20 to 30% too short, sometimes much worse. I have made countless attempts to get to the bottom of the cause. Because in rare cases the time fits perfectly.
My final suspicion is that there are problems if the route is planned with several shaping points. Because if I only plan the route from the state to the destination, the times usually fit well.
Example: I plan a route in the Harz Mountains from Ilsenburg up to the Brocken with only two shaping points (start - finish). That is approx. 10.8 km and 850 m uphill. The track info shows 3:42:36, which is realistic. When I start the track navigation, the time to target is 3:42:31. Perfect.
Now I plan the exact same route with several (14) shaping points. The length and elevation gain are logically the same (10.8 km and 850 m). The track info now shows 3:37:00, a little less, but ok. When I now start the track navigation, the time to target is displayed as 0:55:12, which is bullshit. Here I share both routes:
Route 1: https://link.locusmap.app/t/ko8n5zRoute 2: https://link.locusmap.app/t/xjhu7f
The same thing happens on another example route from Poppenhausen to Wasserkuppe. 6.7 km, 508 m elevation gain: Route with only 2 shaping points (start-finish): time to target 2:13:34
The same route with 6 shaping points: 1:28:44
Route 1: https://link.locusmap.app/t/uuijxm
Route 2: https://link.locusmap.app/t/r24ht4
I can easily reproduce this with any route, the ETA times are usually correct for start-finish planning and are sometimes significantly too short if several shaping points are used. But it is normal to set several shaping points when planning a route.
There are rare exceptions where the time fits despite many shaping points, but unfortunately only rarely.
What could be the reason for this, or what might I be doing wrong?
*** Translated with http://www.DeepL.com/Translator (free version) ***
I'm sorry if I'm annoying you again with this topic. I'm surprised that nobody else has reported the problem.
Over the last few weeks I have been testing Locus very intensively and have also been looking at the vexed subject of ETA. I have often reported that a realistic ETA when navigating along a planned route is the big problem with Locus.
My usual use case is: I plan routes using the route planner in the Locus app. I then hike them and let the track navigation navigate me. On Menion's recommendation, I have recently mostly planned the routes with navigation instructions.
Unfortunately, I still get a much too short ETA in the majority of the planned routes. Usually about 20 to 30% too short, sometimes much worse. I have made countless attempts to get to the bottom of the cause. Because in rare cases the time fits perfectly.
My final suspicion is that there are problems if the route is planned with several shaping points. Because if I only plan the route from the state to the destination, the times usually fit well.
Example: I plan a route in the Harz Mountains from Ilsenburg up to the Brocken with only two shaping points (start - finish). That is approx. 10.8 km and 850 m uphill. The track info shows 3:42:36, which is realistic. When I start the track navigation, the time to target is 3:42:31. Perfect.
Now I plan the exact same route with several (14) shaping points. The length and elevation gain are logically the same (10.8 km and 850 m). The track info now shows 3:37:00, a little less, but ok. When I now start the track navigation, the time to target is displayed as 0:55:12, which is bullshit. Here I share both routes:
Route 1: https://link.locusmap.app/t/ko8n5zRoute 2: https://link.locusmap.app/t/xjhu7f
The same thing happens on another example route from Poppenhausen to Wasserkuppe. 6.7 km, 508 m elevation gain: Route with only 2 shaping points (start-finish): time to target 2:13:34
The same route with 6 shaping points: 1:28:44
Route 1: https://link.locusmap.app/t/uuijxm
Route 2: https://link.locusmap.app/t/r24ht4
I can easily reproduce this with any route, the ETA times are usually correct for start-finish planning and are sometimes significantly too short if several shaping points are used. But it is normal to set several shaping points when planning a route.
There are rare exceptions where the time fits despite many shaping points, but unfortunately only rarely.
What could be the reason for this, or what might I be doing wrong?
*** Translated with http://www.DeepL.com/Translator (free version) ***
Hi,
I'm currently looking into moving from using other route planners to Locus and I came across this issue also. I get the same behaviour as Graf Geo.
This is using the Locus app (not Web), online Lorouter, all route segments using mode Hiking with flat speed 4km/h, including navigation commands. No track recording (don't know if this has any effect). There are many variables/scenarios which make it difficult to understand what is going wrong especially as the logic isn't in the user guide as far as I can see.
However there is certainly one error which looks to be fairly clear, as mentioned by Blihi earlier: "and indeed it appears as if it is not the time to the next via point, but the time to the next shaping point in the route"
Background (as I think I understand it):
------------
When plotting the route Locus calculates the time from each waypoint to the next and stores it with each waypoint. This can be seen in the exported GPX in the <extensions> data for each waypoint <locus:rteDistance> <locus:rteTime> and <locus:rteSpeed>. (this I think is stored in a BLOB binary field in the database so can't be seen directly there). It also calculates timestamps for each trackpoint (milliseconds from the start) and these can be seen in the database and in the exported GPX as times since the unix epoch (00:00 1 Jan 1970).
Not sure if the logic for these time calculations is different (trackpoints vs waypoints)
When viewing the route the "track time" is displayed from the trackpoint timestamps so a reasonable value is shown.
When navigating the route Locus instead uses the data from the waypoints to calculate the "Time to Finish", which should in theory match the trackpoint data if the waypoint times are correct.
------------
Problem (my speculation):
-------------------------
When the router is calculating the times from waypoint to waypoint if a shaping point is encountered between them then the logic has to check if the next segment is using a different mode/profile as the speed may be different. It looks like there may be a bug here in that instead it simply stops and records only the time from first waypoint to the shaping point.
To demonstrate: Plot a route with a number of NAVpoints and place shaping points immediately after every NAVpoint, as close as possible. Also start the route immediately before a junction (or maybe put a VIApoint just after start - to make the distance to first waypoint small). Then navigate it and check the "Time to Finish".
I did this for a 2.8km test route which gave a sensible "track time" of 57:28 mins:secs. (4km flat speed but it is mostly uphill)
Then navigate it: Time to finish......... 38 seconds.
Also check the waypoint <locus:rteTime> values. They are just a few seconds.
That would be an average speed of 265 km/h. I think if I tried hard enough I could probably plot a route which required a speed greater than the fastest man made object :-)
The size of the error depends heavily on the exact relationship between the waypoint and the shaping point locations, hence seemingly random variations as reported by Graf Geo.
---------------------------
Further issues:
---------------
I also see that adding shaping points affects the trackpoint timestamp calculations. I plotted a route with track time 47:54 mins secs then added 10 shaping points without altering the actual route and the "track time" reduced from 47:54 to 41:31. Don't know why but it can't be correct behaviour.
And lastly when navigating an imported route with trackpoint timestamps and waypoints, the "time to finish" also seems to be too low relative to the "track time". In this case I don't think Locus has the waypoint time/speed data , and there are no shaping points. Looks like it ignores the timestamps and uses a default speed of 5km/hr which is too fast.
Hi,
I'm currently looking into moving from using other route planners to Locus and I came across this issue also. I get the same behaviour as Graf Geo.
This is using the Locus app (not Web), online Lorouter, all route segments using mode Hiking with flat speed 4km/h, including navigation commands. No track recording (don't know if this has any effect). There are many variables/scenarios which make it difficult to understand what is going wrong especially as the logic isn't in the user guide as far as I can see.
However there is certainly one error which looks to be fairly clear, as mentioned by Blihi earlier: "and indeed it appears as if it is not the time to the next via point, but the time to the next shaping point in the route"
Background (as I think I understand it):
------------
When plotting the route Locus calculates the time from each waypoint to the next and stores it with each waypoint. This can be seen in the exported GPX in the <extensions> data for each waypoint <locus:rteDistance> <locus:rteTime> and <locus:rteSpeed>. (this I think is stored in a BLOB binary field in the database so can't be seen directly there). It also calculates timestamps for each trackpoint (milliseconds from the start) and these can be seen in the database and in the exported GPX as times since the unix epoch (00:00 1 Jan 1970).
Not sure if the logic for these time calculations is different (trackpoints vs waypoints)
When viewing the route the "track time" is displayed from the trackpoint timestamps so a reasonable value is shown.
When navigating the route Locus instead uses the data from the waypoints to calculate the "Time to Finish", which should in theory match the trackpoint data if the waypoint times are correct.
------------
Problem (my speculation):
-------------------------
When the router is calculating the times from waypoint to waypoint if a shaping point is encountered between them then the logic has to check if the next segment is using a different mode/profile as the speed may be different. It looks like there may be a bug here in that instead it simply stops and records only the time from first waypoint to the shaping point.
To demonstrate: Plot a route with a number of NAVpoints and place shaping points immediately after every NAVpoint, as close as possible. Also start the route immediately before a junction (or maybe put a VIApoint just after start - to make the distance to first waypoint small). Then navigate it and check the "Time to Finish".
I did this for a 2.8km test route which gave a sensible "track time" of 57:28 mins:secs. (4km flat speed but it is mostly uphill)
Then navigate it: Time to finish......... 38 seconds.
Also check the waypoint <locus:rteTime> values. They are just a few seconds.
That would be an average speed of 265 km/h. I think if I tried hard enough I could probably plot a route which required a speed greater than the fastest man made object :-)
The size of the error depends heavily on the exact relationship between the waypoint and the shaping point locations, hence seemingly random variations as reported by Graf Geo.
---------------------------
Further issues:
---------------
I also see that adding shaping points affects the trackpoint timestamp calculations. I plotted a route with track time 47:54 mins secs then added 10 shaping points without altering the actual route and the "track time" reduced from 47:54 to 41:31. Don't know why but it can't be correct behaviour.
And lastly when navigating an imported route with trackpoint timestamps and waypoints, the "time to finish" also seems to be too low relative to the "track time". In this case I don't think Locus has the waypoint time/speed data , and there are no shaping points. Looks like it ignores the timestamps and uses a default speed of 5km/hr which is too fast.
Hi guys,
this one was tough. Firstly thanks to Alan and Graf Geo for the excellent description and help with this. Mainly suggestion "place shaping points immediately after every NAVpoint," helped a lot, so thanks!
After almost a day of debugging, the issue was finally found, and version 4.24.3.5 was just uploaded for the Beta test. Be aware that already saved tracks will still display incorrect times, so recompute them or just create a new one.
Hi guys,
this one was tough. Firstly thanks to Alan and Graf Geo for the excellent description and help with this. Mainly suggestion "place shaping points immediately after every NAVpoint," helped a lot, so thanks!
After almost a day of debugging, the issue was finally found, and version 4.24.3.5 was just uploaded for the Beta test. Be aware that already saved tracks will still display incorrect times, so recompute them or just create a new one.
Wow!!! 🙂😀 That I can still experience this.
I had already lost faith that it would ever work and was feeling quite frustrated and ignored that nothing was happening.
So it's all the more pleasing that the message came today that the error had been found and fixed. Installed and tested straight away and now the ETA - FINALLY - seems to be calculated correctly when shaping points are used and navigation instructions are generated.
Many, many thanks!
I would like to understand exactly what the problem was (because in some of my examples there were no navigation instructions in the vicinity of shaping points), but the main thing is that it works now. 🙂👍
Wow!!! 🙂😀 That I can still experience this.
I had already lost faith that it would ever work and was feeling quite frustrated and ignored that nothing was happening.
So it's all the more pleasing that the message came today that the error had been found and fixed. Installed and tested straight away and now the ETA - FINALLY - seems to be calculated correctly when shaping points are used and navigation instructions are generated.
Many, many thanks!
I would like to understand exactly what the problem was (because in some of my examples there were no navigation instructions in the vicinity of shaping points), but the main thing is that it works now. 🙂👍
Replies have been locked on this page!