This object is in archive! 
Average speed computed over whole trip
Completed
Hi,
in this post I find out that the average speed is based on the last 60 seconds: http://help.locusmap.eu/topic/smoother-average
Is that correct?
Can I change it that the average speed will be calculated on the whole trip?!
Reason why: the average speed of the whole trip gives me a more realistic arrical and complete travel time.
Thanks for your answer.
David
Good day Davidos,
question here is "what is whole trip"? Locus Map compute average speed from last received GPS information, no matter if you use track recording or not. So in moment, you will ride a car for a while and then walk by foot, your average speed will be big nonsense.
I really think that this 60s long averaging interval is usable for most of operations.
For better time estimates of trip travel time, you may try a "Travel time" feature: http://docs.locusmap.eu/doku.php?id=manual:user_guide:tracks:planning#estimated_travel_time
Hope this make sense to You.
Good day Davidos,
question here is "what is whole trip"? Locus Map compute average speed from last received GPS information, no matter if you use track recording or not. So in moment, you will ride a car for a while and then walk by foot, your average speed will be big nonsense.
I really think that this 60s long averaging interval is usable for most of operations.
For better time estimates of trip travel time, you may try a "Travel time" feature: http://docs.locusmap.eu/doku.php?id=manual:user_guide:tracks:planning#estimated_travel_time
Hope this make sense to You.
Hi,
and thanks for your very quick response.
I need the average speed / travel time during my trip.
Let me explain "whole trip": Trip means always one kind of utility (e. g. mountainbike). Imagine my mountainbike trip takes 2 hours with 1000 m elevation in total. After 30 min or 1 hour I will reach an average speed that won't change that much during the last periode. That's the advantage in case that the average speed will be calculated based on the whole trip. The estimated arrival time is not to bad in this calculation.
The disadvantage on the 60s is that in case that I ride uphill for 5 minutes slowly, the average speed is very low and my estimated arrival time very late. The data has no benefit for me. In case of downhilling the opposite: the estimated arrival time is very short.
I hope it became clearer now. Do you have a solution for me.
Regards,
David
Hi,
and thanks for your very quick response.
I need the average speed / travel time during my trip.
Let me explain "whole trip": Trip means always one kind of utility (e. g. mountainbike). Imagine my mountainbike trip takes 2 hours with 1000 m elevation in total. After 30 min or 1 hour I will reach an average speed that won't change that much during the last periode. That's the advantage in case that the average speed will be calculated based on the whole trip. The estimated arrival time is not to bad in this calculation.
The disadvantage on the 60s is that in case that I ride uphill for 5 minutes slowly, the average speed is very low and my estimated arrival time very late. The data has no benefit for me. In case of downhilling the opposite: the estimated arrival time is very short.
I hope it became clearer now. Do you have a solution for me.
Regards,
David
Hello,
understand, logical explanation, unfortunately little complicated to solve.
There always needs to be some time, for how long interval average speed will be computed. If there won't be any time then what? Compute it since start of app? If you does not directly terminate application, there is no guarantee that it was not just hidden on background in memory. And if not since start, then for how long? Configurable by user? It is possible but after all these years, there were not too much people who wanted something like this.
Sorry to say it, but I currently have no better solution for You. If you have any idea, I'm listening, but just keep in mind, that some changes should be usable for more users, it should not be one man show. Thanks for understanding.
Hello,
understand, logical explanation, unfortunately little complicated to solve.
There always needs to be some time, for how long interval average speed will be computed. If there won't be any time then what? Compute it since start of app? If you does not directly terminate application, there is no guarantee that it was not just hidden on background in memory. And if not since start, then for how long? Configurable by user? It is possible but after all these years, there were not too much people who wanted something like this.
Sorry to say it, but I currently have no better solution for You. If you have any idea, I'm listening, but just keep in mind, that some changes should be usable for more users, it should not be one man show. Thanks for understanding.
I think Davidos makes a good point with this average speed will be calculated based on the whole trip
I would also like to have this, at least as a user setting. It is a stupid thing to put the navigation while you are in the car and then walk to the destination on some point and expect to have a valid time estimate
Reality is we only have one means of travelling(walk,bike,car) for a started navigate/guidance to a waypoint..and it is far more usefull to estimate based on overall moving speed average.
A steady uphill hiking(8 hours) with multiple short distances of downhill or flat (like 10-15 mins) will always report correct estimated time,even if you check on shorter downhill distances of the track
Please at least make this configurable in .cfg
I think Davidos makes a good point with this average speed will be calculated based on the whole trip
I would also like to have this, at least as a user setting. It is a stupid thing to put the navigation while you are in the car and then walk to the destination on some point and expect to have a valid time estimate
Reality is we only have one means of travelling(walk,bike,car) for a started navigate/guidance to a waypoint..and it is far more usefull to estimate based on overall moving speed average.
A steady uphill hiking(8 hours) with multiple short distances of downhill or flat (like 10-15 mins) will always report correct estimated time,even if you check on shorter downhill distances of the track
Please at least make this configurable in .cfg
I changed completely to Locus just a few weeks ago and was surpriced that the average speed variates so strong during one trip.
I fully understand and I don't want to make it to complicate. In my eyes it makes only sence to calculate the average data during the recording of an track. And only the average speed during this track recording will be taken for any calculations (e.g. average speed and estimated arrival). The Advancetage: in this case the average speed won't change so strong during climbing a hill or downhilling.
Do you see a chance to realize that?
I changed completely to Locus just a few weeks ago and was surpriced that the average speed variates so strong during one trip.
I fully understand and I don't want to make it to complicate. In my eyes it makes only sence to calculate the average data during the recording of an track. And only the average speed during this track recording will be taken for any calculations (e.g. average speed and estimated arrival). The Advancetage: in this case the average speed won't change so strong during climbing a hill or downhilling.
Do you see a chance to realize that?
One ideea is to make the starting time for averaging, when the user is starting "a navigate/guidance"" to a destination,not from opening of the application
This way the user is saying.. I'm starting a new trip and it's important to me to estimate arrival time from this moment on..
And calculate it till it's reaching the destination
One ideea is to make the starting time for averaging, when the user is starting "a navigate/guidance"" to a destination,not from opening of the application
This way the user is saying.. I'm starting a new trip and it's important to me to estimate arrival time from this moment on..
And calculate it till it's reaching the destination
@Marius: thumb up
@Marius: thumb up
-1
I'm strongly against the proposed change, and it may have been an old topic of mine that suggested the current method of calculation of average. In my cycling experience, the most relevant period over which to calculate an average speed is the last few minutes, not the last hour or 5 hours ago.
-1
I'm strongly against the proposed change, and it may have been an old topic of mine that suggested the current method of calculation of average. In my cycling experience, the most relevant period over which to calculate an average speed is the last few minutes, not the last hour or 5 hours ago.
I'm also not perfectly sure if such new improvements is ideal. In some cases yes of course, but only when you have stable and mainly same activity with longer breaks etc. After such change, it may be clear to you how it works, but not to all users.
I've changed this question to idea, so I'll at see based on votes if few more users consider such change as positive or not. Thanks for now
I'm also not perfectly sure if such new improvements is ideal. In some cases yes of course, but only when you have stable and mainly same activity with longer breaks etc. After such change, it may be clear to you how it works, but not to all users.
I've changed this question to idea, so I'll at see based on votes if few more users consider such change as positive or not. Thanks for now
Perhaps 2 ways are possible:
1. Is it possible that the user descides which periode wil be used for the calculation of the average speed? That would be a good compromise. On the other hand everyone can use it as he wants. Perhaps it can be made that also 2 information of average speed can be shown in the dashboard: the last 60 secondes or last 5 minutes (defined by user) and the average speed of the whole recorded track.
There was also the question of breaks. Also this could be decided by the user: include breaks into the calculation of the average speed - or not.
2. The estimated arrival time could be also choosen by the user: calculation base on the choosen interval by the user (60 sec, 5 minutes...) or the whole trip.
By doing it that way everyone should be fine. And to be honest: that's one of the big advantage of LOCUS MAP --> the individuality of the programm.
Regards,
David
Perhaps 2 ways are possible:
1. Is it possible that the user descides which periode wil be used for the calculation of the average speed? That would be a good compromise. On the other hand everyone can use it as he wants. Perhaps it can be made that also 2 information of average speed can be shown in the dashboard: the last 60 secondes or last 5 minutes (defined by user) and the average speed of the whole recorded track.
There was also the question of breaks. Also this could be decided by the user: include breaks into the calculation of the average speed - or not.
2. The estimated arrival time could be also choosen by the user: calculation base on the choosen interval by the user (60 sec, 5 minutes...) or the whole trip.
By doing it that way everyone should be fine. And to be honest: that's one of the big advantage of LOCUS MAP --> the individuality of the programm.
Regards,
David
I like the idea of an average speed.
But perhaps I have a simple view. My average speed is from when I leave to when I stop.
I can see a use for this on my day trips, when I am out and about with a destination in mind.
Perhaps a Pie run to one of the places that I have in my POI. Days like that are never a straight out and back run. They are always side trips, stops and stuff.
If I was a smart person, I could write down the start time, mileage on the bike. Finish time and finish milage and compute it.
But that is why I have Locus.
I like the idea of an average speed.
But perhaps I have a simple view. My average speed is from when I leave to when I stop.
I can see a use for this on my day trips, when I am out and about with a destination in mind.
Perhaps a Pie run to one of the places that I have in my POI. Days like that are never a straight out and back run. They are always side trips, stops and stuff.
If I was a smart person, I could write down the start time, mileage on the bike. Finish time and finish milage and compute it.
But that is why I have Locus.
I see that nobody is giving a clear reason for why 60 sec average is better :( At least Andrew could stand by his point
I thought that discution and good arguments are making this forum a better product.But if my opinions are not taken into consideration,without any good explanation, then I do not want to post here anymore.
I do not mind if I'm proven wrong,but current algorithm I do not see fit
@ Menion Is there a reasoning behind choosing short perioud speed averaging? or is just personal taste?
I see that nobody is giving a clear reason for why 60 sec average is better :( At least Andrew could stand by his point
I thought that discution and good arguments are making this forum a better product.But if my opinions are not taken into consideration,without any good explanation, then I do not want to post here anymore.
I do not mind if I'm proven wrong,but current algorithm I do not see fit
@ Menion Is there a reasoning behind choosing short perioud speed averaging? or is just personal taste?
Good day guys,
I'm currently little bit improving this system.
Let's try to next Locus Map version following changes:
- average moving speed will be computed separately for hike, cycle and car navigation style
- current low-pass filter constant will be increased so full stabilization of filter will be after around 15 minutes. Because speeds below 0.5 m/s ( when you stand still ) are ignored, this should bring better estimates during navigation/guidance along track
Let me know after some playing with next version, if results are more realistic. Thanks for now.
Good day guys,
I'm currently little bit improving this system.
Let's try to next Locus Map version following changes:
- average moving speed will be computed separately for hike, cycle and car navigation style
- current low-pass filter constant will be increased so full stabilization of filter will be after around 15 minutes. Because speeds below 0.5 m/s ( when you stand still ) are ignored, this should bring better estimates during navigation/guidance along track
Let me know after some playing with next version, if results are more realistic. Thanks for now.
Hi all,
quite old topic. Just maybe two weeks ago I noticed really crazy time estimates in Route planner and thanks to this, found a small problem in computed average times. Let me know if in the latest 3.37.x version, time estimates gives sense to you. Hope they did and we may consider this as "implemented". Thanks.
Hi all,
quite old topic. Just maybe two weeks ago I noticed really crazy time estimates in Route planner and thanks to this, found a small problem in computed average times. Let me know if in the latest 3.37.x version, time estimates gives sense to you. Hope they did and we may consider this as "implemented". Thanks.
Replies have been locked on this page!