Einfach irgendeinen Trackpunkt löschen.
Danach berechnet BaseCamp die Statistik aus den Trackpunkten und nutzt nicht mehr dass vom GPS Gerät angelegten Statistikeintrag.
Einfach irgendeinen Trackpunkt löschen.
Danach berechnet BaseCamp die Statistik aus den Trackpunkten und nutzt nicht mehr dass vom GPS Gerät angelegten Statistikeintrag.
Die Höhendaten stehen im Track. Beispiel:
<trkpt lat="51.196822402998805" lon="7.208448881283402">
<ele>276.04000000000002</ele>
<time>2024-03-10T08:55:54Z</time>
</trkpt>
Wenn der Track keine Höhendaten hat, benutzt das Gerät die Karte, die die besten DEM-Daten zur Verfügung stellt.
Den Track sieht man aber schlecht wegen den dünnen Linien, aber eine Idee ist es. Ich probier das mal aus. Wobei ideal ist es natürlich nicht. Ich überlege immer noch woran das liegt.
Das ist ein Bug. Ich habe alles Mögliche getestet, ältere Software, andere Karten, nichts hilft.
Warum fällt sowas nicht auf? Nun, es benutzt kaum jemand Fahrrad-routen auf einem Wandergerät. Bei kürzeren Routen tritt der Bug kaum auf. Oder überhaupt Routen. Die meisten folgen einfach der Tracklinie. Radfahrer nehmen in der Regel ein Handy, ein Garmin Edge oder ein Wahoo oder sonstwas, aber so gut wie nie einen Oregon. Hat Garmin auch erkannt, es gibt keinen Nachfolger für das Gerät.
Als Workaround schalte ich die "Neuberechnung bei Verlassen der Route" ein. Das schließt natürlich die Funktion "Route aus BaseCamp übernehmen" aus, Außerdem ist man dadurch auf 50 Routenpunkte beschränkt.
Was ich auch immer mache: den Track unter die Route legen. Ein Track ist unverrückbar und man hat definitiv das, was man geplant hat.
Wie "OSM" routet lässt sich pauschal gar nicht sagen. Das kommt drauf an, wie der Kartenersteller das Routing eingestellt hat. Theoretisch kann man auch Zäune oder Stromleitungen in das Routing einbeziehen, was natürlich sinnlos ist.
Die Straßen bei der City-Navigator sind nicht alle über das TYP File definiert, sondern es wird ein Design benutzt, welches in den Geräten steckt.
Das schöne daran: Je weiter man hereinzoomt, desto dicker werden die Straßen.
Sicherlich kann man das TYP File bearbeiten und den Straßen ein eigenes Design geben. Allerdings haben die Straßen dann nur eine Breite, egal in welcher Zoom-Stufe man ist.
Dieses Tool finde ich gut:
https://sites.google.com/site/sherco40/
Beim Herstellen der Karten werden die einzelnen Wegetypen auf ganz bestimmte Schlüsselzahlen gelegt.
Beispiel: highway=motorway = 0x01. Dieses 0x01 findet man im TYP File wieder. Dahinter legt man das Design fest.
Bei OSM Karten werden die Wege oftmals auf andere Schlüsselzahlen gelegt. Daher ist es eher Zufall, wenn ein TYP File in einer anderen Karte passen würde. Zudem hat jede Karte eine eigene Kennzahl "FID". Diese müsste auch noch geändert werden.
Das Aussehen der Karten wird im TYP-File festgelegt. Dort hat man Schlüssel, hinter denen man ein Objekt ablegt und bestimmt, wie das aussehen soll. Ein Beispiel:
[_line]
Type=0x10600
;GRMN_TYPE: //
UseOrientation=N
LineWidth=4
BorderWidth=2
Xpm="0 0 2 0"
"1 c #FFD621"
"2 c #626262"
String1=0x04,secondary
ExtendedLabels=Y
FontStyle=NoLabel (invisible)
CustomColor=Day
DaycustomColor:#525252
[end]
Meine Karten zeigen viel mehr Objekte, als Garmin Karten. Daher brauche ich auch viel mehr von diesen Typen. Das ist in der Regel kein Problem, es werden jede Menge dieser Schlüssel interpretiert. Das Drivesmart zeigt ein paar dieser Schlüssel nicht an, anders als BaseCamp, Outdoorgeräte, Edges, QLandkarte, Oruxmaps, MapSource.
Hier wurde schlicht ein Bereich nicht berücksichtigt, aus welchen Gründen auch immer. Für mich ist das ein Bug, vielleicht ein schnöder Tippfehler, wer weiß, so tief stecke ich da auch nicht drin. Garmin Karten haben damit kein Problem, da dieser Bereich anscheinend nicht genutzt wird. Daher ist es aus Garminsicht egal.
Mit Hilfe eines Drivesmart-Users konnte ich feststellen, dass nur einige Schlüssel nicht angezeigt werden: 0x1010a-0x10114. Bei meinen Karten waren das secondary, tertiary und unclassified. Die Schlüsselnummern habe ich gegen 0x10600-0x1060a getauscht. Das Drivesmart zeigt nun alles an.
Mit geht es nur um die Darstellung..Die nicht gerenderten Typen können gar nicht Routen.
Ja, das ist ein wenig Arbeit, die sich womöglich gar nicht lohnt.
Ich verschenke Rad und Wanderkarten, die in der Regel auf Outdoorgeräten landen und eher selten auf dem Drivesmart.
Ob das ein Garmintypischer Bug ist?
Ist denn bekannt, welche Typen angezeigt werden und welche nicht?
Vielleicht sind ja nur ein paar betroffenen.
Kann es sein, dass ein Drivesmart TYP-Dateien anders auswertet, als Outdoorgeräte? Speziell Type 0x101 sub type 0x0a to 0x13 scheint es nicht anzuzeigen?
Höhenmeter zum Ziel zeigt die Differenz der Höhe des aktuellen Standortes und der Höhe des Zielpunktes. Am Schlussanstieg, wenn das Ziel oben ist, stimmt die Anzeige also ![]()
Diese "Logik" ist vor langer Zeit nachgefrickelt worden, weil sich viele Leute beschwert hatten, dass 50 Zwischenziele zu wenig seien bzw. Routen auf dem Gerät nicht unbedingt so aussahen, wie im BaseCamp, weil das Gerät manchmal doch etwas anderes macht.
Als das rauskam war mein erster Kommentar dazu, das das ja wohl etwas undurchsichtig zu bedienen ist und man da doch bitte nachbessern sollte. Im Gamin Forum gab es einen Mr Falagar, der solche Vorschläge aufnahm und oft auch umgesetzt hat. Der war aber irgendwann weg und anscheinend ist in der Entwicklung nicht weiter gemacht worden, denn diese krude Logik ist seit Jahren unverändert.
Aus Garmin Sicht verstehe ich das, denn 99% aller Nutzer laufen einfach der Tracklinie hinterher und benutzen Routing nicht.
Die Radfahrer haben mittlerweile alle Handys, Wahoos oder Garmin -Edges. Auf letztere haut man einfach den Track und das Gerät macht automatisch eine Strecke mit Abbieghinweisen daraus.
Wander Navi gekauft und Anfängerfragen
Route übertragen mit irgendeinem Profil außer Luftlinie: Route wird vom Gerät NICHT selbst berechnet, sondern 1:1 übernommen. Bei der Erstellung in BaseCamp kann man mehr als 50 Zwischenziele verwenden, sofern man sie anschließend mit "Routenpunkte entfernen" entfernt. Entfernt werden Punkte "ohne Alarm". Diese Art Route ist an die Karte gekoppelt und kann nur mit dieser angezeigt werden. Auf dem Gerät muss also zwingend dieselbe Karte vorhanden sein. Bei entfernten Routenpunkten kann die Route nicht neu berechnet werden. Außerdem kann die Route im Routenplaner des Gerätes nicht bearbeitet werden.
Route übertragen mit dem Profil Luftlinie: Das ist für das Gerät dasselbe, als wenn man die im Routenplaner erstellt, Die Wegfindung macht das Gerät mit Hilfe der gerade aktuellen Karte und den Einstellungen im Routing. Die Route kann im Routenplaner bearbeitet werden.
.....
Meine Touren plane ich in BC, kreiere dazu Wegpunkte, die auf der identischen Karte zum M700 mit der Aktivität Bergsteigen zur gewünschtennRoute führt. Diese Wegpunkte hab ich bislang ans Montana übertragen und daraus auf dem Gerät eine Route angelegt. Karte ist die Garmin Cycle Map EU......
Verstehe ich das richtig: Du öffnest BaseCamp, guckst, wo eine Strecke her führen könnte und setzt an Stellen, wo du vorbeischauen möchtest einen Wegpunkt. Diese Wegpunkte sendest du an das Gerät. Danach schließt du BaseCamp, schaltest das Gerät ein und erstellst im Routenplaner mit Hilfe der Wegpunkte eine Route?
Kann man machen, aber warum dieser Umstand?
ALARM ![]()
Mit Annäherungsalarm ist die Annäherung in dem Wegpunkt gemeint. Nicht der Alarm von einem Zwischenziel.
Dieser "Alarm" bei den Zwischenzielen mag bei anderen Garmin-Geräten eine Bewandtnis haben. Beim Montana spielt das keine Rolle. Man kann damit nur die Funktion "Routenpunkte entfernen" steuern.
Beim Routennavigieren wird ein Zwischenziel angezeigt. Das ist kein Bug.