Das war schon mein Reden in #12. Dafür ist die barometrische Höhenmessung allemal ausreichend und m.E. einfacher als den Neigungswinkel mitteln. Bei 600 m Strecke allemal, so schnell ändert sich das Wetter und der Luftdruck nicht. Man kann ja an anderen Tagen nochmals Kontrollmessungen fahren.
Es sollte aber auch Fahrradapps geben, die auch die Steigung aufzeichnen, ich kann aber nicht sagen, ob die nur auf die GNSS-Höhenmessung oder auch auf barometrische Sensoren zugreifen. Und ich habe bisher leider nur Auswertungen gesehen, die die Höhe in Bezug zur Zeit setzen, aber nicht in Bezug zur Strecke.
Halt, doch, OSMAnd kann das, weiß aber nicht, ob das auch barometrische Höhendaten verwendet, da mein Handy kein Barometersensor hat. Nur GNSS-Höhendaten wären zu ungenau.
Es gibt Karten auf Basis von DEMs; z.B. https://www.openslopemap.org/karte/ - Ab der dritten von neun Stufen gehts es da allerdings um Steigungen über ~60%; die höchste Stufe geht bei ~145% los. Die Quellen sind alle angeführt, die “secret sauce”, die draus Neigungen ableitet, bleibt geheim, so viel ich seh. Im Gebirge eine nette Ergänzung zu Höhenlinien allemal.
Exemplarisch: Bei den SRTM-Radardaten habe ich häufiger den Eindruck, dass Bewuchs (als bspw. Bäume) schon einen deutlichen Unterschied machen. In Großstädten sind in der Opentopomap, die mWn die Höhenlinien aus den SRTM Daten generiert, auch mitunter (für mich?) relativ eindeutig Reflektionen von Hochhäusern störend in die Höhendaten eingeflossen. (*)
Will sagen: Auch bei Fernerkundungsdaten kommt man nicht um eine gewisse Vorsicht und Hintergrund-Wissen umhin, um die Daten ‘richtig’ interpretieren zu können.
Meine Alltags-Erfahrung mit Garmins Algorithmen zur Kombination von Barometrischen Daten mit GPS Daten ist, dass das Resultat eine hohe Zuverlässigkeit und Genauigkeit im kleinen einstellige-Meter-Bereich aufweist. Ich nehme an, dass Garmin die beiden Datenquellen mittels Kalman-Filter kombiniert, das wäre zumindest aus stochastischer Sicht das naheliegendste.
Die Anpassung des Bezugsdrucks findet also indirekt “automatisch” (eigentlich: algorithmisch) statt (**).
Der Aspekt, Sensordaten zu kombinieren ist meinem Verständnis nach im Blogpost von Robhubi unberücksichtigt geblieben, der Fokus liegt/lag wohl eher auf einer (einfachen) Schwellenwertmethode für die Barometrische Höhenmessung.
Grüße
t.
(*) Die abrufbaren Daten sind durch ein (Pre)Processing gelaufen, zu welchem mir keine detaillierte Dokumentation über Buzzwords hinaus bekannt ist – das macht es schwierig, abzuschätzen, was die Daten wiedergeben. Ich hätte erwartet, dass “einer der langsamsten Reflektionen” (also Richtung 95%-Quantil) genommen wird. Allerdings wirken die Höhendaten eher “anders”. Wer weiß, mit welchen Phänomenen die SRTM-Mission noch so zu kämpfen hatte ^^. Ich würd mich über eine PN freuen, wenn da jemand detailliertere Infos zu hat.
(**) Kann man mindestens bei den Ur-eTrex’en auch ausstellen…
