Inconsistent GPX average and max speed

[nbrr]

Description

When a track is open, it shows an average speed that is higher than the max speed. e.g. average speed 11.5km/h, max speed 10.8 km/h.

How to reproduce?

Open GPX track, read speed section.

Your Environment

OsmAnd Version: OsmAnd+ 3.8.3 Android/iOS version: Android 8.0.0 Device model: LG-H870DS

[vshcherb]

Can't reproduce it, please share the track or screenshot.

[nbrr]

Any way I could privately share the track?

Screenshot 1 Screenshot 2

[sonora]

The average speed is obtained via total distance covered divided by time needed, and is consistent in both screenshots.

The maximum speed is the maximum recorded value of the orange speed graph (which is taken from the speed values contained in the track itself), looks also consistent in both screenshots.

Looks to me the inconsistency is not an artifact of the analysis, but is within your GPX files itself: Either the distance they represent is exaggerated (high lateral noise), or the time reported is somehow too short, or the speed values contained in the GPX are generally too low, which could be a chipset or rounding error, or the result of some smoothing applied. With what tool were they recorded (or post-processed)?

[nbrr]

They were recorded with osmand's Trip recording plugin.

[sonora]

I am curious to look at the fies, please PM or share with OsmAnd support. Any filters set for the recording?

[nbrr]

I'm not aware that github has any kind of pm feature. I sent an email to contactus@osmand.net, ref is 26416. I am not aware of any kind of filter.

[sonora]

Thx! @vshcherb if you could forward the files via mail, I'd be hapy to take a look.

[vshcherb]

You can send it to support@osmand.net and we will take a look.

[nbrr]

Done.

[wibraun]

I've noted the same issue in my tracks and could provide more such files if this would be helpful.

[sonora]

If you can share a track here, please do!

I once wrote the analysis code years ago, but have yet to see a recorded track exhibiting this behavior.

[wibraun]

Hope that helps to nailed it down.

osm_issue_10047_track.zip

[vshcherb]

@sonora forwarded

[sonora]

Thanks for the 3 tracks! Here's how it looks:

1. The average speed, which OsmAnd calculates from the contained time stamps and lateral position shifts while in motion, is correct in all 3 cases.

2. Having said that, the 3 tracks are slightly oversampled, meaning they are taken at low speeds of between 5 and 10 km/h, but with a point recorded every 5 seconds.

   • For e.g. track max-avg-issue#10047.gpx, obviously taken in a forest environment, the average accuracy contained is 12 to 16 meters, but you are taking readings only an average 9 meters apart!
   • You can verify by zooming in closely that the tracks exhibit a zig-zag motion (compare recorded track vs. OSM footpath) which is probably not real, but a noise artifact with high point density. This leads to overestimating the real distance covered, and as such your calculated (effective) average speed is slightly overestimated vs. reality.

--> If you record similar tracks at sampling rates of 10 or 15 seconds (reasonable for e.g. jogging), I expect the effect to go away, can you please test?

3. The max speed value which OsmAnd reports, on the other hand, is the maximum speed your GPS actually reported during the trip. (It is not a value calculated by OsmAnd, but is contained directly in the gpx file.) It is the maximum of each point reading's GPS speed value, the GPS algorithm results in some smoothing, and as such a more reliable maximum than deriving one from each single and more noisy point-to-point lateral position shifts. (For the example tracks this would be max-avg-issue#10047.gpx 9.60 km/h, 20201020 course.gpx 14.54 km/h, 20201023 course.gpx 13.22 km/h, I think all exaggerated by single noisy readings. (Similar to #9133, but here in the speed domain. And for the other end of the scale, see #9904.)

My summary:

• A. Average speed (maybe more appropriately effective speed) is really best derived from the overall distance reported covered vs. moving time needed, I think we are ok here. (We could report an average speed from the GPS-reported values (where present in the files), but this would simply move the observed inconsistency to not match overall traveled distance / traveled time. For the sake of completeness, here are the values: max-avg-issue#10047.gpx 4.13 km/h, 20201020 course.gpx 10.13 km/h, 20201023 course.gpx 9.30 km/h)
• B. Maximum speed is best taken from what the GPS reports point by point, even if that may be a little device dependent
• C. If in this analysis your overall (average) speed appears higher than what GPS reports as your (individual) maximum speed, this indicates too much lateral noise in your recording. You are either in bad reception conditions, or your sampling rate is too high, or both. But it is a real effect, indicating something is not quite right!

As a conclusion, we should probably leave the implementation as is (?)

[vshcherb]

@sonora Thanks for investigation! Do you suggest any special GPX recording settings to set for @nbrr? Like minimum recording speed, minimum error or something like that?

@sonora Independent question, did you consider to change some default GPX recording settings that we have today?

[sonora]

Both are tough questions.

I can primarily think of two key use cases for tracks recorded in OsmAnd:

Case 1 are the more casual users who will record tracks in OsmAnd and primarily view and analyze them only within OsmAnd.

For these tracks it is key that as recorded they immediately resemble as much as possible the corresponding real life shape and distance.

In order to achieve that, points should be recorded at least significantly (e.g. 5 times) further apart than the lateral accuracy, but close enough together to still be able to approximate the true shape of a track (i.e. not shortcut corners, true bends and curves, or narrow mountain switchbacks too much).

As an example , if the lateral hdop accuracy is 10 m, points on not too curvy trails could e.g. be recorded on average 50 m apart. If your speed is of the order of 10 km/h, this would mean a recording interval of 15 seconds. (Or alternatively choose a short recording interval of 1 or 5 seconds with the minimum displacement filter set to 50 m.)

Case 2 are tracks which will be analyzed or post-processed in advanced tools outside OsmAnd, and for these a high sampling rate to initially capture more data and improve statistics for later compression algorithms , and definitely the absence of any filtering at recording time may be key.

The situation seems also device dependent, I think different devices already apply different pre-processing before passing on GPS data to Android.

As a result, I think

• we should stick with not applying recording filters by default, they are reserved for users who explicitly understand the consequences
• but maybe we could somehow show the users (e.g. on the recording dialog?) recommendations for a useful choice of the recording interval, e.g. 1 min or more for walking, 15-30 seconds for jogging, 10 seconds for cycling, and 5 seconds for recording a driving track in high definition.