showing average speed in output of gpxinfo

[jose1711]

it would be nice to have average speed (total, uphill, downhill) in output of gpxinfo

[tkrajina]

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.

[vmarceau]

I will do it and send a PR.

[demlak]

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

[tkrajina]

@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.

[tkrajina]

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).

[demlak]

@tkrajina

So.. how does the 18kmh come?

[tkrajina]

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.

[demlak]

i'm confused. i thought you are the dev who knows all the "magic behind the code"?

[tkrajina]

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).

[tkrajina]

@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.

[vmarceau]

@tkrajina : thanks for the information! Indeed, when I looked into the code a few days ago, I noticed that both functions did not treat the elevation profile exactly the same way. When I'll have some more time, I'll look more closely into it and let you know my suggestions!