Limit gradient scale in chart to something reasonable instead of autoscaling to silly values

Andrew Heard shared this idea 3 years ago
Completed

Does it make sense to autoscale the chart gradient to +/-200%? In my case (screen capture below) these are very nonsense values that Garmin Basecamp has calculated; I have no easy/ convenient control over them. Maybe limit/ clamp any outlying values to no more than +/-90%, or maybe even ignore these values? What does a value > 90 even physically mean? Maybe it could be an import setting? Only then autoscale the remainder of the values. Thank you.5fbb8acc4d8602131ce3a63325574db2

Comments (26)

photo
1

Based on this idea http://help.locusmap.eu/topic/improve-change-of-altitude-track-style-mode , I created a lot stronger filter for gradient to eliminate huge jumps based on even a small change of altitude on really short distance.


You'll see in next version, but I believe it will be a lot better now.

photo
1

Thank you - yes it looks a lot better now in 3.7.0.

photo
1

Perfect, glad to hear it.

photo
1

I just created a new track with 3.13.0/ BRouter, and mainly with fast bike profile - see attached, all normal process, but there are 3 huge negative spikes in the gradient which make the chart unusable - gradient -400% - I don't think possible (!). I won't follow that route on my bike over the cliff. It would be an additional improvement to completely ignore these impossible values (as I originally suggested) before any filtering step.

7eff92395721f0083e271bb486e395c7


PS. I had to add ".txt" to file to be accepted. Do you have any control over which file types are accepted? Surely a GPX file is a reasonable file to upload, and shouldn't need to resort to silly ".txt" trick to fool the website into uploading. Maybe confusing for other forum users too.

photo
1

Well and what you expect Andrew when computed track force you to jump 7 metres :).


Check line 3189 in file (14.25 m) vs next 3192 line (7.5 m).


And attachments - I!m aware of this problem, have to write to developers of this system what to do with it.

photo
1

You would have to agree the value of -400% has made the gradient graph totally useless to view. This is not an imported track where an argument could be mounted that all elevations must be accepted, but a track created by BRouter. A value of -400% is about -75 degrees. For a fast cycling profile this is clearly a bogus value. As I already said I'd expect/ hope these values to be ignored prior to the filtering step. Yes I fully understand a 7m step change has caused this bogus value.

photo
1

Andrew, I absolutely agree that such value is total nonsense for bike ride. Anyway you cannot expect that Locus should automatically ignore such values. What about cases when such value make a sense and it is expected value?


My practice is, that when I download any track with such crazy values, I then use function "Fill altitude" that for me in all cases fix incorrect altitude values in any track.

photo
1

>Anyway you cannot expect that Locus should automatically ignore such values

it could ignore such values in situations where it knows they are nonsense, but not to pursue this impossible dream further because...


...I've never used the "Fill alitude" function before. Thanks a lot for making the suggestion. That's a reasonable compromise. The spike reduced from -400% to -30%, and now I can see Y-axis detail for the gradient.

photo
1

Both Locus and Brouter use SRTM3 altitude data based on 90x90m space shuttle radar survey.

Everybody who uses these data should know there are many SRTM artefacts. Some are just data errors, and some of them are corrected. I supose there may be more SRTM3 versions, with different error correction progress. Also, some software may use SRTM data or track altitude filtering.

But some artefacts are related to fact how terrain features affect averaging of 90x90m radar altitude data. Sources of artefacts causing sharp SRTM altitude jumps are mainly:

narrow valleys, rivers, forest passages, urban areas, tunnels, bridges.

That is the reason why Brouter uses 10m altitude hysteresis filter, that is filtering out many, but not all artefacts, as it is a trade-off between filtering and distorting.

Once can have 20-30 m artefact jump in few metres, if you review SRTM altitude profile of a route you are familiar with.

photo
1

I now have a phone with a pressure sensor, and testing shows the altitude accuracy is far greater, far more reliable, far closer to known elevations on a topological map. However on a recent 600km ride I again experience a single track point which totally skews the gradient graph with silly autoscaling - gradient less than -150% ! Unlike previous phone where it may made sense to filter a track, I don't think this should now be necessary.

0d9294aae5ddfdbb09a6e13e75e40c88

GPS track at - https://drive.google.com/open?id=1aQ-HbrmGdySpIrr4lWUmFqaGs04hbC1Z

I eventually find this single bad track point using Garmin Basecamp point #20078 has zero metre leg distance. 52f259411714e7644274c2dfae4bfc1c


When I deleted this point and re-imported into Locus, the gradient chart is more reasonable -10% to +5% gradient. Unlike previous discussion is it therefore reasonable to ignore points with leg distance = 0m?

I note there is an abrupt jump in elevation from -7 to -15m but it appears this is not the cause of the gradient spike.

Locus Pro 3.32.2 GPS settings:

  • optimize GPS values
  • use pressure sensor
  • light filter

photo
1

Just a few versions ago I added this condition: compute gradient only in case of non-zero distance. Anyway seems here distance (leg) won't be exactly 0m, but something close to this. Hmm, I'll try to set this condition to 0.25m as the minimal distance (for real slow-walkers). This should help here.

photo
1

Thanks Menion. Will I be able to check/ verify/ notice any change with this existing track chart when the new Locus version is available? Or will it only affect newly recorded tracks?

photo
1

Chart is always generated as new, so changes in this will affect the chart immediately.

photo
photo
1

There is perhaps possible, in case of longer trip stop with paused logging and drifting pressure ( easily equivalent to 20 alt meters per hour for barometric altitude) , that subsequent points at resumed logging create a sudden change in supposed altitude.

photo
1

Libor - I just checked the map - indeed the 0m gradient spike occurred at a location where I was off the bike for 10 minutes although I didn't pause track recording, so the pressure should have only varied very slightly in that time.

photo
1

Not even autopaused due constant location threshold ?

photo
1

Correction - on closer observation I was not even stationary at the time of 0m glitch. The spike occurred about 500m before this point; I was riding at ~15km/h at this specific track point along a flat road. So no explanation from physical reality.

photo
1

Hmm. But in spite of altitude having barometric accuracy, position has GPS accuracy. In case one get for proper elevation change too short distance change, the result is a slope spike.


This is the reason an accurate barometric altitude may provide more noisy gradient profile,

compared to SRT based profile.

because

photo
1

Thanks Libor but certainly in my recent testing with my SRTM data, the pressure sensor has been far better. With the SRTM grid in places where the road traverses hilly terrain the altitude as estimated with SRTM data can be wildly inaccurate.

photo
1

Hi Andrew.

You may have misunderstood me.


The barometric altitude profile is indeed much better than SRT based one. But for the altitude alone. If the gradient is considered, its calculation is affected by GPS position error.


Purely GPS based gradient is affected by both position and altitude error.


GPS/SRTM based gradient has the least error of all three, as the local errors for altitude and position are correlated and partially cancel each other.

photo
photo
1

Hmm this is very good point. And quite hard to solve I think. Any ideas? Compare by time needed to travel leg? Not ideal for some climbing activities :).

photo
1

What about some deviation threshold check, the value being overwritten by a suitable interpolation if the threshold is triggerred ? Like to compute running standard deviation with threshold somewhere between 2-3 sigma ? Just thinking.

photo
1

P.S.: Or, for the chart, to run statistics and use e.g. 3 sigma scale for the gradient values, cutting out outlyers.

photo
1

The chart is already heavy filtered. My algorithm is based on making the weighted average from before and after 250 meters (or nearest 10 points) around the point, where in case of the slope, is used the strongest parameter that should throw out all these crazy values.

Anyway, I've added your tip to my private notes related to this topic, thanks.

photo
photo
1

Note that 20m/hour is typical value lasting many hours before a warm front. Before and after a cold front, the rate can be several times higher.

, Even if duration is much shorter.

Edit: what about to interrupt calculation of gradient at paused,autopaused, stationary like state? It could be used an Interpolation instead. It would eliminate such a jumps.

photo
1

Yet another example of invalid elevation measurement attached. New Samsung phone, nothing extraordinary. See below the second track point dips by 32 metres. The 3rd & subsequent track point elevations stabilize around correct ~213m. I don't see any chart heavy filtering - the gradient is displayed as -60%. Backstory to this track record: exit house, turn on phone, turn on Locus (settings: auto track record, GPS enabled at start), tap Satellite icon-button, wait for GPS to lock (~20s), ride, enjoy.

<trkseg>
<trkpt lat="-42.981888" lon="147.180609">
	<ele>206.80</ele>
	<time>2018-11-07T00:25:43.000Z</time>
	<course>162.600</course>
	<pdop>7.00</pdop>
</trkpt>
<trkpt lat="-42.981939" lon="147.180647">
	<ele>172.70</ele>
	<time>2018-11-07T00:30:22.000Z</time>
	<course>200.000</course>
	<pdop>4.00</pdop>
</trkpt>
<trkpt lat="-42.982110" lon="147.180865">
	<ele>213.65</ele>
	<time>2018-11-07T00:31:13.000Z</time>
	<course>114.800</course>
	<pdop>4.00</pdop>
</trkpt>