Fill elevation and filter

Andrew Heard shared this idea ago

Declined

When I generate a route with BRouter I am yet to see a total ascent estimate that is less than the actual recorded track. This is hardly surprising given the SRTM height data and method of calculation. The route chart often contains a lot of artificial noise. The calculation is generally worst where the terrain is more hilly. Just the situation where it may matter the most in deciding a choice of route.

There is already a track function to "fill elevation" however this can be performed multiple times and won't change subsequent values. My suggestion is that a 2nd pass of the function or new menu "Fill and filter" would apply an appropriate low pass filter to the track to remove high frequency components.

I like this idea 0

Replies (1)

Menion ●

Good day Andrew,

from what you wrote, you get also quite noisy values even after using "Fill elevation" feature? This is a surprise for me, because I expected that interpolated values from already filtered data (hgt files), should be quite stable without obvious noisy values. You are using hgt files downloaded over Locus? Are you able to share with me your track, so I may use it for quick check/test? Thank you

URL

Andrew Heard ●

Thanks menion. I'll make a proper reply after finishing the 2 months cycle tour in a weeks time.

URL

Andrew Heard ●

In 2 screen captures below the "R" file is calculated Route, "T" file is actual track recording: d32869e988782c2953c1a25f3ed8d7ed

You can see in this second one some really sudden gradient changes on the peaks of the green line, whereas the actual red line has generally more rounded real-world peaks. I would expect appropriate high pass filtering would reduce these peaks slightly and give improved estimates of the total ascent...

26649cd12fa75fe85e1b7ef9b05febd0

URL

Menion ●

Good evening Andrew,

thank you for your screenshots. From what I see on both of them, sometimes recorded track has more fluent values, sometimes opposite.

For interpolating of values from HGT files is used bi-cubic interpolation so even these values are partially "filtered" by this type of interpolation which consider not just two points (like common linear interpolation), but four points (result is interpolated from 16 points - grid 4x4 points).

So sorry, I'm declining this idea. Extra filtering of interpolated elevation values seems to me like extra step that should not be needed in this case.

URL

Andrew Heard ●

No worries. I think part of the "problem" is that total ascent when displayed as field on dashboard is different (significantly larger from memory) then when the track recording is stopped and the track total ascent statistic is then checked. I don't have any figures because the dashboard numbers are reset to 0 as soon as you stop recording, but I vaguely recall some forum discussion about this a while ago too?

URL

Menion ●

Ah, I've forget to answer on this.

This is quite possible. Filter used during track recording is different then filter used after track is finished. It¨s because during recording I filter only from already recorded data (so only current location and few locations back) - logically. When track is stored, I may use different filter where is considered few locations back but also few locations forward. So results are currently little bit different.

URL