GPX analysis: Should the 'Maximum Speed' value be averaged in some fashion?

[YuriySamorodov]

Description

It looks like OsmAnd 3.8.2 show incorrect speed from GPX files created in Fuelio app. Here is the file I was testing with (archived due to GitHub restrictions): route-1601046458340.zip

I was driving lately at 74-76kmh at max. Fuelio recorded the speed correctly: Quite unfortunately Fuelio](https://play.google.com/store/apps/details?id=com.kajda.fuelio) does not allow to review speed in a specific point. So I tried to use OsmAnd for this. I was a bit shocked to see like I was driving at 125kmh according to OsmAnd:

Troubleshooting

Made a review of unit settings Changed speed from kmh to mph and back Changed distance from km/meters to miles/feet and back Opened the same GPX file in GPX Viewer. This app was also showing correct values. Opened the same file in GPXSee. Got 74.5kmh max speed. Checked GPX Online viewer uTrack. It provided 75.4kmh (please see attached pdf utrack_crempa_net_route.pdf

How to reproduce?

1. Record GPX track in Fuelio app (or use route-1601046458340.zip)
2. Open GPX file in OsmAnd (should be located in /internal shared storage/Fuelio/routes
3. Open GPX file in GPX Viewer
4. Open in GPXSee
5. Compare speed values

Your Environment

OsmAnd Version: 3.8.2 Android/iOS version: - Device model: OnePlus 5T

Maps used (online or offline):
online (unrelated)

GPX file route-1601046458340.zip

[sonora]

Thanks for reporting, couple of remarks here:

(1) The track you enclose does not match your OsmAnd screenshot. Instead, the track route-1601046458340 you enclose, in OsmAnd produces average speed 15.8 km/h and max speed 99 km/h.

(2) I ran the track through https://geo.javawa.nl/trackanalyse/index.php?lang=en, and in deed they also show Max speed 98.8 km/h. In both OsmAnd and their speed graph you can see that the single spike in your data defining this maximum is near the 6.5 km mark. Meaning this is not a calculation bug per se, but a feature in the recording. (Their avg. speed depends on your selection of the lower speed cut-off parameter, choosing 1km/h yields 16.7 km/h, in line with our 15.8, we have cut-off >0).

(3) The track you enclosed does not contain any native speed data (recording the track in OsmAnd and numerous other tools would have included this if delivered by the GPS chipset). In cases where this GPS-measured data is missing, OsmAnd's track analysis uses a fallback deriving effective speed data by your location and time stamps (indicated by a red instead of an orange speed graph).

(4) If you tap in the OsmAnd speed graph for the track then swipe the marker left/right, you can see how noisy data this produces for this particular recording.

(5) OsmAnd does not apply any filtering or smoothing for this approximation, in other words, OsmAnd delivers you the most detail it can produce from the data (and also shows the amount of noise contained). The only value notably affected by this fact is the "Maximum Speed", as this is the precise value determined by the single max data point (which may be a point in the noise).

Some, not all, other tools apply smoothing or filtering, making different (and mostly undocumented) assumptions about how speed values can or cannot change over time. Quite obviously, such a parameterization strongly depends on if you are walking, cycling, in a car, or in an airplane, on the signall/noise ratio of your recording, and also on your sampling rate how many points you record per interval (on long trips maybe just one per 5 minutes?). I am at this point not sure if it really makes sense to develop a formula for something like "Maximum speed corrected for what is assumed to be an artifact". But I may come back to this if I find time.

[sonora]

I've been looking at a number of tracks now, and this really only matters for rather noisy ones.

Maybe we should leave it as simple as is: The maximum is the maximum.

If you have noisy data with spikes, the very purpose of our track analysis is you can always tap into the speed graph and find the speed for any point you deem relevant for your current purpose.

[YuriySamorodov]

I've been looking at a number of tracks now, and this really only matters for rather noisy ones.

Is there any way to filter noisy spikes? It would be really nice feature to have

[sonora]

Chances are the best filtering to apply is the one implemented in your chipset, i.e. use a tool to record your trips which does include the chipset-generated speed values in your GPX files (like OsmAnd).

As for additional filters, OsmAnd has a choice of user-selectable filters available at recording time, e.g. accuracy, but with OsmAnd recordings you may not even need these.

When it comes to the analysis of already recorded tracks, that's an entire science, most of which is better left to dedicated post-processing tools (google e.g. Douglas-Peucker for a great way to compress data), and these again work best with data not previously filtered. (Hence we only use trend channel analysis for elevation, nothing else.)

Having explained all that, your case here is less far-reaching: The question is simply if our display for the "maximum speed value" should literally display the data set's "maximum recorded value" (as is today), or make some assumption and show a deviating value (which would demand explanations, or raise secondary issues ...)

[sonora]

In summary: Your track exceeds 76 km/h on 3 different occasions. I have trouble finding objective criteria to say that these are not real.

(Or if we discarded these, based on what mechanism would you select a new value you trust is real?)

[YuriySamorodov]

76kmh is correct. What does not seem correct is 98kmh or 125kmh

[sonora]

Question is how to tell from the data: I often log long car trips with 1 point every 30 sec, and there these points are totally real.

[sonora]

Wrapping this up, I recommend not performing any outlier correction in OsmAnd itself , because it is unclear by which criteria we could distinguish applicable data points from artifacts.