showing average speed in output of gpxinfo
Closed this issue · 11 comments
it would be nice to have average speed (total, uphill, downhill) in output of gpxinfo
I agree, but it's not really top-priority for me. So, leaving this issue open in case somebody wants to implement it and send a PR.
I will do it and send a PR.
It seems to me, that "Max Speed" in gpxinfo is not maximum speed, but average speed.
Attached you can see a graph made with "bikeExperince" of the given gpx testfile. as you can see, the graph says the speed was going over 20km/h several times. GPXInfo says Max speed is 18.19km/h
testfile.zip
@demlak gpxinfo for your file says:
Length 2D: 1.573km
Length 3D: 1.577km
Moving time: 00:07:52
Stopped time: 00:05:14
Max speed: 5.05m/s = 18.19km/h
Total uphill: 45.97m
Total downhill: 8.27m
Started: 2018-06-29 09:40:12
Ended: 2018-06-29 09:53:18
Points: 377
Avg distance between points: 4.17m
Now, if moving time is 00:07:52, then avg speed for you should be 1.573km/00:07:52, which from my quick calculation is around 12kmh, can't be 18km/h. Also from your graph, around 12kmh looks like it could be the right avg speed.
Also, I just returned from a mtb ride, our pace was very slow, and this is the result:
Length 2D: 27.265km
Length 3D: 27.434km
Moving time: 02:16:37
Stopped time: 00:50:12
Max speed: 6.38m/s = 22.96km/h
Avg speed: 3.30m/s = 11.88km/h
Total uphill: 570.86m
Total downhill: 565.10m
Started: 2018-07-22 08:10:03
Ended: 2018-07-22 11:16:52
Points: 1220
Avg distance between points: 22.35m
...which to me feels like right.
Note that avg time here depends a lot on the algorithm how "moving time" and "stopped time" is detected. What gpxpy does is: it just ignores any distances which calculated have speed of less than 1km/h. There are very few human activities where you go that slow, so my thinking was that in most cases this is just an error.
PS. In the latest master (gpxpy version v0.3.3) I added Avg speed in gpxinfo (but calculated for total length, not only for uphills/downhills).
I don't know. It's the same question like asking
How does "over 20kmh" come?
Reading from a graph without knowing anything else isn't really the way to get objective truth. For example: Does the code that draws that graph just calculates distances between points or it tries to account for random GPS measurement errors before calculating the speed?
I'd propose you do the following -- write a simple Python scripts that iterates through all the points and then find which are the two points where the speed is over 20kmh.
i'm confused. i thought you are the dev who knows all the "magic behind the code"?
I was referring to your "bikeExperince" thing. I have no idea how it detects max speed.
Now that we know that your initial intuition was wrong ("max speed" is "max speed", not "average speed"), the only thing left is the max speed of your track -- is it 18.19km/h or "over 20". If you think the gpxpy algorithm is incorrect -- feel free to submit a new issue. This issue is a feature request about something else (avg speeds).
@vmarceau there is one small complication here... Uphill/downhill is calculated in get_uphill_downhill() and moving data is in get_moving_data(). Calculating speed could naturally belong to get_moving_data(), but... It's not enough to just check the elevation between two points to find out if the track segment is uphill/downhill, that's because of random elevation errors. You would end up with too many uphill/downhill segments even when you are on the same elevation all the time. To fix that, get_uphill_downhill() first "smooths" the elevation graph, but get_moving_data() don't.
Maybe get_uphill_downhill() should do the same, or maybe get_moving_data() should be extended to calculate all the data get_uphill_downhill() on a smoothed track. That would also mean that get_uphill_downhill() should be deprecated. I'm still undecided on this, feel free to add your opinions on this when you have a few minutes.