Ich habe das Schietwetter heute zur Planung in BaseCamp mehrerer möglicher Routen zum Forumstreffen 2017 nach Erfurt genutzt zur Suche nach dem günstigsten Höhenprofil.
Auf der L1015 bei Rüdigershagen am Aussichtspunkt Unterdorf zeigt das Höhenprofil für eine kurze Strecke von ca. 500 m eine Neigung (Steigung) von 177%.
Bisher habe ich so etwas in BaseCamp noch nicht erlebt. Wer hat dazu eine Idee?

Das heißt also 175 m Anstieg auf 100 m Entfernung. Solche Steigungswerte können an Steilwänden auftreten, bei denen der Straßenverlauf nicht präzise ist. D. h. man wechselt schlagartig vom normalen Verlauf im Tal zu einer Position oben am Berg. Ein derartiger Fehler kann auch bei Deinem Kartenmaterial außerhalb der Alpen auftreten. Es können z. B. einfach falsche Höhenwerte hinterlegt worden sein. 177 % sind schon eine Ansage - damit kannst Du ganz erheblich Eindruck schinden

Peter,
mit welchem Höhenmodell arbeitest Du? Ich habe mal eine kurze Strecke über die L 1015 zwischen den Kreuzungen mit der L 2048 bzw. L 2043 erstellt. Dazu zeigt mir Basecamp auf Basis des Höhenmodells meiner alten TopoDeitschland, Version 2, einen plausiblen Verlauf an. Höhe an der Kreuzung mit der L 2048 = 277m und an der Kreuzung mit der L 2043 = 462 m. Die max. Höhe dieser Strecke beträgt 478 m. Ich hoffe, dass ich eine richtige Teilstrecke gewählt habe. Den von Dir benannten Aussichtspunkt habe ich auf meinen Karten (Garmin Topo bzw. OSM- Freizeitkarte leider nicht gefunden.

mfg, horst

Kleiner Nachtrag: im steilsten Verlauf des Höhenprofils geht es über knapp 300 m von 407 m auf 459 m hinauf.

Gerade bei OSM treten auch kurzfristig und kurzzeitig Fehler auf. Es gibt durchaus auch Situationen, wo z. B. das Garmin-Navigationsgerät an bestimmten Stellen abstürzt, da dort Fehler in Kacheln auftreten. Mit einer neuen Version der Karte kann das dann schnell behoben sein. Es lohnt sich also, die OSM-Karten upzudaten.

. . . . und ich habe dann wohl etwas voreilig durch Lieferung anderer Daten diesen "Heldenanstieg" wieder etwas relativiert . . . .

Soweit ich weiß, erfasst OSM aber gar keine Höhendaten. Die Probleme stammen aus dem hintrlegten Höhenmodell oder aus dem Zusammenspiel von OSM und dem Höhenmodell. Hochauflösende Höhenmodell gibt es meines Wissens nicht kostenfrei.

Ich hatte die Route mit Komoot geplant und dann nach BaseCamp exportiert. Auf BaseCamp habe ich die Velomap Karte: Velomap_ger_30.08.16 mit Höhenlinien: Velomao_srtmger ´_04.11.2012,
Die genaue Stelle ist die L1015 bei Rüdigershagen nach der Kreuzung L1015/K232 Richtung Hüpstedt in der langezogenen Kurve vor den Serpentinen.

177 % sind wirklich éine Ansage und entsprechen sicher nicht dem tatsächlichen Profil ...und ich bin kein Steigungsheld. Darum hatte ich schon bei der Planung Schmerzen in den Beinen und überlegt, wie ich das Rad dort hoch bekomme Noch Mal genau geschaut sind es 85 Höhenmeter auf eine Strecke von ca. 500 Meter, das sind 17 % (wenn ich richtig rechne). Für eine Landesstraße ganz ordentlich, oder?

Hallo Peter!
Eine Karte mit Höhenlinien muss noch lange nicht auch ein Höhenmodell haben. Eine Karte mit Höhenmodell muss nicht unbedingt auch Höhenlinien haben...
Standardmäßig haben die meisten freien auf dem OSM-Projekt basierenden Karten kein Höhenmodell, bzw. wenn denn nur eines mit einem 90m-Raster. Die Garmin-Topo-D-Karten haben ein 25m-Raster.
An jeweiligen Eckpunkten ist neben den Koordinaten auch ein Höhenwert hinterlegt. Quasi eine transparente Karte mit einem 25m-Raster dass die Topographie wieder gibt.

Alles was zwischen den Eckpunkten des 90 oder 25m-Rasters wird nur errechnet (interpoliert). Sprich da kann in diesem Quadrat ein spitzer Berg sein, aber auch ein Loch... Und wenn dann mal an einer Stelle eine Höheninfo fehlt, kommt es mal schnell zu solch netten Ergebnissen... Dementsprechend genau, oder besser ungenau, sind die Höhenprofile...

Du hast in Komoot deine Tour geplant, automatisch wurden im Hintergrund die Höheninformationen ergänzt. Nach dem Import in BaseCamp hast du vermutlich was geändert? Und damit auch unwissentlich die Höheninformationen geändert.

Du kannst den fertigen Track auch in gpsies mit den fehlenden Höheninfos ergänzen. Dazu nur anklicken, das die vorhandenen Höheninfos ersetzt werden sollen. Dann erneut in BaseCamp importieren.

Wenn du hier im Forum mal nach Höhe u. GPS suchst, dann hast du die nächsten Abende Lesestoff genug...

So ähnlich mache ich das auch: Planung in Basecamp, exportieren, mittels GPXEditor Höhen dazu laden und nach Korrektur der <gpx>-Element-Attribute in Basecamp reimportieren. Etwas umständlich, aber zuverlässige Höhen. Der GPXEditor kann auch noch anderes, vor allem die Point Reduction ist um Welten besser als die von Basecamp, letztere unbrauchbar.

mit Höhenmodellen von GPSies habe ich vor Jahren mal gearbeitet und dabei sehr häufig völlig fehlerhafte Höhenprofile erhalten. Das mag sich inzwischen zum Positiven verändert habe. Aber ich arbeite jetzt schon viele Jahre mit über kostenpflichtige Karten von Garmin zur Verfügung gestellte Höhenmodelle. Das sind bei mir neben der TopoDeutschland in der alten Version 2, die TopoFrankreich und eine TopoEuropa, welche vor Jahren mal mit meinem Oregon 450t in meinen Besitz gelangt ist. Bisher konnte ich bei den aufgrund dieser Höhenmodelle ermittelten Höhenprofilen keine wesentlichen Abweichungen gegenüber den in der Realität angetroffenen Verhältnissen beobachten.

in dem von mir nachvollzogenen Ausschnitt der hier In Rede stehenden Streckenführung besteht zwischen den mir vorliegenden OSM-Daten und dem aktuellsten Update der CityNavigator von Garmin keinerlei Unterschied. die Straßenführungen sind völlig deckungsgleich.

Das wäre ja eine Höhendifferenz von fast 900 Metern. Das lässt sich nicht durch die Ungenauigkeit des Höhenmodells oder mangelnde Deckungsgleicheit von Kartendaten und Höhenmodell erklären. Wie sieht denn das Höhenprofil aus? Da müssten ja Werte weit außerhalb der 300 bis 500m vorkommen, die man in der Gegend tatsächlich vorfindet.

Ich hatte solche Fälle schon ab und zu mit den frei verfügbaren, auf den NASA/SRTM-Daten basierenden Höhenmodellen. Ursache waren "Löcher" im Höhenmodell, d.h. Stellen an denen eine negative Höhe angezeigt wird. Beheben kann man solche Effekte, indem man Trackpunkte mit unplausiblen Hohenwerten löscht oder etwas verschiebt.

Hallo Peter,
wenn ich mir die Strecke mit Google plane und als kml exportiere, dann erhalte ich im Höhenprofil maximal 25%.
Solltest Du nicht wissen, wie das geht:
Diese Linkadresse bei http://www.gpsvisualizer.com eingeben und kml.File erzeugen. Speichern und mit Google Earth öffnen. Oder Du importierst es in BaseCamp.

Lieben Gruß
Jürgen, der sich von dem Glauben an reale Höhenangaben bei BC oder sonstwo längst verabschiedet hat.

na ja, die meisten "Ungereimtheiten" dürften eher am benutzten Höhenmodell als an BaseCamp oder vergleichbaren Programmen liegen. Die von mir in meiner nun schon mehr als 10jährigen Praxis beobachteten erheblichen Abweichungen traten immer bei Nutzung relativ grobmaschiger Höhenmodelle auf. Selbst bei engmaschigen Höhenmodellen, egal wer diese nun liefert, sollte man nie vergessen, es handelt um Modelle und nicht um an jedem beliebigen Punkt gemessene exakte Werte.

Hallo Arnulf,

die "gängigen" OSM-Garmin Karten haben evtl. Höhenlinien, aber nie ein Höhenmodell. Dieser Teil des Garmin-Formates ist derzeit noch nicht erforscht. Es gibt manche Anbieter, die das Höhenmodell aus vorhandenen Garmin-Karten auslesen und mit den OSM-Daten zu einer Karte schreiben. Das ist aber nicht so wirklich legal.

So viel ich weiß nimmt BaseCamp das beste Höhenmodell, was es finden kann und dies wird recht schlecht sein, wenn man keine Topo-Karte hat. In der CityNavigatoren ist zwar ein Höhenmodell drin, aber das ist mehr schlecht als recht. Da ist es deutlich besser den Track zu exportieren und dann mit Drittsoftware die SRTM-Daten reinschreiben zu lassen und dann wieder zu importieren. Schade, dass BaseCamp dies nicht selber unterstützt. Aber Garmin verkauft da halt lieber ihre Topo-Karten

als ich seinerzeit von meinem VISTA HCx auf das Oregon450 umgestiegen bin, hatte ich mich wegen der zumindest damals ohnehin nur gegen Entgelt erhältlichen "ordentlichen" Höhenmodelle für die Version 450t mit der vorinstallierten topografischen Europakarte entschieden. Diese Karte enthält zwar nicht alle Details, die man heutzutage in jeder guten OSM-Karte finden kann, aber damals war die Informationsdichte besser als die bis dahin erfassten und verfügbaren OSM-Daten. Und heute kann ich immer noch auf das recht gute Höhenmodell dieser Karte zugreifen. Die Handhabung in BaseCamp ist dann nun wirklich äußerst simpel, selbst dann, wenn ich zur Planung meiner Strecken mit irgendeiner OSM-Karte arbeite. Unter Berücksichtigung meines Hanges zur Bequemlichkeit hat sich der damals bezahlte Mehrpreis durchaus gelohnt. Da habe ich schon häufiger für andere weit weniger hilfreiche Dinge mehr Geld ausgegeben.

Hallo Markus,

ich habe auf BaseCamp die Höhenlinien von Velomao srmt germany installiert. Wie groß das Raster ist weiß ich nicht. Ich war davon ausgegangen, dass BaseCamp aus dem Raster der Höhenlinien ein zuverlässiges Höhenmodell erstellt. Bis jetzt hat das auch immer funktioniert und stimmte mit der Realität weitgehend überein.
Nachträglich habe ich für die fragliche Steigung dann anhand der ermittelten Höhe und der Strecke eine Steigung von ca. 17 % errechnet.

Hallo Jürgen,
Danke für die Links.
Obwohl diese Hin- und Herschieberei lästig ist, ist sie für ein überzeugendes Ergebnis manchmal notwendig. So ganz ins Blaue möchte ich nicht starten. Ich plane die Strecke auch weil ich wissen möchte was mich unterwegs erwartet. 25% maximal sind auch eine echte Hausnummer.

Hallo Rainer und @ all

Danke für Deine/Eure Hilfe und die Erklärungen zur Sache. Da habe ich wieder einiges hinzugelernt. Und ansonsten werde ich mich an der Erkenntnis von Jürgen orientieren:

Zitat: "Jürgen, der sich von dem Glauben an reale Höhenangaben bei BC oder sonstwo längst verabschiedet hat."

Auch bei mir ergaben sich recht realistische Höhenprofile für meine Strecken in Basecamp (meist verwende ich OpenFietsMaps), wenn ich dort die Route berechnen ließ. Beim Hochladen in GPSies zeigten sich beim Neuberechnen des Höhenprofils keine erheblichen Unterschiede zu den Basecamp-Ergebnissen. Was aber immer wieder einmal passiert, ist, dass die OSM-Karten Fehler aufweisen. Das fängt mit nicht verbundenen Straßenabschnitten an und endet bei Fehlern, die offensichtlich Navigationsgeräte zum Absturz bringen können. Rein mathematisch gesehen, könnten das Divisionen durch Null sein, die nicht ordentlich abgefangen werden usw. Neben der Tatsache, dass eine geringe Abweichung von Straßen oder Höhenzuordnungen zu drastischen sprunghaften Höhenänderungen führen kann, könnten auch bei der Berechnung von Steigungen Strecken, die aufgrund von Kartenfehlern als unsinnig kurz berechnet werden, bei der Ermittlung des Steigungswertes (Höhendifferenz / Strecke) zu gigantischen Werten führen. Das sind Fehler, die andere mit z. B. neuerem oder älterem Kartenmaterial des gleichen Typs evtl. nicht nachvollziehen können.

Es sollte hier aber Leute geben, die deutlich mehr zu diesem Thema sagen können. Ich persönlich würde solche seltsamen Angaben nicht überbewerten, wenn sie nur vereinzelt auftreten. Ein kachelabhängiger Absturz meines GPSMap 62s (und schon zuvor beim eTrex 30) trat bislang typischerweise einmal pro Woche Tour (also ca. alle 1000 km) auf. Diese Fehler waren nachvollziehbar ortsabhängig. So konnte ich z. B. auch lange Zeit durch Bremen fahren und hatte schon fast vorhersagbar immer im etwa gleichen Gebiet Komplettabstürze des Navis. Irgendwann verschwinden die Probleme (Kartenupdate), dafür treten sie dann an anderer Stelle evtl. neu auf.

Wie sah denn das Höhenprofil in komoot aus?
Und klär mich auf: Du planst auf komoot, exportierst, öffnest das dann in BC um zu planen ... ? Welchen Hintergrund hat das denn?

Danke Arnulf,
so wissenschsftlich habe ich mich dem Thema nicht genähert. Ich gebe meine Daten ein, das Programm rechnet und ich sehe das Ergebnis, das ich dann ggf. anpasse. So einfach soll das sein.
Bisher hat das auch immer funktioniert. Aber ich habe den Fehler gefunden: Genau wie >Markus weiter oben schon bemerkt hat, habe ich die mit Kommot erstellte Route in BaseCamp noch mal geändert. Damit ist die Steigungsberechnung in die Hose gegangen.

Hallo Bernd,

ich hatte erstmalig mit Komoot geplant und im Höhenprofil war mir starke Steigung aufgefallen. Da mit Komoot keine Steigungsprozente anzeigt hatte ich das Ergebnis nach BaseCamp exportiert, denn dort kann ich die Steigung in %-Werten ablesen.
Durch nachträgliche Änderung der Route habe ich das Ergebnis verfälscht. Inzwischen habe ich alles neu nach BaseCamp exportiert und komme auf eine realistische Steigung zwischen 9,5 - 11 %.

Bitte keine fremden Bilder posten!

Screenshot

Es handelt sich doch um diesen Abschnitt? Hm, da fällt mir nix besonderes auf, sieht doch recht realistisch zum Verlauf der Höhenlinien aus, oder?
http://fs5.directupload.net/images/161213/wdna99sg.png

Endgültig adieu sagte ich hier:
Vorne, hinten, rechts und links gehts nur noch abwärts und mein Garmin sagt, ich habe noch 150hm vor mir.

ps: Die kamen erst später, als Garmin sagte, es ginge bei 42° nur noch bergab.

Zum Glück hatte ich solche groben Ausreißer unterwegs noch nicht. Wirklich verlassen würde ich mich auf das Höhenprofil, welches mit meinem Track auf das Navi geladen wird, nicht, aber meist ist es doch recht brauchbar um eine Idee zu bekommen, was mich noch an Höhenmetern (rauf oder runter) erwartet.

Das Höhenprofil meiner Tracks erzeuge ich ausschließlich mit GPSies. Bei Routenberechnungen in Basecamp wird ein Höhenprofil erzeugt, auch wenn ich OSM-Karten verwende. Ich erzeuge aber aus den einzelnen Routen immer Teiltracks, die ich anschließend zu einem Gesamttrack zusammenfasse. Dabei gehen die Höhenmeter in Basecamp verloren. Sie werden unter GPSies dann wieder ergänzt.

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.

Ich sage nur, dass es so gemacht werden könnte. Wie Garmin es tatsächlich macht, bleibt deren Geheimnis.
Eine Garmin-IMG-Datei enthält ja nicht nur eine Ansammlung von Polygonen, Polygonlinien und Punkten und deren Koordinaten und Eigenschaften. Damit wäre weder das Routing noch die Darstellung von hochaufgelösten Zoom-Leveln möglich. Damit das möglich ist, wird die Karte in Kacheln aufgeteilt und für jede Kachel die darin enthaltenen bzw. durch die Kachel führenden Elemente in der IMG-Datei abgespeichert. Der Aufwand, sich schneidende Track- und Höhenliniensegmente zu suchen, hält sich daher in Grenzen.

Wie die hier geschilderten Erfahrungen mit Basecamp zeigen, funktioniert das in der Praxis ja auch. Dass es bei OSM-Karten, genauer: bei aus OSM-Daten mit mkgmap erzeugten Karten nur bei Routen, nicht aber bei Tracks funktioniert liegt vielleicht daran dass die mit mkgmap erzeugten Karten nicht 100%ig mit dem (nicht offen gelegten) Garmin-Format kompatibel sind.

Diese "... führenden Elemente ..." sind nach meinem Verständnis "Wege", also Straßen, Wege, Pfade, ..., welche in Teilstücken Teile eine Route sind. Diese "Wege" sind es, die Höhenlinien schneiden, nicht Routen und schon garnicht Tracks.


Nach meinem Verständnis liegt das daran, dass eine Route etwas anderes als ein Track ist, s.o. Trotzdem nervt es mich natürlich auch, dass ich mir zur weiteren Planung, nachdem ich aus einer Route einen Track erzeugt habe, per Export/Import erst im GPXEditor die Höhen dazu laden muss. Für die erste Grobplanung benutze ich daher lieber Tools im Web (Brouter, Radroutenplaner, Naviki, ... die einem direkt die Tracks mit Höhen als gpx-Datei liefern.

Nebenbei: mit diesen Bemerkungen möchte ich keinem, der in diesem Faden über Höhenmodelle und dergleichen geschrieben hat, zu nahe treten, denn davon habe ich (bisher) wenig Ahnung.

Hallo Markus,


Wir reden aneinander vorbei. Ich meinte nicht die Software, sondern das Datenformat. Dass ein Track Höhendaten (und noch vieles mehr) enthalten kann, weiß ich. Aber eine Route?

Lästig bei Basecamp ist das Hinzufügen von Höhendaten bei Tracks, die über Staatsgrenzen verlaufen. Leider werden auch Trackpunkte, die außerhalb der jeweils selektierten Karte liegen, mit - natürlich falschen - Höhendaten versehen. Man muss recht umständlich den Track an den Grenzen teilen, dann den einzelnen Segmenten die Höhendaten zuweisen, dann den Track wieder zusammensetzen, die dadurch entstehenden doppelten Trackpunkte löschen und dem zusammengesetzten Track wieder den ursprünglichen Namen geben.

Grüße
Andreas

Warum machst Du das dann nicht länderübergreifend/grenzenlos bei http://www.gpsvisualizer.com/elevation oder in https://www.caminaro.com ?

das passiert doch nur dann, wenn die verfügbaren Höhendaten an den "Staatsgrenzen" aufhören. Man sollte schon Höhenmodelle für den gesamten Streckenverlauf nutzen. Wo sollen sonst die Höhendaten herkommen?

Ich finde ja überhaupt und ganz allgemein, dass man mit caminaro oder gpsies geniale Planungstools zur Verfügung hat, nicht nur wegen der Höhendaten. Nachdem ich mich mit dem Garmin-Vorgänger (ich glaube, das hieß mapsource) schon nicht anfreunden konnte, habe ich es mit basecamp gar nicht mehr ernsthaft versucht.

Hans

Hallo kosemuckel,


Ist Deine Frage ernst gemeint? Ich habe das bisher nicht gemacht, weil ich nicht von dieser Möglichkeit wusste. Danke für Deinen Hinweis.

Grüße
Andreas