Calculated elevation gain too big
Answered
I'm having a problem with the calculated elevation gain for a newly planned route. Locus calculates up to twice as much elevation gain as there actually is. The route is planned on a single road, and other apps like CycleTravel calculate the elevation gain relatively accurately.
The same question
Today i have make it with a Garmin Edge 1030.
Edge 1030 - 906 HM
Locus calculate - 1770 HM
CycleTravel calculate- 890 HM
Locus is complete wrong.
Today i have make it with a Garmin Edge 1030.
Edge 1030 - 906 HM
Locus calculate - 1770 HM
CycleTravel calculate- 890 HM
Locus is complete wrong.
Hi Wolfgang,
could you please send a GPX or a weblink to the route? Thanks.
Hi Wolfgang,
could you please send a GPX or a weblink to the route? Thanks.
... the GPX and a Screenshot where i have refresh the data of the altimeter
Gesendet von Outlook für Android
... the GPX and a Screenshot where i have refresh the data of the altimeter
Gesendet von Outlook für Android
Does such a big deviation occur also on another route?
Does such a big deviation occur also on another route?
Yes, Limone - Tremalzo - Riva del Garda are 4700 HM. In real u think 1900
Yes, Limone - Tremalzo - Riva del Garda are 4700 HM. In real u think 1900
I tested the first route in GPXSee application giving the same result as Locus Map. Then I downloaded the latest custom 1'' lidar elevation data to the app (https://sonny.4lima.de/), the result was 1400m elevation gain with 5m threshold. Only when I set 20m threshold (meaning that the app ignores all hills smaller than 20 m on the route), the result was 925m. That means that the competitive apps calculations are probably strongly generalized.
I tested the first route in GPXSee application giving the same result as Locus Map. Then I downloaded the latest custom 1'' lidar elevation data to the app (https://sonny.4lima.de/), the result was 1400m elevation gain with 5m threshold. Only when I set 20m threshold (meaning that the app ignores all hills smaller than 20 m on the route), the result was 925m. That means that the competitive apps calculations are probably strongly generalized.
Please help me to get the correct settings in locus maybe some instructions. Today i ride Limone-Tremalzo-Riva del Garde. My Garmin Edge 1030 shows ÷/- 2000 HM. Locus calculate 4700 HM. Your Settings for the first GPX shows 500 HM to much
Please help me to get the correct settings in locus maybe some instructions. Today i ride Limone-Tremalzo-Riva del Garde. My Garmin Edge 1030 shows ÷/- 2000 HM. Locus calculate 4700 HM. Your Settings for the first GPX shows 500 HM to much
The 20m threshold is maybe correct for me. How can i get the new elevation data in locus and how can i set there the 20m threshold ?
The 20m threshold is maybe correct for me. How can i get the new elevation data in locus and how can i set there the 20m threshold ?
By mere adding the approximate elevations of the individual hills on the route chart I calculated 3708 m. How can Garmin claim that it's just 2000m m for the whole 173 km route??
The threshold is set in the route editing screen, see https://docs.locusmap.app/doku.php?id=manual:faq:wrong_gps_data&s[]=threshold#custom_altitude_threshold.
Custom elevation data: https://docs.locusmap.app/doku.php?id=manual:faq:how_to_add_map_shading#custom_elevation_data_sources
By mere adding the approximate elevations of the individual hills on the route chart I calculated 3708 m. How can Garmin claim that it's just 2000m m for the whole 173 km route??
The threshold is set in the route editing screen, see https://docs.locusmap.app/doku.php?id=manual:faq:wrong_gps_data&s[]=threshold#custom_altitude_threshold.
Custom elevation data: https://docs.locusmap.app/doku.php?id=manual:faq:how_to_add_map_shading#custom_elevation_data_sources
I write Limone - Tremalzo - Riva ;-) ... and my mistake is that locus calculate 4500 and not 4700 ... look at the screenshot
I write Limone - Tremalzo - Riva ;-) ... and my mistake is that locus calculate 4500 and not 4700 ... look at the screenshot
I see, you used a "touring" routing profile. With this, the route looks like this, using custom elevation data and altitude threshold 3m:
I see, you used a "touring" routing profile. With this, the route looks like this, using custom elevation data and altitude threshold 3m:
Thanks for your answers. With these settings, it's still 800 meters too much, which is still too imprecise for planning. Cycletravel calculates 1900 meters and that corresponds to what I drove. I'll take look at it after my holiday.
Thanks for your answers. With these settings, it's still 800 meters too much, which is still too imprecise for planning. Cycletravel calculates 1900 meters and that corresponds to what I drove. I'll take look at it after my holiday.
woher weist du damit Cycletravel den richtigen Wert hat. Ich habe schon gehört damit die Werte nicht stimmen. Komoot und Strava liegen auch falsch. Ich habe viele Strecken geprüft und Locus war ganz nah an der Realität. Gemessen mit sehr genauem gps inkl. sehr genauen Höhendaten und auch Barometer.
woher weist du damit Cycletravel den richtigen Wert hat. Ich habe schon gehört damit die Werte nicht stimmen. Komoot und Strava liegen auch falsch. Ich habe viele Strecken geprüft und Locus war ganz nah an der Realität. Gemessen mit sehr genauem gps inkl. sehr genauen Höhendaten und auch Barometer.
Weil ich die Tour ( und auch einige andere Touren ) kenne, sie in jedem Führer so beschrieben ist und ich sie mit dem Edge 1030 mit Barometer gefahren bin. Wenn du die Strecken auf den Tremalzo kennst dann weist du das es nie und nimmer 4500 HM sind und 4500 HM würde ich an einem Tag nicht schaffen. Ich zweifle nicht an Locus ich habe nur die Vermutung das an meinem Locus was verbogen ist. Falls du einen Tipp hast was da schief läuft bin ich dir dankbar. Ich bin von Locus begeistert aber die Höhenmeter bei Cycletravel entsprechen halt eher der Realität.
Weil ich die Tour ( und auch einige andere Touren ) kenne, sie in jedem Führer so beschrieben ist und ich sie mit dem Edge 1030 mit Barometer gefahren bin. Wenn du die Strecken auf den Tremalzo kennst dann weist du das es nie und nimmer 4500 HM sind und 4500 HM würde ich an einem Tag nicht schaffen. Ich zweifle nicht an Locus ich habe nur die Vermutung das an meinem Locus was verbogen ist. Falls du einen Tipp hast was da schief läuft bin ich dir dankbar. Ich bin von Locus begeistert aber die Höhenmeter bei Cycletravel entsprechen halt eher der Realität.
You're not seeing 4500 meters of elevation gain. You confirmed that just a moment ago. Try to get accurate elevation data from Sonny.
You're not seeing 4500 meters of elevation gain. You confirmed that just a moment ago. Try to get accurate elevation data from Sonny.
... und es geht mir nicht um ein paar Höhenmeter. Ich bin teilweise um 100 % und mehr daneben.
Limone - Tremalzo - Riva sind so ca. 2000 HM aber Locus berechnet 4500 HM. Daher die Vermutung das an meinem Locus was nicht passt.
... und es geht mir nicht um ein paar Höhenmeter. Ich bin teilweise um 100 % und mehr daneben.
Limone - Tremalzo - Riva sind so ca. 2000 HM aber Locus berechnet 4500 HM. Daher die Vermutung das an meinem Locus was nicht passt.
Mit den Standarteinstellungen ( Locus Map Italy North inkl. Höhemdaten )sind es 4500 HM ( siehe Anhang ). Die alternativen Höhendaten kann ich erst nach meinem Urlaub installieren.
Mit den Standarteinstellungen ( Locus Map Italy North inkl. Höhemdaten )sind es 4500 HM ( siehe Anhang ). Die alternativen Höhendaten kann ich erst nach meinem Urlaub installieren.
Das Problem ist wirklich, dass die Berechnung primär von der Datengrundlage abhängig ist - wie ja bereits hier im Thread erörtert - und das es eigentlich zwei (drei) Stellschrauben gibt, die je nach Datengrundlage großen Einfluß haben.
Die einfachste Gegenmaßnahme dürfte in der Tat die Verwendung hochauflösender DEM-Daten sein (wie sonny's lidar elevation data), weil die Höhendaten dann weniger Sprünge aufweisen und man ohne größere Nachbearbeitung die Auf- und Abstiegsmeter berechnen kann.
Anderenfalls bleiben nur die zuvor erwähnten zwei Stellschrauben, als das wären:
Und wie das Michal Stupka richtig aufführt, begibt man sich dann mitunter auf dünnes Eis, weil man die Daten künstlich neu moduliert, wenig Glättung gegenüber einer großen/hohen Glättung. Ersteres ist eher bei feinauflösenden Daten (sonny's lidar elevation Daten oder barometrisch protokollierte GPS Tracks) sinnvoll, zweiteres bei grob auflösenden Daten (SRTM1 und SRTM3 Daten und bei vielen rein auf GPS protokollierten Tracks).
Und dazwischen liegt leider eine große Grauzone, weil die grob auflösenden Daten manchmal Terrain bedingt doch gut passen, also eine hohe Glättung daher eher kontraproduktiv ist.
Falls es interessiert, anbei eine kleine Animation, die die Berechnung und die Auswirkungen dieser beiden Stellschrauben anhand deiner GPS-Datei illustriert.
Hier noch ein Blogbeitrag, der etwas mehr ins Detail geht:
https://wrpsoft.blogspot.com/2024/10/berechnung-der-auf-und-abstiegsmeter.html
Das Problem ist wirklich, dass die Berechnung primär von der Datengrundlage abhängig ist - wie ja bereits hier im Thread erörtert - und das es eigentlich zwei (drei) Stellschrauben gibt, die je nach Datengrundlage großen Einfluß haben.
Die einfachste Gegenmaßnahme dürfte in der Tat die Verwendung hochauflösender DEM-Daten sein (wie sonny's lidar elevation data), weil die Höhendaten dann weniger Sprünge aufweisen und man ohne größere Nachbearbeitung die Auf- und Abstiegsmeter berechnen kann.
Anderenfalls bleiben nur die zuvor erwähnten zwei Stellschrauben, als das wären:
Und wie das Michal Stupka richtig aufführt, begibt man sich dann mitunter auf dünnes Eis, weil man die Daten künstlich neu moduliert, wenig Glättung gegenüber einer großen/hohen Glättung. Ersteres ist eher bei feinauflösenden Daten (sonny's lidar elevation Daten oder barometrisch protokollierte GPS Tracks) sinnvoll, zweiteres bei grob auflösenden Daten (SRTM1 und SRTM3 Daten und bei vielen rein auf GPS protokollierten Tracks).
Und dazwischen liegt leider eine große Grauzone, weil die grob auflösenden Daten manchmal Terrain bedingt doch gut passen, also eine hohe Glättung daher eher kontraproduktiv ist.
Falls es interessiert, anbei eine kleine Animation, die die Berechnung und die Auswirkungen dieser beiden Stellschrauben anhand deiner GPS-Datei illustriert.
Hier noch ein Blogbeitrag, der etwas mehr ins Detail geht:
https://wrpsoft.blogspot.com/2024/10/berechnung-der-auf-und-abstiegsmeter.html
Hi Wolfgang, I analyzed the GPX-file of your 1st track. Please attach a GPX-file of 2nd track (Limone-Tremalzo-Riva del Garde) too!
Calculation of reasonable elevation Totals is not an easy chapter as you read in the upper posts. But there are a few things you can improve and also some other thing Locus could improve ;-)
1) Download Sonny elevation 1"-DTMs (for tracks in Europe). They are much more precise especially in hilly terrain like your tracks than the usual SRTM-DTMs provided by Locus by default. Unfortunately, locus has not yet found a solution to provide 1" Sonny files themselves instead of 3"-SRTM files to make life for their useres a lot easier regarding reasonable elevations.
2) you are using OSM ways to create your tracks. But these OSM tracks could be off here and there by several meters horizontally resulting in the elevation in rocky terrain also "wrong" by several meters. The same problem is true regarding vertical accuracy (but thats practically of less importance). This is why the so called "Threshold" (=elevation filter) is important: The more threshold, the more (faulty) elevation jumps are ignored. A Threshold between 5-10m is ideal for routes within hilly terrain. The steeper terrain around the ways, the more Threshold to use. Locus by default just uses a threshold of 3 m.
To Locus developers: I would advice to raise default threshold for Routeplanner as well as imported tracks up to 5, 6, or 7 m ! (3 m only make sense in Lowlands, but most people calculate Elevation Totals for hilly Highlands). And 2nd thing to improve: Right now bicubic interpolation is used to calculate elevation values from DTMs. But this method is just useful for image processing . Better use bilinear interpolation for elevation calculation, since calculated value is not (faulty) influenced by elevations farer away from current point than those used by bilinear method!
Obeying both points is all you can do - but the same time perfectly adequate to get better Elevation Totals:
3m threshold, using SRTM elevation provided by Locus: +1770 m | -1016 m
3m threshold, using Sonny elevation: +1400 m | -641 m
5m threshold, using Sonny elevation: +1282 m | -520 m
10m threshold, using Sonny elevation: +1122 m | -365 m
Hi Wolfgang, I analyzed the GPX-file of your 1st track. Please attach a GPX-file of 2nd track (Limone-Tremalzo-Riva del Garde) too!
Calculation of reasonable elevation Totals is not an easy chapter as you read in the upper posts. But there are a few things you can improve and also some other thing Locus could improve ;-)
1) Download Sonny elevation 1"-DTMs (for tracks in Europe). They are much more precise especially in hilly terrain like your tracks than the usual SRTM-DTMs provided by Locus by default. Unfortunately, locus has not yet found a solution to provide 1" Sonny files themselves instead of 3"-SRTM files to make life for their useres a lot easier regarding reasonable elevations.
2) you are using OSM ways to create your tracks. But these OSM tracks could be off here and there by several meters horizontally resulting in the elevation in rocky terrain also "wrong" by several meters. The same problem is true regarding vertical accuracy (but thats practically of less importance). This is why the so called "Threshold" (=elevation filter) is important: The more threshold, the more (faulty) elevation jumps are ignored. A Threshold between 5-10m is ideal for routes within hilly terrain. The steeper terrain around the ways, the more Threshold to use. Locus by default just uses a threshold of 3 m.
To Locus developers: I would advice to raise default threshold for Routeplanner as well as imported tracks up to 5, 6, or 7 m ! (3 m only make sense in Lowlands, but most people calculate Elevation Totals for hilly Highlands). And 2nd thing to improve: Right now bicubic interpolation is used to calculate elevation values from DTMs. But this method is just useful for image processing . Better use bilinear interpolation for elevation calculation, since calculated value is not (faulty) influenced by elevations farer away from current point than those used by bilinear method!
Obeying both points is all you can do - but the same time perfectly adequate to get better Elevation Totals:
3m threshold, using SRTM elevation provided by Locus: +1770 m | -1016 m
3m threshold, using Sonny elevation: +1400 m | -641 m
5m threshold, using Sonny elevation: +1282 m | -520 m
10m threshold, using Sonny elevation: +1122 m | -365 m
Hi Sonny,
as I was on holiday in the area, I also tested the routes in Locus and came up with pretty much the same values using your altitude data and the threshold values ;-)
@Locus developers: If you follow Sonny's recommendation and increase the default threshold value, it would be nice if you could change this default value yourself permanently. Reason: I live in a rather flat area (Berlin-Brandenburg) and therefore mainly move around in this area, the current 3-m threshold value is ideal for me.
When I'm on holiday in mountainous areas, I change it manually using the slider, but I don't want to have to do that for every trip in my home region.
On holiday, I could then set the default value to 10 m, for example, and not have to do this for every route. At home, I would set it back to 3 metres.
*** Translated with http://www.DeepL.com/Translator (free version) ***
Hi Sonny,
as I was on holiday in the area, I also tested the routes in Locus and came up with pretty much the same values using your altitude data and the threshold values ;-)
@Locus developers: If you follow Sonny's recommendation and increase the default threshold value, it would be nice if you could change this default value yourself permanently. Reason: I live in a rather flat area (Berlin-Brandenburg) and therefore mainly move around in this area, the current 3-m threshold value is ideal for me.
When I'm on holiday in mountainous areas, I change it manually using the slider, but I don't want to have to do that for every trip in my home region.
On holiday, I could then set the default value to 10 m, for example, and not have to do this for every route. At home, I would set it back to 3 metres.
*** Translated with http://www.DeepL.com/Translator (free version) ***
Interesting discussion.
Altitude threshold in the app is not fixed. It is based on the source of the elevation. App decide by following check (in this order):
- If you use pressure sensor, app set the threshold to "2".
- If you use elevation data (enabled in "Altitude manager"), threshold is set to "3".
- If you have Android 12+, threshold is set to "5".
- Otherwise it is set to "10".
---
Generally default value is "5". It should be set to all imported tracks or to old tracks recorded before this parameter was introduced.
---
1'' data are used in our maps and also in the routing files. So if you use LoRouter for planning, elevations are already computed from these precise datasets.
Distribution to users was discussed many times in our team, but we were never able to find enought time to realize it. Sorry.
Interesting discussion.
Altitude threshold in the app is not fixed. It is based on the source of the elevation. App decide by following check (in this order):
- If you use pressure sensor, app set the threshold to "2".
- If you use elevation data (enabled in "Altitude manager"), threshold is set to "3".
- If you have Android 12+, threshold is set to "5".
- Otherwise it is set to "10".
---
Generally default value is "5". It should be set to all imported tracks or to old tracks recorded before this parameter was introduced.
---
1'' data are used in our maps and also in the routing files. So if you use LoRouter for planning, elevations are already computed from these precise datasets.
Distribution to users was discussed many times in our team, but we were never able to find enought time to realize it. Sorry.
Hi, it has happened to me too. Elevation gain has been almost doubled for the last year, compared to the same move in my Suunto.
Sorry for the off topic, but my entire library, a part from a couple of route planned in the last month is disappeared. Tow month ago the same thing, but after uninstall and reinstall the app my planned routes reappeared. I've the gold version.
Any idea? Thnks a lot and good trips.
Hi, it has happened to me too. Elevation gain has been almost doubled for the last year, compared to the same move in my Suunto.
Sorry for the off topic, but my entire library, a part from a couple of route planned in the last month is disappeared. Tow month ago the same thing, but after uninstall and reinstall the app my planned routes reappeared. I've the gold version.
Any idea? Thnks a lot and good trips.
Replies have been locked on this page!