Better values for "Time to target"
Normally while cycling I have found the "Time to target" estimate to be quite good. But yesterday I was navigating (walking) a 5km track @ a fairly constant 6km/h and the time was very wrong. With 4.3km still to go the displayed time to target is 14 minutes but should be 43 minutes. I estimate 14 minutes would require walking at 18km/h:
The track recording shows my moving average is 6km/h:
A calculation of 4.3 / 6.0 x 60 would suggest 43 minutes "time to target" not 14 minutes. What has gone wrong here?
I created one 5km track for the navigated outward section. I then created a copy and reversed the track for the navigated return section (route.tcx attached), The recorded track (track.tcx attached) at the screen capture was at 5.7km because I was walking out/back along the same path. I had stopped ~10 minutes at the 5km point (1/2 way).
I like this idea 
Hello Andrew,
answer here will be really simple - it is because of remaining missing settings in Locus. If you create a track by "Navigate to" feature, you define car/bike etc. But if you use any recorded or imported track, there is no definition. So Locus consider all these tracks as a "car". And use defined minimum average speed for compute of times. That is all.
Solution is planned - ability to define "profile" for navigation where you define if you wants to navigate as car/bike/walk. It will anyway take some time. Thanks for understanding.
Hello Andrew,
answer here will be really simple - it is because of remaining missing settings in Locus. If you create a track by "Navigate to" feature, you define car/bike etc. But if you use any recorded or imported track, there is no definition. So Locus consider all these tracks as a "car". And use defined minimum average speed for compute of times. That is all.
Solution is planned - ability to define "profile" for navigation where you define if you wants to navigate as car/bike/walk. It will anyway take some time. Thanks for understanding.
Thanks for the explanation Menion. Your plan makes sense for an estimate before starting to navigate, but once navigating has started (like my example) all the real numbers are known, the answer is even simpler ---> 4.3 / 6 x 60 = 43 minutes. Would it therefore be best to only use your new "profile average" when the moving average is unknown and for a few minutes after navigation starts, then switch to the current moving average (or weighted moving average)?
Thanks for the explanation Menion. Your plan makes sense for an estimate before starting to navigate, but once navigating has started (like my example) all the real numbers are known, the answer is even simpler ---> 4.3 / 6 x 60 = 43 minutes. Would it therefore be best to only use your new "profile average" when the moving average is unknown and for a few minutes after navigation starts, then switch to the current moving average (or weighted moving average)?
It is not precise. What you suggest was implemented few months (maybe already an year) before, but it do not work.
Imagine you take a break somewhere, you will stay on red light on a cross for very long, or any other delay. This will result in quite huge numbers that will be far away from reality. Moving average is just not good enough to give logical time estimates. There always have to be some minimal value and this value is based on what kind of navigation (walk/bike/car) you just do ...
It is not precise. What you suggest was implemented few months (maybe already an year) before, but it do not work.
Imagine you take a break somewhere, you will stay on red light on a cross for very long, or any other delay. This will result in quite huge numbers that will be far away from reality. Moving average is just not good enough to give logical time estimates. There always have to be some minimal value and this value is based on what kind of navigation (walk/bike/car) you just do ...
Maybe replace any zero value with a profile value. Surely a non-zero moving average is the reality. But if I stop for a long delay I would actually expect the "Time to Target" to gradually increase towards infinity. Certainly I can't walk at 18km/h. In code I have written there would be 10 "bins" for each average over the last 10 minutes to calculate the weighted moving average over. So stopping for 1 or 2 minutes does not suddenly make the displayed average infinity.
Maybe replace any zero value with a profile value. Surely a non-zero moving average is the reality. But if I stop for a long delay I would actually expect the "Time to Target" to gradually increase towards infinity. Certainly I can't walk at 18km/h. In code I have written there would be 10 "bins" for each average over the last 10 minutes to calculate the weighted moving average over. So stopping for 1 or 2 minutes does not suddenly make the displayed average infinity.
Sorry Andrew, but I cannot agree. I expect that if I stop somewhere, I will still see a realistic value. So if someone ask me "how long", I may tell "2 hours" and not "3 days" because I just had 15 minutes break. If you will use 10 minutes average, it will take 10 minutes! after you start a ride, till you get some useful values, which does not make sense for me.
Sorry Andrew, but I cannot agree. I expect that if I stop somewhere, I will still see a realistic value. So if someone ask me "how long", I may tell "2 hours" and not "3 days" because I just had 15 minutes break. If you will use 10 minutes average, it will take 10 minutes! after you start a ride, till you get some useful values, which does not make sense for me.
OK, yes I agree with your point while stopped. It wasn't a good thought of mine. However while moving, if you don't use actual average speed, then the Time to Target is just a guess based on remaining distance. For a bike the estimate is only accurate if the speed is 5m/s (18km/h) but my track may be hard uphill all day, or the smooth road may be flat with a tail wind. In both cases the time will be very inaccurate.
> If you will use 10 minutes average, it will take 10 minutes!
No - as soon as you measure a valid non-zero speed, you pre-populate each of the X bins with the initial average, I have used this general method successfully in other software. It could be 5 or 20 bins, it could be every 5 or 60 seconds, the weighting can vary, there are many variations depending on the requirements.
So to answer my own original question now - I selected the cycling profile for track recording instead of the walking profile. Because of my selection error the displayed time was always wrong.
>Solution is planned - ability to define "profile" for navigation where you define...
>you wants to navigate as car/bike/walk.
So you plan to add more UI/ more settings for a navigation profile? If the user selects the wrong profile the error remains. With my suggestion this type of error could not occur, and the profile settings are only used for the initial estimate, but not while navigating - more automatic, more accurate, less settings.
OK, yes I agree with your point while stopped. It wasn't a good thought of mine. However while moving, if you don't use actual average speed, then the Time to Target is just a guess based on remaining distance. For a bike the estimate is only accurate if the speed is 5m/s (18km/h) but my track may be hard uphill all day, or the smooth road may be flat with a tail wind. In both cases the time will be very inaccurate.
> If you will use 10 minutes average, it will take 10 minutes!
No - as soon as you measure a valid non-zero speed, you pre-populate each of the X bins with the initial average, I have used this general method successfully in other software. It could be 5 or 20 bins, it could be every 5 or 60 seconds, the weighting can vary, there are many variations depending on the requirements.
So to answer my own original question now - I selected the cycling profile for track recording instead of the walking profile. Because of my selection error the displayed time was always wrong.
>Solution is planned - ability to define "profile" for navigation where you define...
>you wants to navigate as car/bike/walk.
So you plan to add more UI/ more settings for a navigation profile? If the user selects the wrong profile the error remains. With my suggestion this type of error could not occur, and the profile settings are only used for the initial estimate, but not while navigating - more automatic, more accurate, less settings.
Menion - today I did a 5 hour ride with much observation of the "Time to target". It worked perfectly every time. Even better than I had expected. The estimated time slowly increased as I rode uphill, and slowly decreased as I rode downhill, taking about 2 minutes to become accurate as my speed varied. And if I stopped completely, the estimate increased to a large time (eg. 5 or 7 hours) and then remained at this time until I started riding again. I tried navigation with/ without track recording, and different profiles (car/ bike/ walk). None made any difference, the estimate was always perfect.
So Mention, when I read your first reply 3 days ago, I am now totally confused. We must be misunderstanding each other. The "Time to target" works perfectly today, just as I would have expected, and very different to the explanation in your reply. So for my original question again, I still do not understand why the estimate was 14 minutes (wrong) instead of 43 minutes (correct) because if I had simulated the same conditions today I am sure the estimate would have correctly calculated & displayed as 43 minutes.
Menion - today I did a 5 hour ride with much observation of the "Time to target". It worked perfectly every time. Even better than I had expected. The estimated time slowly increased as I rode uphill, and slowly decreased as I rode downhill, taking about 2 minutes to become accurate as my speed varied. And if I stopped completely, the estimate increased to a large time (eg. 5 or 7 hours) and then remained at this time until I started riding again. I tried navigation with/ without track recording, and different profiles (car/ bike/ walk). None made any difference, the estimate was always perfect.
So Mention, when I read your first reply 3 days ago, I am now totally confused. We must be misunderstanding each other. The "Time to target" works perfectly today, just as I would have expected, and very different to the explanation in your reply. So for my original question again, I still do not understand why the estimate was 14 minutes (wrong) instead of 43 minutes (correct) because if I had simulated the same conditions today I am sure the estimate would have correctly calculated & displayed as 43 minutes.
Hi Andrew,
oki, let's move a little bit with this topic :).
You wrote you "did a ride" - what was source of this track? You planned it manually thanks to Navigate to feature? Or it was some already recorded track and you just re-used it for navigation?
Hi Andrew,
oki, let's move a little bit with this topic :).
You wrote you "did a ride" - what was source of this track? You planned it manually thanks to Navigate to feature? Or it was some already recorded track and you just re-used it for navigation?
It was the same method for both days - I created the track (route) in Locus with the the track editor, point to point, compute source BRouter, no compute instructions, and manually add some navpoints.
It was the same method for both days - I created the track (route) in Locus with the the track editor, point to point, compute source BRouter, no compute instructions, and manually add some navpoints.
Hmm then it is weird that there is a difference. I do not know if you wants to invest more time into this case.
Anyway I'm looking into code and in case, you create a track manually, then last computed segment is used as source for "type". By type I mean foot/bike/car.
So if you computed last segment as bike, whole track will be internally marked as "bike". You may confirm this also when you export track to GPX file. There should be parameter "locus:rteComputeType", where values 0, 1, 6 are car, 2, 4, 5 are bike and 3 is foot.
Second important information is "minimum" speed values for certain "type". These are "foot" 1 m/s, bike 5 m/s and car 15 m/s (may be modified in config.cfg).
And how Locus works ... when you use navigation, Locus take "type" of track (if not defined like in imported track, "car" is default), and in every moment compute required distance (to next point or to target). Then Locus compute average speed for last 60 seconds. If this speed is higher then "minimum" for this "type", it is used (in case you drive faster then minimum defined speed). Otherwise "minimum" is used.
Well and result is simply speed divided by distance and it is a time you see on display.
Uff, not sure if you find this description of my algorithm logical, but maybe it helps to understand it a little bit :).
Hmm then it is weird that there is a difference. I do not know if you wants to invest more time into this case.
Anyway I'm looking into code and in case, you create a track manually, then last computed segment is used as source for "type". By type I mean foot/bike/car.
So if you computed last segment as bike, whole track will be internally marked as "bike". You may confirm this also when you export track to GPX file. There should be parameter "locus:rteComputeType", where values 0, 1, 6 are car, 2, 4, 5 are bike and 3 is foot.
Second important information is "minimum" speed values for certain "type". These are "foot" 1 m/s, bike 5 m/s and car 15 m/s (may be modified in config.cfg).
And how Locus works ... when you use navigation, Locus take "type" of track (if not defined like in imported track, "car" is default), and in every moment compute required distance (to next point or to target). Then Locus compute average speed for last 60 seconds. If this speed is higher then "minimum" for this "type", it is used (in case you drive faster then minimum defined speed). Otherwise "minimum" is used.
Well and result is simply speed divided by distance and it is a time you see on display.
Uff, not sure if you find this description of my algorithm logical, but maybe it helps to understand it a little bit :).
Thanks - I really appreciate that explanation because it tells me what the correct/ expected behavior is . And that is exactly the behavior yesterday when I was closely observing - and is the perfect behavior.
Unfortunately I exported the original track to TCX not GPX, and then deleted the Locus track, so I am not able to check the "type" ;-(
But the GPX track I exported yesterday does not contain a string "locus:rteComputeType"? I exported as V1.0 not V1.1 because my version of Garmin BaseCamp crashes with 1.1. Is this the reason?
Why is the config.cfg "minimum" speed so high? 3.6km/h (foot), 18km/h (bike), 54km/h (car) - they are all average speeds not minimum speeds. If they are just used to compute average, would a real "minimum" be better? Eg. 1km/h (foot), 4km/h (bike), 20km/h (car)? Yes, I can modify my own config.cfg but am thinking of all Locus users.
Thanks - I really appreciate that explanation because it tells me what the correct/ expected behavior is . And that is exactly the behavior yesterday when I was closely observing - and is the perfect behavior.
Unfortunately I exported the original track to TCX not GPX, and then deleted the Locus track, so I am not able to check the "type" ;-(
But the GPX track I exported yesterday does not contain a string "locus:rteComputeType"? I exported as V1.0 not V1.1 because my version of Garmin BaseCamp crashes with 1.1. Is this the reason?
Why is the config.cfg "minimum" speed so high? 3.6km/h (foot), 18km/h (bike), 54km/h (car) - they are all average speeds not minimum speeds. If they are just used to compute average, would a real "minimum" be better? Eg. 1km/h (foot), 4km/h (bike), 20km/h (car)? Yes, I can modify my own config.cfg but am thinking of all Locus users.
Yes, GPX 1.0 has limited support for custom extension, so there parameters are not there. Basecamp is really crazy application. I hope, that all issues are already solved, but it still do not work perfectly? Crazy.
Anyway version 1.1 helps here.
And speeds - maybe change "minimum" for "expected". They are not used for compute average.
Logic is (in simple programmatical point of view):
so this "expected" speed (defined in config) is just minimum speed used for compute of time estimates. Hard to say if they are too high. I hope that field tests show and users say me "hey, on bike it usually tell me a 20% less time then expected", so I'll then reduce default values by 20 % :).
Yes, GPX 1.0 has limited support for custom extension, so there parameters are not there. Basecamp is really crazy application. I hope, that all issues are already solved, but it still do not work perfectly? Crazy.
Anyway version 1.1 helps here.
And speeds - maybe change "minimum" for "expected". They are not used for compute average.
Logic is (in simple programmatical point of view):
so this "expected" speed (defined in config) is just minimum speed used for compute of time estimates. Hard to say if they are too high. I hope that field tests show and users say me "hey, on bike it usually tell me a 20% less time then expected", so I'll then reduce default values by 20 % :).
So this was my problem - track recording type=bike but I was in fact walking. My actual speed 1.7m/s (6km/h) is less than your "minimum" average 5m/s, so 5m/s is used to calculate "Time to target" --> 4.3km/18km/h = 14m.
How is the "type" determined if track recording is turned off?
If your "minimum" average is just to calculate "Time to target" when GPS is stopped, and avoid "divide by zero" error then here is a suggestion:
I can achieve this result as workaround by setting navigation_average_speed_foot, navigation_average_speed_bike, navigation_average_speed_car=0.3.
So this was my problem - track recording type=bike but I was in fact walking. My actual speed 1.7m/s (6km/h) is less than your "minimum" average 5m/s, so 5m/s is used to calculate "Time to target" --> 4.3km/18km/h = 14m.
How is the "type" determined if track recording is turned off?
If your "minimum" average is just to calculate "Time to target" when GPS is stopped, and avoid "divide by zero" error then here is a suggestion:
I can achieve this result as workaround by setting navigation_average_speed_foot, navigation_average_speed_bike, navigation_average_speed_car=0.3.
Hmm now you confused me. What is "track recording" doing here? I though we talk only about navigation system. Track recording profile has absolutely no influence on anything except ... well, track recording. You may simply rename your profile and also change it's icon, so all "bike" info will be lost.
You suggest some solutions here, but
1) this leads again to this: http://help.locusmap.eu/topic/why-was-time-to-target-so-wrong#comment-17650 ( so time to ride 100 km trip in car with 1 hour break on lunch in the middle, results in increasing numbers till "current average will be used", then big jump to some more logical values when "average (all)" starts (it is not counted in Locus, so it is extra work to do) and then later, when you will need also a break after lunch, "unknown" value ...
2) you wrote then during your previous ride, values were quite precise, so probably good combination of "type" in planned route and activity itself (your speed was same as "expected" time for planned route)
Result is: isn't just best solution, be able to define what kind of activity you are just doing (walk/bike/car) and then optimize this speed parameter? I'm sure you will agree that some more user friendly system for automatization should be useful (like start navigation also: start centering, rotation of map, set "bike" profile, enable auto-zoom, etc.). And this all may be connected together. Just my idea, because I'm still not a fan of your solutions, which will lead to enormously loooong times in case, you will be just slow. I know this, because: http://help.locusmap.eu/topic/why-was-time-to-target-so-wrong#comment-17616
Hmm now you confused me. What is "track recording" doing here? I though we talk only about navigation system. Track recording profile has absolutely no influence on anything except ... well, track recording. You may simply rename your profile and also change it's icon, so all "bike" info will be lost.
You suggest some solutions here, but
1) this leads again to this: http://help.locusmap.eu/topic/why-was-time-to-target-so-wrong#comment-17650 ( so time to ride 100 km trip in car with 1 hour break on lunch in the middle, results in increasing numbers till "current average will be used", then big jump to some more logical values when "average (all)" starts (it is not counted in Locus, so it is extra work to do) and then later, when you will need also a break after lunch, "unknown" value ...
2) you wrote then during your previous ride, values were quite precise, so probably good combination of "type" in planned route and activity itself (your speed was same as "expected" time for planned route)
Result is: isn't just best solution, be able to define what kind of activity you are just doing (walk/bike/car) and then optimize this speed parameter? I'm sure you will agree that some more user friendly system for automatization should be useful (like start navigation also: start centering, rotation of map, set "bike" profile, enable auto-zoom, etc.). And this all may be connected together. Just my idea, because I'm still not a fan of your solutions, which will lead to enormously loooong times in case, you will be just slow. I know this, because: http://help.locusmap.eu/topic/why-was-time-to-target-so-wrong#comment-17616
Summary: I was walking along a track created with fast bike profile - sorry it took so long but I finally see!! I think could happen to other users too.
>now you confused me. What is "track recording" doing here?
sorry - I guessed the "minimum" 5m/s comes selected track recording profile, but I now understand when creating the track it comes from compute source profile
But this makes me think the existing three "minimums" are problematic, and a more robust, self adjusting algorithm could improve the results, and reduce the number of settings. One obvious example for an "ordinary" user - they ride all day at 10km/h but the estimate will be based on 18km/h. I am simply suggesting replacing constant "minimum" with average(all). OK, a few more details than this sure, but that is the essence. You have said many times you want less settings/ more automation.
I very much like the activity profile idea but from your explanation I now think the "speed parameter" (constant or future UI setting) can be completed avoided.
Examples of loooog times - yesterday when I stopped (about 1 hour before finish), the "Time to target" slowly increased from 1h (correct value) to 5h in space of 1 minute, I assume as my average reduced towards zero, but not yet down to 5m/s. At another short stop about 1.5h to finish the displayed time was 7h. Each time as soon as I started riding and within a minute the estimate was again excellent, so I was very happy. If you want to avoid sudden changes in the estimate, a post filter could be used.
Sorry for taking so much time on this topic but I think the final outcome is very good. And I hope others benefit. Forums are inefficient for this quick back/forth conversation compared to face-to-face.
Summary: I was walking along a track created with fast bike profile - sorry it took so long but I finally see!! I think could happen to other users too.
>now you confused me. What is "track recording" doing here?
sorry - I guessed the "minimum" 5m/s comes selected track recording profile, but I now understand when creating the track it comes from compute source profile
But this makes me think the existing three "minimums" are problematic, and a more robust, self adjusting algorithm could improve the results, and reduce the number of settings. One obvious example for an "ordinary" user - they ride all day at 10km/h but the estimate will be based on 18km/h. I am simply suggesting replacing constant "minimum" with average(all). OK, a few more details than this sure, but that is the essence. You have said many times you want less settings/ more automation.
I very much like the activity profile idea but from your explanation I now think the "speed parameter" (constant or future UI setting) can be completed avoided.
Examples of loooog times - yesterday when I stopped (about 1 hour before finish), the "Time to target" slowly increased from 1h (correct value) to 5h in space of 1 minute, I assume as my average reduced towards zero, but not yet down to 5m/s. At another short stop about 1.5h to finish the displayed time was 7h. Each time as soon as I started riding and within a minute the estimate was again excellent, so I was very happy. If you want to avoid sudden changes in the estimate, a post filter could be used.
Sorry for taking so much time on this topic but I think the final outcome is very good. And I hope others benefit. Forums are inefficient for this quick back/forth conversation compared to face-to-face.
Here is an example of "Time to target" yesterday while I was stopped. This would imply the average speed used in the calculation is 3.6km/h which is well below the bike profile "minimum" of 18km/h. So your calculation must be more complex than explained. The estimate didn't concern me, because as soon as I started riding it came back down to an accurate number. I my proposal I should have said use average(moving) instead of average(all). Then the estimate would have been 40.7km/22km/h = ~2 hours instead of 11.
Another simple example - if I ride to the top of mont ventoux @ 8km/h I really do want to see the time estimate based on 8km/h, not 18km/h.
Here is an example of "Time to target" yesterday while I was stopped. This would imply the average speed used in the calculation is 3.6km/h which is well below the bike profile "minimum" of 18km/h. So your calculation must be more complex than explained. The estimate didn't concern me, because as soon as I started riding it came back down to an accurate number. I my proposal I should have said use average(moving) instead of average(all). Then the estimate would have been 40.7km/22km/h = ~2 hours instead of 11.
Another simple example - if I ride to the top of mont ventoux @ 8km/h I really do want to see the time estimate based on 8km/h, not 18km/h.
I've discussed this with Michal and I've in the end agreed with some improvements.
I won't say exact algorithm for now, but we should chat after another field test with next version ;). I'll be testing it too and watch results more carefully ...
For now, thanks for help and useful discussion. Btw. in the end, I have to say that you are correct. In this case, should be a lot better some automatic solution, then extra settings!
I've discussed this with Michal and I've in the end agreed with some improvements.
I won't say exact algorithm for now, but we should chat after another field test with next version ;). I'll be testing it too and watch results more carefully ...
For now, thanks for help and useful discussion. Btw. in the end, I have to say that you are correct. In this case, should be a lot better some automatic solution, then extra settings!
That's great news. In the meantime I took your advise and reduced all three config.cfg navigation_average_speed_<X>=0.3 - thanks. This now works perfectly for me - the Time to target is now accurate for slower than "average" speeds. And I can reuse a track created with a different profile without concern for inappropriate "average" speed.
That's great news. In the meantime I took your advise and reduced all three config.cfg navigation_average_speed_<X>=0.3 - thanks. This now works perfectly for me - the Time to target is now accurate for slower than "average" speeds. And I can reuse a track created with a different profile without concern for inappropriate "average" speed.
I think I have suggsted this in the past and it was declined. IMO the best way to calculate time to arrive (or estimated arrival time) is to use the speed profile from the very start of guiding/navigation, ie. Locus knows the total route distance/time passed and adjusts it to remaining route/track part (assuming the remaining part from upcoming waypoint to end waypoint), as the immediate speed may highly vary during route.
I think I have suggsted this in the past and it was declined. IMO the best way to calculate time to arrive (or estimated arrival time) is to use the speed profile from the very start of guiding/navigation, ie. Locus knows the total route distance/time passed and adjusts it to remaining route/track part (assuming the remaining part from upcoming waypoint to end waypoint), as the immediate speed may highly vary during route.
Hi All,
for me (riding mtb often single track up- and downhill - so my average speed varies a lot during ride (biking uphill with 3.5 km/h and down with 15 km/h....) and also from ride to ride I would suggest to estimate the time to target as an average of a) the actual speed and b) the value in the speed profile. This would balance both of the discussed use-cases.
And I opened this idea: http://help.locusmap.eu/topic/make-navigation_average_speed_-a-value-in-menu-for-better-time-to-target-values so that we could create different track recording profiles with better standard values for the preset average speed.
Greetings, thanks
Wille
Hi All,
for me (riding mtb often single track up- and downhill - so my average speed varies a lot during ride (biking uphill with 3.5 km/h and down with 15 km/h....) and also from ride to ride I would suggest to estimate the time to target as an average of a) the actual speed and b) the value in the speed profile. This would balance both of the discussed use-cases.
And I opened this idea: http://help.locusmap.eu/topic/make-navigation_average_speed_-a-value-in-menu-for-better-time-to-target-values so that we could create different track recording profiles with better standard values for the preset average speed.
Greetings, thanks
Wille
I created a 1km track with BRouter/ cycling profile, and intentionally walked along track instead of cycle. The "Time to Target" was a good estimate with v3.9.3.
I created a 1km track with BRouter/ cycling profile, and intentionally walked along track instead of cycle. The "Time to Target" was a good estimate with v3.9.3.
Best ETA (Estimated time of arrive) for a single user can be created only when app is learning our habits. Using Locus noticed that calculated ETA is based on the average speed of the last few minutes. The result is that when riding a bicycle or walk the ETA contains a big mistake. The best solution I've seen have Garmin. After several years of use, my eTrex device learned my speed on various types of roads. Of course, depending on the profile of navigation - a car, a bike or walking. ETA projected over a distance of 400-500 kilometers for the car differed only a few minutes with the actual time of arrival. When riding a bicycle was similar. I wonder whether it is possible to implement such a solution for Locus. Just when navigating the application calculates the average speed for each type of road and used afterwards with such a profile when calculating the ETA. Of course, separate averages are for the car, bike and walk.
Best ETA (Estimated time of arrive) for a single user can be created only when app is learning our habits. Using Locus noticed that calculated ETA is based on the average speed of the last few minutes. The result is that when riding a bicycle or walk the ETA contains a big mistake. The best solution I've seen have Garmin. After several years of use, my eTrex device learned my speed on various types of roads. Of course, depending on the profile of navigation - a car, a bike or walking. ETA projected over a distance of 400-500 kilometers for the car differed only a few minutes with the actual time of arrival. When riding a bicycle was similar. I wonder whether it is possible to implement such a solution for Locus. Just when navigating the application calculates the average speed for each type of road and used afterwards with such a profile when calculating the ETA. Of course, separate averages are for the car, bike and walk.
Replies have been locked on this page!