Originally Posted by
MinnMan
If the x-axis is distance, rather than time, the graphically "averaged" velocity is nonsense. You know that. It's possible that the algorithm calculates a graphical average with elapsed moving time as the independent variable, And then maybe smoothing could introduce a difference, though I don't see why that difference would be systematic as compared to the mathematically rigorous quotient (total accrued distance/total moving time). "Ignoring zeros" would amount a different extraction of "moving time" as compared to another calculation, and though this is possible, one wonders why they would have two different methods for calculating moving time - which after all, has to be extracted from the same original data, whether they plot it or not.
Clearly *something* is different and smoothing is a good suspect, but again it's odd that it would result in a systematic bias.
I don't really use Strava, in Garmin you can make the X axis time or distance, but that's not what I mean. What I mean is this. You have more data points in your file than you have pixels on the X axis on that chart. Each pixel in the chart represents some amount of time, it might just be the highest or lowest value. My suspicion as a developer who fixes bugs for a living is that the average speed shown next to the chart comes from the Y values and they're being summarized incorrectly. I don't have a way to test that hunch, but in terms of how software is put together, it feels pretty likely.