von: Toxxi
Re: OsmAnd - Höhenangaben in aufgezeichnetem Track - 07.09.25 17:13
In Antwort auf: martinbp
Das ist auch meine Erfahrung. Gestrige Tour mit 2 Android-Geräten: 854 Hm und 842 HM, barometikusan gemessen 840 Hm. Das auf einer 67 km Strecke mit etlichen kurzen knackigen Anstiegen und längeren allmählichen Steigungen.
Diese Genauigkeit reicht fürr meine Zwecke völlig aus. Erstaunlicherweise zeigt Brouter nur 703 Hm an.
Diese Genauigkeit reicht fürr meine Zwecke völlig aus. Erstaunlicherweise zeigt Brouter nur 703 Hm an.
Da will ich durchaus noch mal einhaken. Aus meiner Sicht reden wir hier irgendwie am Thema vorbei.
Du sprichst davon, dass deine Geräte die Höhenmeter gemessen haben. Hier liegt m.E. ein Verständnisproblem vor. Es gibt kein Höhenmetermessgerät. Ein Navigationsgerät misst keine Höhenmeter. die Höhenmeter werden angezeigt, aber nicht gemessen.
Die Geräte messen immer nur die aktuelle Höhe. Die Höhenmeter werden daraus über die Länge des Tracks, d.h. über die einzelnen Messpunkte, durch einen Algorithmus berechnet. Der addiert nicht einfach nur. Dann würde man jede Messschwankung addieren und es kämem viel zu viele Höhenmeter raus. Eine Art Glättung oder Rauschschwelle muss implementiert sein.
Und da fängt die Krux an. Es gibt m.E. keinen universell akzeptieren Algorithmus zur Berechnung der Höhenmeter. Aber irgendwie scheinen sie doch wieder ähnlich zu sein, wenn so ähnliche Werte rauskommen.
Der Fehler durch den Additionsalgorithmus ist viel größer als der durch die Nachkommastelle der Höhenmeter.
Beipiel - wir stellen und einen Höhenmesser vor, der millimetergenau messen kann. Dann fahren wir 10 km einer an sich flachen Straßen mit grobem Kopfsteinpflaster. Auf dieser Länge überfahren wir ca. 5000 Pflastersteine. In jeder Ritze sinken wir 20 mm ein.
Wenn wir jetzt stur die Höhenmeter ohne Glättungsalgorithmus addieren, dann kommen wir auf 100 Höhenmeter, obwohl wir flach gefahren sind.
Gruß
Thoralf