estimated elevation for a route in the montain?

[EssBee59]

Helo, I was last week in the french Alpes with my fastbike and compared the elevation of a route calculated/estimated with the brouter-web with the corresponding recorded track (of course more accurate) This route was calculated at home and tracked last week: http://brouter.de/brouter-web/#map=12/44.3421/6.6386/standard&lonlats=6.643936,44.386329;6.593828,44.297144

On this route, the estimation for elevation with brouter-web is nearly 20% higher as in the track Using Osmand and Brouter for routing, the difference is higher, with the route-converter the difference is very high Is it possible to get a better estimation for elevation?

2019-08-30_08-43_Fri.pdf As the "gpx" format is not suüüorted for attachements, I renamed the ".gpx" into ".pdf" 30.08.2019_Bis.pdf Here an other recorded track with more points! (rename "pdf" to "gpx")

[poutnikl]

All estimation methods involve estimation errors. given by estimation model like SRTM.

Recorded tracks bring their own, different errors.

Barometric altitude bring errors via improper or not frequent recalibration, due pressure and temperature trends.

GPS altitude brings huge error in altitude fluctuation artefacts.

Matching estimation and recording means involving altitude filtering in such extent that it compensates measured altitude errors to estimated altitude errors.

Underfiltering and overfiltering lead to mismatch of the total altitude difference. The point is, the proper filtering is not known. 20% is very nice result.

Additionally, BRouter implements filtered ascend, that differed from classical filtering, based on altitude hysteresis.

[EssBee59]

Hello Poutnikl,

First of all, Brouter is for me the best Routing system I know, as it supports not only a lot of profiles but Freely configurable routing profile! I opened this issue because I was "suprised" to find differences between the estimation and the recorded track (that exactly corresponds to the street!)

The Problem again in detail: Only few users are with bike on road in the montains (saying 2%) This users are only max 1 week per year in the montains ==> only 0,04 % of the Routings applies in mountains!

20% difference in the estimation of Elevation using brouter-web is not bad, but Osmand+brouter had more difference. (the worst estimation I found was GarminBasecamp with nearly 40%) It seems, the Problem is due to the differences between the elevation of the ground and the street above: On my route, the calculated track goes up and down, but the street (using bridges and co..) goes only up (exactly as the recorded track).

For Elevation estimation in mountains (and only for this 0,04%) I intend in the future to use recorded tracks (not calculated!)!

• recorded tracks are more occurate
• in the montains you generally have only 1 road available , so you find easily a track for each pass, and Routing is not necessary

Regards

[EssBee59]

I just forgot above to mention, that the "20%" difference calculated in the ascend of the pass is generally growing to 40% when you descend the pass to return home.

[nrenner]

@EssBee59 You mentioned sending (by E-Mail?) the recorded gpx in #182, but that somehow didn't work. You should be able to attach files to this issue, ideally by editing the first comment with "..." > "Edit". See the line at the bottom of the text input field where it says "Attach files by dragging & dropping, selecting or pasting them.", e.g. by clicking on that line, which then shows a file selection dialog.

[nrenner]

20% difference in the estimation of Elevation using brouter-web

How do you calculate that difference, i.e. how can I reproduce?

Are you using the "Ascend" (de: "Aufsteigend") value in the bottom statistics bar of BRouter-Web, which is "1.378 m" for the link above?

And comparing it to what (where do I get the other value from)?

[EssBee59]

Hello, Underway I had only my smartphone: So I had a look at the recorded track (see above 2019-08-30_08-43_Fri.pdf ==> rename it into 2019-08-30_08-43_Fri.gpx) with GPX viewer and Osmand: Osmand using this track indicated 1.117 meters ascending GPX Viewer using this track indicated 1.145 meters ascending

Yesterday I checked again at home on my PC: Brouter-web calculated / indicated 1.378 meters (aufsteigend) Osmand+Brouter calculated / indicated 1.459 meters ascending, 341 meters descending Route-Converter calculated / indicated 1.896 meters ascending, 780 meters descending BaseCamp calculated 1.894 meters ascending 782 meters descending

As explained above, a Routing to the top of the pass and then back to the start point leads to higher differences… I think, the exceptional effect is very specific to a route in high montains.

[poutnikl]

In fact,the effect is quite normal.

If an application calculates ascend from calculated or (worse) from noisy GPS altitudes, the ascend can be routinely twice as much, compared to Brouter filtered hysteresis based ascend.

Then, depending on filtering depth, the total ascend gets reduced.

It occurs in near any but flatland terrain.

Note that the total ascend should not be confused with simple ascend start to destination altitude difference . That can be calculated easily.

[EssBee59]

Hi,

I compare again the elevations by a tour in Hermany/Hessen 2 days ago:

• Estimated with Brouter-web 509 meters
• Recorded track 488 meters Brouter-web made a very good estimation, and I think, only in very rarely / exceptional situations, the estimation is not occurate. Workarround for "passes" in high mountains: Download and look at a recorded track!

A simple "warning" for these exceptional situations in the documentation should be for me ok, and the issue can be closed.

[Phyks]

Looking at the GPX trace, it seems as well that the precision is not so good from time to time (for instance close to "Les Agneliers"). Your track does not follow the OSM road very precisely (either from your GPS device or because the OSM road is not well drawn).

This should also have an impact on the computed elevation since BRouter assumes you follow precisely the OSM road and computes elevation from there, as far as I know.

[EssBee59]

Looking at the GPX trace, it seems as well that the precision is not so good from time to time (for instance close to "Les Agneliers"). Your track does not follow the OSM road very precisely (either from your GPS device or because the OSM road is not well drawn). This should also have an impact on the computed elevation since BRouter assumes you follow precisely the OSM road and computes elevation from there, as far as I know.

Hi Phyks, As a bike friend recorded also the same track with more details last week, I added the gpx above (30.08.2019_Bis.gpx) Regards Ess Bee

[abrensch]

so no real issue here, just known limitations of SRTM -> closed