Incorrect elevation data on the map

[anastasiia936]

In the track created via the Plan route option the elevation change (Aufstieg / Abstieg) is displayed as 21 and 39 meters, but the actual route is nearly perfectly level like the small river in parallel. Obviously the wrong values are caused by the bridge that crosses the valley.

[vshcherb]

Yes we could detect that situation based on map data as we process cause we know there is a bridge over that place

[scaidermern]

I guess this needs to be fixed dynamically? If you pass under the bridge then the previous elevation needs to be kept. If you pass across the bridge then the elevation from the data must be used.

[yuriiurshuliak]

The user emphasizes that the higher the altitude, the greater its error. Sometimes it is reduced by 30-40%. This was compared to a dedicated GPS device. The app was updated and the altitude correction was uploaded.

[Fedsmachine]

Elevations are actually INCREASED not decreased.

[sonora]

Is this for a recorded trip or a planned one using SRTM elevation data?

Root cause is probably that elevation gain/loss is not a precise science. Depending on the strategy applied, undulations could either be counted and accumulate over the time of your trip, or are disregarded. The "art" is to correctly guess which types of undulations are due to terrain and motion vs. which are noise like random fluctuations or bad reception. Under-filtering produces too high elevation gain/loss estimates, over-filtering too small.

In the previous strategy we used, I had programmed a trend channel approach where the delta between every beginning and end of a trend channel was counted if at least 5 veetical meters, and otherwise neglected. This takes out all low-amplitude noise, while for high amplitude fluctuations it counts the overall amplitude neglecting any interim noise.

A while back we changed to a new algorithm, which I could not explain as readily.

[vshcherb]

@yuriiurshuliak we don't have a goal to have exactly same number of Garmin, it's not a standard to measure Uphill / downhill and it's algorithm is not open, so this is a irrelevant case.

[vshcherb]

@sonora from now we consider to take an integral approach to calculate uphill / donwhill. It means we will use green graph as a reference i.e. if 1st deriviate > 0, it will accumulate uphill as integral, < 0 downhill. It will be visual & easy testable approach.

In case data of 1st derivative won't be correct we will take specific ways to test it and fix it.

[Fedsmachine]

I have travelled with others with several GPS devices (Wahoo, Garmin) and apps and for some reason OSMand is always 20-40% too high in terms of elevation calculations. It makes route planning and day planning difficult so I have to use other apps to route plan. I still live it for navigation.

On Mon, May 29, 2023, 4:37 p.m. vshcherb @.***> wrote:

@yuriiurshuliak https://github.com/yuriiurshuliak we don't have a goal to have exactly same number of Garmin, it's not a standard to measure Uphill / downhill and it's algorithm is not open, so this is a irrelevant case.

— Reply to this email directly, view it on GitHub https://github.com/osmandapp/OsmAnd/issues/12306#issuecomment-1567534479, or unsubscribe https://github.com/notifications/unsubscribe-auth/A75PVFSFAF57ZQTVDZYM3G3XIUJJVANCNFSM5BGLSTGQ . You are receiving this because you commented.Message ID: @.***>

[vshcherb]

@Fedsmachine how do you treat which numbers are correct? 20-40% sounds not much but it's still not clear what it means, obviously counting all points gives higher numbers in uphill / downhill but it's not clear how low uphill / downhill should be

[Fedsmachine]

40% error on a 2,000 m day is a lot on a bicycle.

On Tue, May 30, 2023, 9:18 a.m. vshcherb @.***> wrote:

@Fedsmachine https://github.com/Fedsmachine how do you treat which numbers are correct? 20-40% sounds not much but it's still not clear what it means, obviously counting all points gives higher numbers in uphill / downhill but it's not clear how low uphill / downhill should be

— Reply to this email directly, view it on GitHub https://github.com/osmandapp/OsmAnd/issues/12306#issuecomment-1568520333, or unsubscribe https://github.com/notifications/unsubscribe-auth/A75PVFVOG2PSGAZZ3745CY3XIX6UHANCNFSM5BGLSTGQ . You are receiving this because you were mentioned.Message ID: @.***>

[sonora]

Victor is right: There is no "truth", it's a fractal situation. And this is not ideology but pure signal processing: It is all about noise, and with that about the question: "What type of fluctuation do we want to ignore because we consider it a likely measurement artifact, vs. what do we want to keep as an effect significant for travel". (Elevation gain/loss for an ant hiking up a mountain and climbing millions of pebbles is completely different than for a human hiker stepping over most pebbles.)

I advise we answer the noise question first. The corresponding algorithm to use, like frequency filtering, moving average, amplitude cut-off, trend channel, etc. needs to be derived, not selected up front.

By my testing the current OsmAnd implementation is quite in line with many "conventional" analysis tools, as long as you don't oversample tracks, which unfortunately many users think increases accuraccy, while it also increases noise. If you limit your sampling rate to e.g 1/30sec for hiking, you will likely find the results quite agreeable.

[Fedsmachine]

Thanks for the explanation. How about setting a route? Is there a way to make that more accurate? That is more important for me. I import the GPX file and look at the data on the track that shows elevation gains. I also will set the track using OsmAnd and use elevation data.

On Tue, May 30, 2023, 5:46 p.m. Hardy @.***> wrote:

Victor is right: There is no "truth", it's a fractal situation. And this is not ideology but pure signal processing: It is all about noise, and with that about the question: "What type of fluctuation do we want to ignore because we consider it a likely measurement artifact, vs. what do we want to keep as an effect significant for travel". (Elevation gain/loss for an ant hiking up a mountain and climbing millions of pebbles is completely different than for a human hiker stepping over most pebbles.)

I advise we answer the noise question first. The corresponding algorithm to use, like frequency filtering, moving average, amplitude cut-off, trend channel, etc. needs to be derived, not selected up front.

By my testing the current OsmAnd implementation is quite in line with many "conventional" analysis tools, as long as you don't oversample tracks, which unfortunately many users think increases accuraccy, while it also increases noise. If you limit your sampling rate to e.g 1/30sec for hiking, you will likely find the results quite agreeable.

— Reply to this email directly, view it on GitHub https://github.com/osmandapp/OsmAnd/issues/12306#issuecomment-1569230649, or unsubscribe https://github.com/notifications/unsubscribe-auth/A75PVFQIJ7S5CHFSUYPXBP3XIZ2EVANCNFSM5BGLSTGQ . You are receiving this because you were mentioned.Message ID: @.***>

[vshcherb]

The real data is only "KWh" spent on bicycle or by foot, that allows to measure relief, obviously measuring it correctly is very tricky....

[sonora]

@Fedsmachine Setting a route is no different: The "noise question" to be decided is then in our elevation data (SRTM, etc.).

As an example of how to solve the "noise" question:

• My previous approach was to say "Trends which break before reaching 5m vertical change are neglected, trends which exceed that are counted.".

Brief discussion:

• That principle implies that (mountain) hikers are not usually worried about <5m undulations, as long as all elevation changes of greater amplitude are accumulated correctly.
• Naturally, a 'dune hiker' or a surfer straddling small undulations all day ling would get 'under-estimated'. 😉
• And the principle is sensitive to large singularity outliers - they count full unless detected as measurement artifacts and filtered.
• The principle is also comparatively insensitive to oversampling, because the 5m-amplitude limit triggers if a vertical change is considered as contributing to an elevation change, but the actually change is then taken from the trend, ignoring any interim fluctuation.

[vshcherb]

@sonora I think we should align model to terrain SRTM data, it's well maintained, it doesn't have infinite scale problem (i.e. fractal) we could calculate interpolation based on it and it will be consistent result doesn't matter how many points we put on the track 100 or 10000

[sonora]

@vshcherb Yes precisely, valid idea!

The limitations are, naturally, surface-independent motion (e.g.airborne) or steep terrain (e.g.cliff climbing), where recording will beat modeling, of course.

[vshcherb]

We already have Elevation correction (in Track / Plan Route), so it's worth to test it out.