BC Unterschied Höhenmeter Teilstrecke zu Gesamtstrecke

Bei der Gesamtroute werden weniger Datenpunkte im Profil erzeugt, daher ergibt sich beim Zusammenrechnen der Einzelrouten in den meisten Fällen ein höherer Wert.

Mich würde interessieren, ob die Daten auch noch abweichen, wenn Sie die Höhenmeter der Routen im Routeneigenschaftsfenster in der 3.3.0.3 Beta anzeigen lassen. (Eventuell müssen Sie die Routen jeweils noch einmal neu berechnen lassen, wenn Sie nicht auf Anhieb angezeigt werden.) Die sollten dann theoretisch nicht mehr abweichen.

Beeinflussen kann man die Berechnung derzeit nicht.

Hallo FALAGAR,
habe die 3.3.0.3 Beta installiert, die Entfernung ist korrekt geblieben, bei den Höhenmetern ist es eher noch schlimmer geworden bei den errechneten Werten.
Also eine Route hat 44 km und 2310 Hm aus der 3.2.2 und in der 3.3.0.3 errechnet das Programm 44 km und 2670 Hm. Im Graph beim abgreifen der Daten erhalte ich aber den Wert von 2310 Hm wieder?!?! siehe Anhang Bild01und Bild02. Jetzt weist die Gesamtroute bei den Höhenmetern 27046 Hm aus gegenüber den Abgeriffenen Werten von 17140 Hm. Ich weiß, das die Gesamtroute um die 18000 Hm hat, es ist die Strecke der Transalb-Challenge.
Die Summe der Einzelstrecken liegt jetzt bei 27105 Hm. Da scheinen die Summen übereinzustimmen. Aber meiner Meinung zu viel Höhenmeter und wo kommt dann der Unterschied im Graphen her?

Hier ein weiterer Vergleich hinsichtlich der Gesamtanstiege bei Routen und Tracks. Die einzelnen Etappen wurden als Routen mit BaseCamp 3.3.0.3 Beta geplant und anschließend zu Tracks konvertiert. Wie man sieht, gibt es kaum nennenswerte Abweichungen, bis auf die in der Profilgrafik ermittelten Routen-Höhenmeter im Vergleich zum Eigenschaftsfenster bzw. zu den Gesamtanstiegen der Tracks. Ebenso lässt sich feststellen, dass die Betaversion geglättete Höhen in die Trackdaten schreibt. Somit ergeben sich beim Gesamtanstieg keine Abweichungen im Eigenschaftsfenster eines Tracks im Vergleich zur Route.

Sofern nachträglich einem Track über die Funktion "Set Selected Track to Map Elevation" die Höhendaten der Karte zugewiesen werden, so nimmt der Gesamtanstieg folglich wieder zu. Verbindet man die einzelnen Routen zu einer Gesamtroute, ergibt sich ein deutlich geringerer Gesamtanstieg (15217 Hm) im Vergleich zum kumulierten Anstieg aller einzelnen Routen (18085 Hm). Das könnte darauf hindeuten, dass die Glättung distanzabhängig stattfindet.
Aus meiner Sicht scheinen die Gesamtanstiege der einzelnen Routen in den Profilgrafiken realistischer als die Angaben in den Eigenschaftsfenstern zu sein.


Gruß

... die Geschichte mit den Höhenmetern hat eine ganz einfache Bewandtnis.

Und nun ein einfaches Beispiel:
Plane ein Luftlinenroute und setze den Startpunkt und den Zielpunkt in 5 km Entfernung.

Das Streckenprofil ist eine gerade Linie und zeigt nur den Höhenunterschied zwischen diesen beiden Punkten.

Will ich nun ein genaueres Höhenprofil erhalten, muss ich mehr Zwischenpunkte setzen, bei einem 200-m-Höhenraster weniger als bei einem 90-m-Höhenraster.
Als weiteres Beispiel diene ein Track: Nimm einen Track mit x-Punkten und schaue dir das Höhenprofil an.
Dann reduziere mittels Filter die Anzahl der Trackpunkte auf ein Minimum und schaue dir dann das Höhenprofil an, und vergleiche.

Ein auf die Map gemalter Track mit weniger Punkten muss zwangsläufig ein anderes Profil aufweisen als ein tatsächlich mit dem GPS aufgezeichneter Track.

Und wenn ein Track in eine Route konvertiert wird, und wieder zurück, erhalte ich auch zwangsläufig unterschiedliche Ergebnisse - s. auch die ausgewiesen Punkte/Viapunkte in der Grafik des vorstehenden Beitrages.

Es ist alles nur interpoliert. Und so kann es geschehen, dass ein Fussweg neben einem Bachlauf 1 m tiefer als der Bach selbst liegt.

Hallo zusammen,
es ist schön oder auch nicht schön, das ebenfalls Jemand mein Phänomen an eigenen Daten nachvollziehen kann.
Ich habe ebenfalls eine solche Tabelle erstellt und mein Fazit stimmt mit dem von MARKUSDOEGELT überein.
Ich vertraue eher den Angaben aus dem Graphen.
Hallo GEDULD, deine Erklärung ist sicher OK, plausiebel und nachvollziehbar, erklärt aber nicht die Diskrepanz zwischen der Summe Einzeletappen und verbundener Etappe, da die Punkte ebenfalls aufsummiert sind und demzuvolge die gleiche Berechnung zugrundeliegt, aber im Graphen andere Werte erscheinen und wo kommen die erheblich anderen Werte in der 3.3.0.3 her, die Berge sind nicht höher geworden?!

Hallo FLACHLANDBIKER,

die Vergleiche sind interessant und logischerweise müssen sich auch entsprechende Parallelen bei ähnlicher Vorgehensweise ergeben. BaseCamp verändert sich derzeit relativ schnell, deshalb wollte ich die aktuelle Beta nur isoliert betrachten und keine Vergleiche zu älteren Releases ziehen. Du planst eine Transalp und benötigst daher eine gute Planungsgrundlage, die Dir den zu erwartenden Gesamtanstieg möglichst brauchbar ermittelt. Es wird hier leider immer einige Variablen geben, die sich nicht in der Planung berücksichtigen lassen, aber ich glaube BaseCamp wird sich noch in vielen Punkten ändern und sicher auch weiter verbessern.

Nach meinem Verständnis sollte es in erster Linie eigentlich gar nicht darum gehen, die tatsächlichen realen Höhenmeter zu ermitteln (das ist ohnehin nie genau möglich), sondern einen Abgleich von BaseCamp mit dem Verhalten des eigenen barometrischen Höhenmessers durchzuführen. Das könnte z. B. so aussehen, dass ein Track, dessen barometrischer Gesamtanstieg bekannt ist, in BC importiert und in eine Route konvertiert bzw. als Route nachgezeichnet wird. Den Gesamtanstieg, den nun BC anhand dieser Route ermittelt, wird mit hoher Wahrscheinlichkeit vom ursprünglichen Wert des Höhenmessers abweichen. Diese Differenz könnte aber vom Benutzer z. B. über einen einstellbaren Glättungsfaktor oder durch eine Änderung der Funktion, welche die Daten interpoliert, in BaseCamp korrigiert werden.

Abgesehen davon muss man aber auch die Karten mit der Qualität der hinterlegten Höhenmodelle betrachten und ebenso die durchaus abweichenden Aufzeichnungsmethoden der bar. Höhenmesser. Wenn ein Benutzer aber weiß, wie sich z. B. 2000 Höhenmeter mit seinem eigenen Gerät anfühlen, dann ist es m. E. unerheblich, ob die Höhenmeter der Realität entsprechen. Es geht viel mehr darum, dass sich in der Planung nach Möglichkeit ähnliche Werte ergeben, die sich dann im praktischen Einsatz auch einigermaßen bewahrheiten. Es gibt definitiv keinen Trackfilter und auch keine interpolierte Auswertung, die für jeden Track oder jede Route optimale Ergebnisse liefert, da die Auswertung immer nach einem vorgegebenen Schema abläuft.
Daher wäre es sinnvoll, wenn der Benutzer eine Einflussmöglichkeit hätte.

Gruß

@ Flachlandbiker

Schicke deinen langen Track doch einmal durch den Filter und verringere stufenweise die Trackpunkte solange, bis du als Ergebnis die korrekten Höhenmeter bekommst.

Dann wird dir auch schlagartig klar, wie Interpolation und Anzahl der Trackpunkte im Zusammenhang stehen.

Und wenn du einen Track wirklich gut analysieren möchtest, nimm "GPS-Track-Analys-NET". Damit kannst du den Track mit der Baro-Höhe syncen.