Hallo zusammen,
habt ihr Euch schon mal die neue Funktion Höhenprofil in Osmand angesehen. Man kann sich ein Höhenprofil eines Tracks anzeigen lassen.
Das ist an sich noch nichts weltbewegendes, was ich aber gut finde ist die Funktion "Auf Karte auswerten".

Osmand wechselt dann auf einen getrennten Bildschirm. Links sieht man das Höhenprofil oder die Steigung in Prozent.
Vor allem bei letzterem kann man sofort sehen, wo sagen wir mal Steigungen >10% sind. Mit einem Touch auf sdas Steigungsprofil,
sieht man in der karte einen Punkt wo diese sich befindet. Durch zoomen mit 2 Fingern, kommt das Steigungsprofil näher und auch die Karte rechts zoomt auf den Punkt.

Unten bei den Kilometren kann man abschätzen wie lang die Steigung ist. Hier wäre allerdings eine Änderung des Masstabes noch wünschenswert,
da dieser doch sehr grob ist.

Ansonsten eine sehr schicke Funktion.

Damit kann man sicher beim einen oder anderen mal auch sagen, ich nehm einen Umweg in Kauf statt 16% Steigung zu fahren (oder auch andersrum ).

Gruß

Yogi

Wurde hier hier schon vor ein paar Tagen entdeckt. Höhendaten werden beim Routing berücksichtigt. Die einhergehenden "Aufblähung" der Rechenzeit auch.

Fürs Finden. Posts zwischen dem 9.4. und 15.4.

Hi JSchro,

den Thread habe ich bereits verfolgt. Routing verwende ich nur in Städten um Hotels, Sehenswürdigkeiten usw. zu finden.

Mir geht es eher um vorgefertigte Tracks (z.Bsp. mit BrouterWeb) zu untersuchen.
Eine vergleichbare WebSeite oder eine App kenne ich bisher nicht, wo man die Steigungen so schön auflösen kann.

Dann schau Dir mal das Projekt Caminaro an und stöbere im dazugehörenden Faden Der caminaro-Thread

Caminaro ist in keinster Weise vergleicbar.

Da wird weder das Höhenprofil, noch die Steigung gezoomt.
Bei der Steigungsanzeige da seh ich nur ein paar Farben.
Keine Ahnung was die bedeuten.

Bitte jetzt nicht wieder ne Diskussion anfangen, was ist besser. Ich habe den Faden aufgemacht um über die Osmand Steigungsanzeige zu diskutieren, über die Features der Caminaro Seite sollte man es dort tun.

Gruß
Yogi

Ich dann die Funktion nicht finden.

Geht das auch für die berechnete Route?

VG,
Alex

Menü - Meine Orte - alle Tracks- touch

Hallo!

Habe die Funktion nach dem gestrigen Update gefunden. Damit ist für mich Osmand die perfekte App!

LG

Martin

Danke für den Hinweis. Da habe ich die App gleich aktualisiert. Sieht auf den ersten Blick gut aus.

Auf den zweiten Blick ist die Frage, wie kommen die Höhendaten zustande. Dass ich am Samstag 4000 hm bewältigt haben sollte, bezweifle ich ganz stark.

Bekanntes Problem: Messfehler („Rauschen“).

Mathem. Verfahren, aber aufwändig: Glättung / Reduzieren von Punktwolken, Ermittlung von Ausreißern, Ausgleichsrechnung oder aber Verfahren kombinieren: GPS, barometrisch, digitales Geländemodell.

Einfachste Methode: Trackreduzierung - weniger Wegpunkte ergeben meist exaktere Werte .

Bekannte Probleme sind nicht unbedingt die Antwort, weil Osmand auf STRM-Höhendaten zurückgreifen kann. Und normalerweise wären es bei GPS-Messung erfahrungsgemäß dann eher 10000 hm. (Mein Gott, wie hat mich die barometrische Höhenmessung zur Memme gemacht.)

Deine Antwort stimmt trotzdem. Entweder hat Osmand etwas eingebaut, dass der GPS-Messfehler reduziert wird oder ich habe einen guten Messtag gehabt.

*hüstel*
Das kann nicht das Mittel der Wahl sein. Wenn das Verfahren Rauschen aufsummiert, dann ist es Mist. Das wird auch dadurch nicht besser, dass man "nicht mehr so genau hinschaut", sprich eigentlich vorliegende Daten verwirft, nur um das Drama der fehlerhaften Berechnung nicht mehr ganz so stark ins Gewicht fallen zu lassen.
Um wie viel soll man den Track denn reduzieren? Wenn das Verfahren chronisch zu viel misst, dann gibt es mittels Ausdünnung immer einen Ausdünnungsgrad, wo die vom Algorithmus berechneten Höhenmeter und die realen Höhenmeter zusammenpassen. Nennt sich Zwischenwertsatz in der Mathematik. Allerdings ist dieser Ausdünnungsgrad aber vom konkreten Track abhängig, mal wird mehr, mal weniger Ausdünnung nötig sein. Damit hat dieser Ansatz nicht viel praktischen Wert.

Und wie viel praktische Erfahrung hast Du, um den realen praktischen Wert dieser Vorgehensweise zu beurteilen.

Liebe Freunde/innen der Höhenmeter,

also ich glaube,

• bei den Höhenmetern gibt es keinen wirklich “wahren” Werte
• weniger Wegpunkte ergeben exaktere Werte
• Planungsprogramme nützlich (ich nutze u.a. Quovadis und vergleiche)

Ansonsten siehe Diskussion hier

Gruß,
Dieter

Um in Sammys Duktus zu bleiben, diese Aussage ist Mist.

Denn das aufsummierte Rauschen, hat man auch bei der GPS-Streckenmessung. Bloß Messfehler/gemessenes Strecke bewegen sich bei der Längenmessung in anderen Dimensionen als bei der Höhenmessung. Deswegen hinterfragen wir trotz eines aufsummierten Rauschens den praktischen Wert einer GPS-Streckenmessung.

Der oben genannte Größe Messfehler/gemessenes Strecke dürfte aber ein Ausdruck werden, wie der Zahlenwert praktisch zu interpretieren ist. Zu sagen ich bin 90 km nach GPS gefahren, kann man sagen. Bei den Höhenmeter kann man vielleicht sagen, dass ich ungefähr das doppelte gefahren bin als bei der letzten Tour.

Aus praktischer Erfahrung, als ich GPS-Werte und digitalen Werte mit barometrischen Höhenmeter verglichen habe, ich kann bei mir von einer groben direkten Proportionalität sprechen.

Interessant wäre zu wissen, ob man berechnen kann, wann Werte noch etwas mit der Realität zu tun haben, oder nur noch Verhältnisse angeben, oder einfach zu nichts mehr nutze sind.

Was mich dazu bringt die Osmandwerten zu hinterfragen? Sie passen in das Raster nicht rein.

Ich habe jetzt mal den Track in RouteConverter gemacht und da werden andere Werte ausgegeben als in Osmand. Dann habe ich den Track unter http://www.gpsvisualizer.com/convert_input mit digitalen Werten versehen. Auch andere Werte.

Osmand liegt irgendwo dazwischen. Was die Vermutung nahelegt, Osmand interpretiert die Messungen oder wertet die digitale vorliegenden Höhenwerte anders aus.

Der Punkt ist eben der, dass das Verfahren mittel Trackreduktion nicht mehr viel mit einer konkreten Messung zu tun hat. Mag ja sein, dass du daraus deine eigenen Streckenbewertungen ablesen kannst. Ich warne nur vor zwei Effekten:
Einerseits die Höhenmeterwerte von Gebieten deutlich verschiedener Topografie (Hochgebirge vs. sehr welliges Mittelgebirge z.B.) zu vergleichen. Oder die ermittelten Werte blind mit anderen Messverfahren zu vergleichen.
Von daher sind meine "praktischen Erfahren" recht wertlos, weil sie eben von Software und Trackausdünnungsverfahren abhängen würden. Und warum sollte ich mit einem Verfahren Erfahrungen sammeln wollen, was ich schon aus systematischen Gründen für nicht gut erachte?

Ich kann mich erinnern, dass (hier im Forum - ?) genau vom Gegenteil berichtet wurde.
Gruß
Uli

Weil deine Überlegung, wie oben ausgeführt in ihrer Absolutheit (Mist) ausgeführt falsch ist, und Du unter Umständen die Fachkunde hast, dass zu bemerken, weil es einen Schwellenwert gibt, wann es Mist wird. Und dann könnte ja mal ausprobieren, ob es schon so weit ist.

Das ist nur bedingt richtig. Die Positionswerte, die das GPS-Gerät abspeichert, sind nicht nur die bloßen Messdaten, sondern eine Extrapolation, die u.a. auch die aktuelle Geschwindigkeit berücksichtigt. Spricht bewegst du dich nach Norden mit deutlicher Geschwindigkeit, dann unterdrückt die Gerätesoftware Messfehler in Ost-West-Richtung. Das merkt man vor allem wenn man in Tunnel (ohne Empfang) fährt. Das GPS-Gerät extrapoliert dann die voraussichtliche Position einfach anhand der letzten Geschwindigkeit weiter. Effektiv ist damit das GPS-Positions-Material kaum mehr verrauscht, weil es schon bei der Datenerfassung geglättet wird.


Nach einer geeigneten Modellbildung, kann man das sehr wohl ausrechnen. Ist aber unter Umständen extrem aufwändig.
Digitale Höhendaten sind immer nur ein Notbehelf, "Naturdaten" von GPS UND barometrischem Höhenmesser immer viel genauer.
Recht einfache Tests der Algorithmen kann man machen, wenn man Strecken mit überschaubar wenigen Anstiegswechseln fährt. Sprich z.B. ein Flusstal rauf, oben angekommen dann einen Pass runter und noch einen Pass rauf. Dann ging es auf der Strecke zweimal hoch, einmal runter. Die Höhenmeter kann man dann ganz leicht "von Hand" ausrechnen. Alles was zu wenig liefert, ist sehr skuril, was zu viel liefert dann offensichtlich auch mit Vorsicht zu genießen.

Mich stört der systemsiche Ansatz. Ich nehme doch nicht erst zig Messdaten auf und verwerfe hinterher einen Großteil davon. Diese Ergebnisbestimmung kann nicht optimal sein, das liegt auf der Hand. Die Schwellwerte betreffend nähern wir uns allerdings dem Knackpunkt. Die Frage ist, wie man die Höhenmeter aufsummiert? Und stupides Aufsummieren der Differenz zu den Daten vom vorherigen Messpunkt ist sicher nicht der richtige Ansatz. Man muss detektieren, wo die Monotoniewechsel stattfanden, sprich wo sich Rauffahrt und Runterfahrt abgewechselt haben. Dann wird die Höhe dieser Stellen möglichst genau bestimmt und dies dann aufaddiert. Dann kommt nur noch ein Rauschbeitrag von jeder dieser Stellen, aber nicht mehr von jedem einzelnen Trackpunkt.

Also wir haben dann einen dreidimensionalen Vektor, schmeißen eine Dimension raus und haben ein sauberes Minimalrauschen für die Strecke?

Das kann so auch nicht stimmen, entweder wird die Z-Achse mit extrapoliert, dann wird das Höhenrauschen aber auch reduziert oder man macht es ohne Z-Achse. Bloß dann kann der extrapolierte Vektor ziemlich falsch sein.

Wobei ich mich frage, ob diese Extrapolierung grundsätzlich stattfindet oder wenn das Signal fehlt. Konnte das aber nicht herausfinden.


Das musst Du dann aber auch bei Tempo- und Richtungswechsel. Da gibt es ja auch Monotoniewechsel. Die fallen sogar tendenziell mit den Rauf- und Runterfahrten zusammen.

Mir erschließt sich aus deinen Ausführungen nicht, warum das für eine Dimension plötzlich alles nicht gehen soll. Bzw, warum ist das für eine Dimension schwierig und für die anderen zwei machbar.

Eine Kurve in der Ebene sieht von oben so aus, wie ein Tal von der Seite.

Außer wir kommen auf mein Verhältnis Messfehler/Gemessene Strecke zurück.

Zweidimensional. Die Z-Koordinate wird meines Wissens gar nicht oder zumindest anders behandelt. Würde mich nicht wundern, wenn bereits der GPS-Empfangschip eine Vorverarbeitung der Daten durchführt. Für die Z-Koordinate will das Gerät dann aber noch die Infos vom zumindest möglichen barometrischen Höhenmesser mit integrieren. Schon allein deshalb ist es auch sinnvoll, die Höhe getrennt zu behandeln. Ich vermute aber, dass die üblichen GPS-Geräte hier durchaus nicht sonderlich elegant arbeiten und Potential verschenkt wird.

Rauschen in Bewegungsrichtung ist nicht weiter schlimm, das mittelt sich bei der Aufsummation raus. Wichtig ist nur, dass das Rauschen nicht die kommenden Punkte "überholt" oder hinter die vorherigen "zurückfällt". Das ist aber in der Regel (solange man in Bewegung ist) nicht der Fall. Anders beim Höhensignal, hier führt das Rauschen dazu, dass man beim Blick auf die aufgenommenen Daten den Eindruck gewinnen kann, dass es von Messpunkt zu Messpunkt mal rauf, mal runter geht (Rauschen ist groß im Vergleich zur realen Höhenänderung). Das bewirkt die Probleme und ist der qualitative Unterschied zwischen der Stärke des Rauschens auf dem Höhensignal und dem auf dem Positionssignal.


Dieser Rechenalgorithmus arbeitet beständig. Effektiv findet dabei eine Mittelung mehrerer zurückliegender Messwerte statt. Ich vermute, dass ein Ausgleichsrechnungsalgorithmus zum Einsatz kommt, der die zurückliegenden Messwerte am besten mit einer bestimmten Bewegungskurve (wahrscheinlich ein konstanter Ansatz für die Geschwindigkeit, sprich linearer Ansatz für den Ort) in Einklang bringt. Dass auf jeden Fall so etwas stattfindet, siehst du anhand der Punktewolken, die sich im Stillstand ergeben. Hier kann der Algorithmus keine Geschwindigkeit zuordnen und zeigt daher gut das Rauschen des Signals in jede Himmelsrichtung an. Kann der Algorithmus einmal von einer bestimmten Geschwindigkeit ausgehen, können die Fehler senkrecht zu dieser Bewegungsrichtung herausgerechnet werden.


Meine Ausführungen bezogen sich auf die Höhenmeterberechnung. Da spielt weder das gefahrene Tempo, noch das Vorhandensein von Kurven eine Rolle. Es geht ausschließlich um die Auswertung der Funktion "Höhe in Abhängigkeit vom Aufzeichnungspunkt". Will man ein Höhenprofil plotten (oder mit Steigungswerten hantieren), dann kommt dem Abstand der Aufzeichnungspunkte noch eine Bedeutung zu.


Häh?


Das ist ja gerade mein Punkt, der Fehler hat nur sehr indirekt etwas mit der gefahrenen Strecke zu tun. Das betrifft übrigens beide Werte: Die Längenmessung und die Höhenmetermessung. Ich mache es mal an der Höhenmetermessung fest.
Das eine Extremum: Du fährst in absoluter Ebene stupide geradeaus. Real: 0hm. Durch naives Aufsummieren des Rauschens (nehmen wir mal beispielhaft mit +/-1m an) machst du einen Fehler, der direkt mit der Anzahl der Trackpunkte korrespondiert. Halb so viel Trackpunkte, halb so viel errechnete Höhenmeter, 10% Trackdaten, 10% der Höhenmeter.
Anderes Extremum: Du fährst einen steilen Pass rauf. Ich spinne jetzt mal, zwischen zwei Messzeitpunkten machst du stets etwa 3hm gut, das Höhensignal rauscht aber nur +/-1m. Selbst wenn du hier ganz naiv einfach die Höhendifferenzen aufsummierst, wirst du am Ende ein (fast) exaktes Ergebnis bekommen, unabhängig davon, wie weit du den Track ausdünnst.

Ähnlich verhält es sich bei der GPS-Streckenmessung. Geht es hauptsächlich kurvenlos geradeaus, machst du einen sehr kleinen Streckenlängenberechnungsfehler. Der ist offensichtlich auch nicht von der Aufzeichnungsdichte abhängig.
Ist der Streckenverlauf sehr kurvig und obendrein in den Kurven die Aufzeichnungsdichte noch gering (weil z.B. nur alle 10s ein Trackpunkt erfasst wird), ist ein größerer Fehler zu erwarten.

Ergo: Der Berechnungsfehler hängt sehr wesentlich vom Streckenverlauf ab und man kann nicht pauschal sagen, wie Berechnungsfehler und Trackaufzeichnungsdichte korrespondieren. Je nach Radfahrgegend mag es da gewisse "Erfahrungswerte" geben, das sind aber keine universell gültigen Prinzipien und Vergleiche zwischen verschiedenen Topografien/Streckenverläufen faktisch nicht möglich.

Also ich gehe davon aus,

dass ein GPS Punkt eine dreidimensionale Koordinate ist. Ob ich die Differenz zwischen zwei Z-Anteilen berechne oder den Abstand der zwei Punkte ist relativ Wurst.



Stell dir eine Sinuskurve vor. Ist das jetzt ein Auf und Ab von der Seite gesehen oder ein Straßenverlauf von oben?

Der Punkt ist, dass meine Höhenänderung gemessen zur Zeit als Radfahrer niedriger ist als meine Streckenänderung. Und deswegen schlägt der Messfehler bei der Höhenmessung mehr rein.

Mit Messfehler meine ich die Abweichung realer Punkt und gemessener Punkt.

Dein Geometrieproblem die Kurve ist ein Polygon ist ein andere (Mess)fehler. Zu dem kommt dann noch der Abweichungsirrtum des GPSs.

Fand auch diese Erläuterungen hier sehr erhellend:

https://www.gletschersau.de/2016-02-10_gps_hohenmessung_genauigkeit/

Nein, zumindest bei GPX und sicher auch bei anderen GPS-Datenstandards werden Länge und Breite als prominente Koordinaten erfasst. Zusätzlich kann noch die Höhe erfasst werden, qualitativ auf dem gleichen Level wie Temperatur, Trittfrequenz usw.

Und wie ich bereits schrub, ist die Art des stochastischen Fehlers der erfassten Werte (sowohl hinsichtlich der stochastischen Natur, als auch hinsichtlich ihrer prozentualen Ausprägung in Relation zu den wahren Werten) sehr unterschiedlich und nicht vergleichbar.


Ich bin mit meinem Latein langsam am Ende. In noch anderen Worten kann ich es nicht mehr erklären. Die stochastischen Fehler sind von nicht vergleichbarer Qualität.


Ja, das trifft den Kern schon recht gut. Obendrein ist zumindest aus dem GPS-Signal der vertikale Höhenmessfehler deutlich größer als der horizontale.


Nein, ich meine nicht den Längenbestimmungsfehler, den man durch die Polygonzugapproximation erhält. Wobei der natürlich auch umso größer wird, umso mehr man den Track ausdünnt. Aber es ergeben sich halt auch größere Fehler, wenn der Geschwindigkeitsvektor seine Richtung ändert, weil das GPS dort z.B. den Serpentinenscheitel nicht passend erfasst. Solange es geradeaus geht, tritt das Problem so nicht auf.

Sorry, einen getrennten Bildschirm krieg ich nicht, und auch kein Höhenprofil oder Steigung in %. Nur einen track, wo ich die km-abstände wählen kann, und die Farbe.

Menü - Meine Orte - Tracks - Schlange neben Trackname

Hat lange gedauert, aber jetzt funzts.Nach nem update.
Naja, zuhaus brauch ich halt kein Navi.