auch ich plane im ersten Schuss diverse Kleinabschnitte mit Komot oder Caminaro und speichere sie mir dann als gpx-Datei ab.
In BaseCamp plane ich ggf. noch mal um und erstelle einen Gesamtrack. Zusätzlich versehe ich das ganze noch mit WPs (Sehenswürdigkeiten, Campingplätze usw.) und speichere das ganze in GPSies mit aktuellen Höhendaten ab.
Zurück wird das ganze wieder mit den richtigen Höhendaten ins GPS-Gerät geschoben.

Alle Dateien bleiben bei mir noch bei GPSies gespeichert. Als Art Datensicherung.
Nachdem es mir einmal passiert war alle meine Tracks auf dem GPS-Gerät zu löschen (ich weiß heute noch nicht wie), konnte ich sie unterwegs in einem Internet-Cafe nachladen.

Gruß Rolf

Das ist DIE Lösung. Das habe ich durch diesen Faden gelernt.

Vorsicht
Von GPSies Höhenmetern kannst Du mindestens 35% streichen.
Wenn es drauf ankommt, plane ich bei Google im Geländemodus und schalte zur Kontrolle bei http://www.caminaro.com/ die Schatten ein.

ps: Bei der Planung der Jura-Tour hab ich auch den Flugmodus bei GPSies mit Google Erde genutzt, um mögliche Alternativen zu erkennen.

Das ist tatsächlich wahr. Dennoch bleibt das Höhenprofil während der Fahrt eine gute Orientierungshilfe. Die Gesamthöhenmeter, die GPSies ausrechnet, liegen zwar über dem Wert, den man beim Erfahren der Strecke über das Navi ermittelt, aber für die einzelnen Steigungen, die zu erklimmen sind, ist der Unterschied meiner Erfahrung nach meist nicht so groß. Man sieht den Unterschied übrigens, wenn man meine Radreiseberichte ansieht. Dort gebe ich die tatsächlich ermittelten Höhenmeter an und habe auch den Track mit den von GPSies ermittelten Höhenmetern verlinkt.

Ich brauche aber die exakten Höhenmeter sowieso nicht. Wenn wir das GPSMaps 62s im anrückenden Höhenprofil einen steilen Anstieg zeigt, dessen Ende auf dem Bildschirm nicht mehr zu sehen ist, weiß ich, was die Stunde geschlagen hat

Die exakten Höhenmeter sind mir auch egal. Ich führe keine Statistik. Ich möchte aber auch gerne wissen, was ich an Steigung zu erwarten habe. Genau dafür brauche ich das Höhenprofil und um bei der Planung für angezeigte extreme Steigungen eine alternative Strecke zu suchen.

Du machst das wirklich von den Steigungswerten abhängig? Mich interessieren bestenfalls die absoluten Höhenmeter. Ob ich die schneller und weniger steil auf längerer Strecke, oder eben steil und gemächlich auf kürzerer Strecke erklimme, ist mir eigentlich egal.

Klar gibt es auch Anstiege, die für langfristiges Fahren zu steil sind, aber nicht auf 100hm. Da kommt man eigentlich überall rauf, es sei denn es ist vereist oder es geht um das Befahren einer Downhillpiste gegen die Fahrtrichtung.

Lieber Sammy,

man kann extreme Anstiege auch schlicht umfahren wollen, so wie es Winoross und manchmal auch ich ja wohl vor haben.

Hallo,



Ist der Fehler reproduzierbar? Bei meinem Basecamp gehen keine Höhendaten verloren, wenn ich Tracks zusammenfasse.

Grüße
Andreas

Ja, dass ist mir schon klar. Die Frage ist nur, ab welcher Länge entscheidet man sich bei einer extremen Steigung dafür diese zu umfahren und wie groß ist der alternative Umweg? Nur weil in einer Serpentineninnenseite über 30m Länge mal 30% Steigung sind, wird man ja nicht gleich ne Alternative suchen, oder?
Im Mittelgebirge hab ich bisher die Steigungen noch nie genauer betrachtet, bei Alpenpässen schon. Wenn einem der Wurzenpass zu steil ist, dann kann ich das verstehen. Da werden auf einer Länge von 3km fast 400hm gemacht - und das ist nur der steile Mittelteil des gut 600hm-Anstiegs. Aber wie gesagt, hier ging es um 100hm und alle diskutierten Steigungen bisher waren punktuelle Messungen, nicht Durchschnittssteigungen auf sagen wir mindestens 100m Länge.

Diese Vorhergehensweise ist m.E. von vornherein zum Scheitern verurteilt! In aller Regel sind die Höhenprofile viel zu ungenau, um auf kurzen Strecken exakte Steigungen zu ermitteln. Es lassen sich allenfalls Durchschnittssteigungen an längeren Anstiegen ermitteln.

Überlege doch mal: Höhenlinien bzw. Höhenmodell laufen ja nicht zentimetergenau durch die Landschaft (zumindest nicht die frei verfügbaren), sondern die Höhenlinie ist von ihrer Lage her ziemlich fehlerbehaftet. Abweichungen von vielen Metern sind da üblich. Wenn die Höhenlinien auf 20 m gerastert sind, dann kannst du zwischen zwei Linien gleich Fehler von deutlich über 100%, und im ungünstigsten Falle noch viel mehr bekommen. An langen Anstiegen mitteln sich die Fehler statistisch wieder aus, aber kurze Anstiege sind mit den gängigen Höhenmodellen grundsätzlich nicht modellierbar.

Du investierst Arbeit in etwas, das nichts bringt.

Gruß
Thoralf

Dass die Höhenlinien bzw. die Berechnung des Profils ungenau sind sein können, hatte Markus (Cyclist) und Arnulf (Keine Ahnung) vorher schon schön erklärt. Für meine Zwecke reichte es bisher aber immer aus, bzw. mir wurden hier Möglichkeiten zur Verbesserung aufgezeigt.
Das Empfinden hinsichtlich "Steigung" ist m.E. höchst unterschiedlich. Alpentouren scheiden für mich aus diesem Grund von vornherein aus. Das ist auch eine Frage des Alters und der gesundheitlichen und körperlichen Verfassung. Da ich mich überwiegend auf Flußradwegen und in der Ebene fortbewege, bringt mir die investierte Arbeit nach meinem Empfinden sehr wohl etwas.

ich bin über Arnulfs Aussage auch gestolpert und habe mir dann nochmals das Verhalten von BaseCamp genauer angeschaut. Nach meiner Beobachtung ist es so, dass bei Zusammenfassen mehrerer Tracks bereits vorhandene Höhendaten erhalten bleiben. Anders ist das, wenn ich eine Route in einen Track umwandle. Dann gehen wohl bereits evt. in der Route enthaltene Höhendaten verloren und für so generierte Tracks müssen die Höhendaten erneut eingelesen werden.

Hallo hopi,


Ich wusste gar nicht, dass Routen überhaupt Höhendaten enthalten können.

Das Zusammenfügen von Tracks mit Höhendaten mache ich öfter. Länderübergreifende Tracks trenne ich an den Grenzen, füge den Segmenten die Höhendaten zu (mit Basecamp und passender Karte) und setze den Track dann wieder zusammen.

Grüße
Andreas

Hallo Andreas!

Das ging sogar schon in MapSource. Voraussetzung ist natürlich eine Karte mit Höhenmodell.
Natürlich dann auch wieder mit den schon bekannten Fehlern und Fehlerursachen...

Ich plane üblicherweise eine Route mit einer OSM- o. Openfietsmapkarte, wandle die Route in BC zu einem Track um, wechsle auf eine Karte mit genauerem Höhenmodell (z.B. Garmin Topo D) und ersetze die Höhendaten. Das passt meistens schon recht gut - sprich meistens werden ca. 10-20% zuviel an HM in BC angezeigt...
Das hängt aber auch wieder von der Rechenmethode in BC ab...
Verschiedene Topo-D-Karten liefern auch wieder unterschiedliche Zahlen...
Und daher ist man desöfteren schon lange oben angekommen, obwohl man noch 20-50 HM hoch hätte fahren müssen...

Also nicht alles so ernst nehmen! Und wenn es doch ernst sein sollte, muss man die Übersetzung anpassen... - daher fahre ich jetzt auch 28 Gänge...

Bei mir ist es ähnlich... Das bloß Zusammenfassen von Tracks ändert nichts an den Höhendaten.

Nach dem Erstellen einer Route kann ich die Höhendaten abrufen. Beim Umwandeln der Route in Tracks gehen die Höhendaten verloren.

Das ist schon immer so seit ich Basecamp habe (Frühjahr 2012). Sie lassen sich auch nicht wieder nachträglich einfügen. auch nicht mit der Funktion "Höhendaten der Karte fürausgewählten Track verwenden". Diese Funktion ist reines Placebo und hat bei mir noch nie funktioniert.

Gruß
Thoralf

das kann ich nicht nachvollziehen. Voraussetzung ist allerdings, dass bei Nutzung dieser Funktion eine Karte mit einem Höhenmodell aktiviert sein muss. Zumindest hat BaseCamp bei mir noch nie den Dienst versagt, wenn ich bei einer aktivierten Karte mit Höhenmodell Höhendaten in einen ausgewählten Track schreiben wollte.

Ich benutze die Velomaps... Höhenlinien sind dort hinterlegt. Das merkwürdige ist, dass in den Routen, die ich erstelle, Höhendaten enthalten sind, aber nicht in den Tracks. Und wenn ich eine andere Karte auswähle (entweder eine andere Region, oder die rudimentäre Basiskarte), verschwinden die Höhendaten aus der Route. Insofern müssen irgendwelche Höhenmodelle in der Karte sein. Bei Routen bekomme ich immer Höhendaten angezeigt, aber eben nicht bei Tracks.

Das ist ja das merkwürdige. Und wie gesagt - das nachträglich Berechnen der Höhendaten hat bei mir NOCH NIEMALS funktioniert.

Gruß
Thoralf

Höhenlinien sind aber nicht gleich ein digitales Höhenmodell! Sowas ist deutlich komplexer und mich würde es nicht wundern, wenn die velomap nicht über ein digitales Höhenmodell verfügt.

Dann beantworte mir bitte folgende Fragen:

(1) Warum sehe ich ein Höhenprofil bei einer Route, wenn ich Velomap benutze?
(2) Warum sehe ich das Höhenprofil nicht mehr, wenn ich den Velomap ausschalte?

Gruß
Thoralf

Gute Frage, vielleicht hat die Velomap mittlerweile doch das SRTM-Höhenmodell integriert? Ich wollte nur darauf hinaus, dass die Höhenlinien in einer Karte in der Regel zunächst erstmal nur transparente Kartenkacheln sind, die eben nur den Verlauf der Höhenlinien wiedergeben. Die werden einfach über die eigentliche Karte drüber gelegt. Das digitale Höhenmodell liefert dir jedoch zu konkreten Koordianten (x,y) einen konkreten Höhenwert. Und denen allein aus dem Verlauf der Höhenlinien zu bestimmen ist eine durchaus nichttriviale Sache

Das stimmt. Ist bei mir genau so. Höhengrafik in der Route vorhanden und beim umwandeln in einen Track geht die Höhengrafik verloren.
Lösung: Den Track aus BC speichern, in GPSies hochladen, Höhendaten neu berechnen, speichern und zurück nach BC transportien. Dann wird auch beim Track die Höhengrafik angezeigt.

Die Software braucht nur die Schnittpunkte des Tracks mit den Höhenlinien ermitteln und die Höhe der Trackpunkte aus den Höhenwerten der Höhenlinien an diesen Schnittpunkte interpolieren. Bei Höhenlinien im 10m-Raster kommt dabei ein ganz ordentliches Ergebnis zustande.

Weißt du, dass das so geschieht oder vermutest du das?

Und auch rein mathematisch würde mich interessieren, wie man das macht: Die Schnittpunkte von einem Track und den Höhenlinien berechnen. Beide liegen ja nur als Polygonzug vor...

In der Mathematik sind das jede Menge Strecken, die sich schneiden. Davon die Schnittpunkte zu errechnen ist von der MAthematik her trivial. Einzig die Menge mchts.

Genau das meine ich, N viele Punkte im Track und M viele Punkte im Höhenlinienmodell macht etwa NM viele Schnittpunktberechnungen. Das scheint mir zu aufwändig, das müsste auch schneller gehen. Hinzu kommt übrigens noch die Überprüfung, ob der Schnittpunkt innerhalb der Strecken liegt oder womöglich außerhalb (was häufiger der Fall sein dürfte). Außerdem ist es gerade bei einer Straße, die in etwa einer Höhenlinie folgt, nicht unüblich, dass ein Streckenabschnitt des Tracks die Höhenlinie mehrfach kreuzt. Und viel häufiger ist der Fall, dass eine Streckensegment des Tracks gar keine Höhenlinie kreuzt. Welchen Höhenwert ordent man da zu? Alles nicht so einfach...

jetzt habe ich mir das Verhalten von BaseCamp nochmals angesehen und kann meine in einem vorhergehenden Beitrag geschilderten Beobachtungen noch etwas erweitern. Wenn ich eine Route auf einer routingfähiger Karte mit Höhenmodell (z.B. Garmin TopoFrankreich) erstelle und diese anschließend in einen Track durch BaseCamp umwandeln lasse, bleiben die Höhendaten erhalten. Bei Erstellung einer Route auf einer routingfähiger Karte ohne integriertes Höhenmodell (z.B. OSM-Fietsmap) weist die Route zwar ein recht rudimentäres Höhenprofil auf, dieses geht jedoch bei Umwandlung in einen Track durch BaseCamp verloren. Ich vermute, dass BaseCamp bei der Erstellung der Route irgendwoher, möglicherweise aus den Daten zu den Höhenlinien, so etwas "ähnliches" wie ein rudimentäres Höhenprofil ermittelt und im Rahmen einer Route auch anzeigt.
Wenn Routen zur Navigation in einem GPS-Gerät benutzt werden, muss jeweils vom Gerät nach Aktivierung einer solchen Route die Wegeführung neu berechnet werden. Soweit nicht nach Luftlinie zwischen den einzelnen Wegepunkten navigiert werden soll, ist der vom Gerät zu ermittelnde Streckenverlauf von der jeweils eingesetzten Karte abhängig und kann daher durchaus auch unterschiedlich ausfallen. Vor diesem Hintergrund sind Höhenprofile von Routen ohnehin keine verlässliche Größe. Ich gehe mal davon aus, dass die in BaseCamp hinterlegten Regelungen zur Erstellung von Höhenprofilen für Tracks deshalb die wie auch immer zustande gekommenen Höhenprofile von Routen ignoriert werden und bei Bedarf bzw. durch Aufruf einer dafür eingerichteten Prozedur für Tracks neue Höhenprofile erstellt werden, wenn ordentliche Höhenmodelle verfügbar sind. So ähnlich dürfte es auch in zumindest einigen Baureihen der Garmin-Outdoorgeräte ablaufen. Ich konnte schon wiederholt nach Aktivierung eines Tracks einen Hinweis an meinem Oregon lesen, dass der Track und dazu gehörende Höhendaten aus einer auf dem Gerät befindlichen Karten eingelesen werden.

Ich auch nochmal, demnach verhält es sich so:
Ich lege in BC eine Route an, indem ich Anfangs- und Endpunkt in die Karte klicke. BC macht daraus zwei <rtept>s und sucht in der Karte nach einer Verbindung dieser beiden Punkte, die den Präferenzen entspricht, also Straße, Waldweg, Fußweg oder was auch immer. Diese Wege müssen natürlich als solche in der Karte vorhanden sein. Diese Wege erscheinen nun nicht als <rtept>s in BC, sondern als <gpxx:rpt>s (Garmin gpx Extensions) als Kindelemente des ersten <rtept> und ich verstehe diese als eine Art Link auf in der Karte hinterlegte Daten. Diese <gpxx:rpt>s enthalten keine Höhendaten (<ele>).
Wenn ich nun statt der velomap die Globale Karte darunter schiebe, sind diese Wege i.A. da garnicht vorhanden, die "Links" zeigen ins Leere. Eine Route in BC ist demnach nicht einfach eine Folge von <rtept>s, so wie ein Track eine Folge von <trkpt>s ist, sondern eben eine Basecamp-Route im beschriebenen Sinn.
Beim Umwandeln in einen Track werden dann einfach diese <rtept>s und <gpxx:rpt>s als <trkpt>s gesetzt, natürlich ohne Höhen.
Nachvollziehen lässt sich das, indem man sich die als gpx-Datei exportierte Route und Track in einem Editor anschaut.
Also: eine Route ist eine Folge von routepoints auf der Basis eine unterliegenden Karte (mit Wegen, Straßen usw), ein Track ist eine Folge von trackpoints ohne Bezug zu einer Karte.

So oder so ähnlich.