"Time to target" data source not working properly
Not a Problem
Hi there
I think the "time to target" data source has a bug.
When I use it in my dashboard, it seems to generate random numbers about how long it will take to walk to the end of the route I'm following. The "distance to target" field and the "average speed" field work fine, so why isn't the "time to target" just the distance to target divided by the a average speed? See example in screenshots. Also, on a hike I did a couple of days ago, after about 1km following a 22km route, the "time to target" said the remaining walking time to complete the whole route was 44 minutes.
I'd be really grateful if you could try and fix this - or perhaps tell me if I'm doing something wrong.
Many thanks
Adam
The same problem 
Here are the screenshits
Here are the screenshits
Screenshits? Hopefully they don’t smell too bad... 😉😎
It’s important to know how you created the route. Did you use the route planner, and which profile did you use? With or without navigation commands? Did you perhaps set an incorrect (too high) speed using the slider (‘average speed on flat ground’)?
It doesn’t simply use your previous average speed for the remaining distance, but employs a highly complex (overly complex) algorithm that takes into account gradients, surface conditions and much more. I haven’t always had good experiences with this, particularly when hiking; the ETA times are often not particularly accurate. (I therefore prefer to plan my hiking routes without navigation instructions; in my experience, the results are then significantly better in terms of the ETA. When cycling, on the other hand, it may make more sense to plan using navigation commands, as gradients and road surfaces have a much greater impact on the time taken than when walking.)
But it shouldn’t be as drastic as in your case; that suggests it’s more likely to be a wrong setting.
Screenshits? Hopefully they don’t smell too bad... 😉😎
It’s important to know how you created the route. Did you use the route planner, and which profile did you use? With or without navigation commands? Did you perhaps set an incorrect (too high) speed using the slider (‘average speed on flat ground’)?
It doesn’t simply use your previous average speed for the remaining distance, but employs a highly complex (overly complex) algorithm that takes into account gradients, surface conditions and much more. I haven’t always had good experiences with this, particularly when hiking; the ETA times are often not particularly accurate. (I therefore prefer to plan my hiking routes without navigation instructions; in my experience, the results are then significantly better in terms of the ETA. When cycling, on the other hand, it may make more sense to plan using navigation commands, as gradients and road surfaces have a much greater impact on the time taken than when walking.)
But it shouldn’t be as drastic as in your case; that suggests it’s more likely to be a wrong setting.
Ah yes sorry about the smelly typo! Thanks for the suggestions.
I was following a route that I downloaded from Komoot but I stripped out all the waypoints before using it. So I’m pretty sure it was just a plain gpx with no instructions or other bits of debris in it. So I’m puzzled as to what is going on - I think the “time to target” algorithm may have an error in it.
Ah yes sorry about the smelly typo! Thanks for the suggestions.
I was following a route that I downloaded from Komoot but I stripped out all the waypoints before using it. So I’m pretty sure it was just a plain gpx with no instructions or other bits of debris in it. So I’m puzzled as to what is going on - I think the “time to target” algorithm may have an error in it.
Show the route and open the Route planner. Create a new route using the route planner. Now you can compare whether the error still exists.
Show the route and open the Route planner. Create a new route using the route planner. Now you can compare whether the error still exists.
Hi
Thanks that’s helpful.
But I really don’t want to have to recreate the hike in the planner - it’s much safer to download it from a verified website from someone who’s actually done the hike before. If I try to do it myself, I’m likely to make a mistake because I don’t know exactly where it goes. If I just import a “plain” gox, if locus can use it to correctly calculate the distance to target (ie the end - there are no other “targets”) and can calculate the average speed, why can’t it just divide the distance by the average speed to calculate the likely time left to the target (=end)? I really can’t work out how it manages to calculate such weird numbers for the estimated time remaining - I don’t know what “targets” it could be using!
Thanks.
Adam
Hi
Thanks that’s helpful.
But I really don’t want to have to recreate the hike in the planner - it’s much safer to download it from a verified website from someone who’s actually done the hike before. If I try to do it myself, I’m likely to make a mistake because I don’t know exactly where it goes. If I just import a “plain” gox, if locus can use it to correctly calculate the distance to target (ie the end - there are no other “targets”) and can calculate the average speed, why can’t it just divide the distance by the average speed to calculate the likely time left to the target (=end)? I really can’t work out how it manages to calculate such weird numbers for the estimated time remaining - I don’t know what “targets” it could be using!
Thanks.
Adam
Hi all,
When a route is not planned with LoRouter and does not contain timestamps from which an accurate ETA can be calculated, the ETA is calculated based on the remaining distance and the average speed measured along the portion of the route that has been traveled without breaks. If there is additional GPS deviation caused by external factors, such as weather or terrain, the ETA may differ significantly from expectations.
Hi all,
When a route is not planned with LoRouter and does not contain timestamps from which an accurate ETA can be calculated, the ETA is calculated based on the remaining distance and the average speed measured along the portion of the route that has been traveled without breaks. If there is additional GPS deviation caused by external factors, such as weather or terrain, the ETA may differ significantly from expectations.
Hello Adam,
Here only my point of view about re-routing a recorder track.
Pros
- Allows to have the better available information about way type (street, track, path, etc) and surface type (asphalt, gravel, ground, etc). Also turn-by-turn guidance.
- Even if the resulte is never perfect (depending on Open Street Map datas), if you travel with beguiner people it is safer, because router do not allow you to go to unexisting "roads".
- When done, it is very easy to change the route.
Cons
- If a lot of "roads" of the recorded track are not in Open Street Map it will be long to re-route. In France for example, some forest are poorly mapped.
- If you ride a lot, it is time consuming doing this frequently.
My way to re-route a recorded track.
- I store the imported (recorded) GPX into a specific directory ("Imported") of the library. I set a specific Line style for this folder (different of the standard).
- I make a copy of this track, and store it into a different directory ("My routes") of the library.
- I have now the two tracks on the map.
- I open the copied track in the route planner and recalculate all with the correct routing mode (Hiking, Touring, MTB, etc.).
- The resulting routed track is often different of the imported one. To correct that, I add shaping points or move segment points in order to be above the imported track.
- If a "road" segment is very difficult to set, it can be because "road" is not present in Open Street Map or the access is restricted (Locus map show it on the map). Here I draw a manual segment (manual mode).
Note :
- After doing several re-routing it is easier.
- In order to see the "road" type below the route line on the map, my Style line is : Pattern (no Line), Arrows 2, Coloring mode=Slope, Width=13 (or smaller for imported tracks).
Hello Adam,
Here only my point of view about re-routing a recorder track.
Pros
- Allows to have the better available information about way type (street, track, path, etc) and surface type (asphalt, gravel, ground, etc). Also turn-by-turn guidance.
- Even if the resulte is never perfect (depending on Open Street Map datas), if you travel with beguiner people it is safer, because router do not allow you to go to unexisting "roads".
- When done, it is very easy to change the route.
Cons
- If a lot of "roads" of the recorded track are not in Open Street Map it will be long to re-route. In France for example, some forest are poorly mapped.
- If you ride a lot, it is time consuming doing this frequently.
My way to re-route a recorded track.
- I store the imported (recorded) GPX into a specific directory ("Imported") of the library. I set a specific Line style for this folder (different of the standard).
- I make a copy of this track, and store it into a different directory ("My routes") of the library.
- I have now the two tracks on the map.
- I open the copied track in the route planner and recalculate all with the correct routing mode (Hiking, Touring, MTB, etc.).
- The resulting routed track is often different of the imported one. To correct that, I add shaping points or move segment points in order to be above the imported track.
- If a "road" segment is very difficult to set, it can be because "road" is not present in Open Street Map or the access is restricted (Locus map show it on the map). Here I draw a manual segment (manual mode).
Note :
- After doing several re-routing it is easier.
- In order to see the "road" type below the route line on the map, my Style line is : Pattern (no Line), Arrows 2, Coloring mode=Slope, Width=13 (or smaller for imported tracks).
Thank you everyone for all your help. It looks like Locus “time to target” is doing a far more complex calculation than I expected. So I will experiment with creating or importing the routes I want to follow, but ensuring there’s no time, waypoint, surface or navigation data included in it. Hopefully then Time to Target will behave as Michal suggests and just divide the remaining distance by the average speed so far. If it continues to return strange results, I’ll add to this thread.
Much appreciated, everyone.
Adam
Thank you everyone for all your help. It looks like Locus “time to target” is doing a far more complex calculation than I expected. So I will experiment with creating or importing the routes I want to follow, but ensuring there’s no time, waypoint, surface or navigation data included in it. Hopefully then Time to Target will behave as Michal suggests and just divide the remaining distance by the average speed so far. If it continues to return strange results, I’ll add to this thread.
Much appreciated, everyone.
Adam
Replies have been locked on this page!