Nav6 Neuberechnung nach Routenübertragung

[qtreiber]

Das eine Route, die auf einer anderen Karte geplant, und wenn auch danach auf der "gleichen Karte wie im Navi" angezeigt und danach übertragen zu Problemen führt, wissen wir hier ja nun alle. (Daher immer neu berechnen lassen von alten Route auf der aktuellen zu verwenden Karte!)
Aber sehr interessant mit dem WP. Werde ich mal bei mir zwischen zwei Karten auch testen! Danke nochmal.

DAS hatte ich ja mit seiner Originalroute gemacht und die ewig langen Wartezeiten wurden bestätigt. Erst als ich seine Route komplett neu auf meinem System nachgezogen hatte, flutschte alles wie gewohnt sehr schnell.

Gleiches habe ich mehrfach mit Fremdrouten festgestellt. Trotz gleichem Kartenmaterial und identischen Grundeinstellungen. Deshalb ziehe ich Fremdrouten immer neu auf meinem System. Geht grundsätzlich sehr schnell und ich bin unterwegs auf der sicheren Seite.

Mit den WP wäre interessant. Bitte berichte!

 

[Uli G.]

@TrippleBlack1250 @phuLphiL @qtreiber
Hallo zusammen,
ich habe mir die beiden kleineren Dateien mal nebeneinander angeschaut (Photos angehängt), da sind schon Unterschiede feststellbar. Die ersten Unterschiede im oberen Teil der Dateien sind u.a. auf die unterschiedlichen Zeiten und die unterschiedlichen Koordinaten des ersten Wegpunktes zurückzuführen, auf eine unterschiedliche Postleitzahl (?), andere Schreibweisen von Straßen- und Ortsnamen, etc. Das dürfte noch kaum zu Problemen führen, ich werde aber trotzdem mal die Koordinaten des WP der nicht funktionierenden Garmin-Datei einsetzen um zu sehen, was passiert.
Sollte das am Verhalten der OSM-Datei nichts ändern, geht es unten (zweites Photo) weiter, eine Änderung nach der anderen, bis es auch mit der Garmin-Datei funktioniert.
Was mir allerdings (bei beiden!) aufgestoßen ist, ist die Verwendung von Umlauten, die Garmin (amerikanische!) Geräte und Software zumeist nicht mögen. Für Windows war früher ein Name da beendet, wo ein Umlaut im Namen stand. Im Manual für den StreetPilot 2820 (und Mapsource u. Basecamp m.W. auch) steht für die Ortssuche explizit, daß Umlaute durch den ersten Vokal des Umlautes zu ersetzen seien, also bei St. Pölten nach St. Polten zu suchen sei (und Straße mit Doppel-s zu schreiben ist ). So halte ich das seit jeher auch in Basecamp, und habe wenig Probleme damit. Die uns geläufigen Umlaute sind kein nativer Bestandteil des ASCII-Zeichensatzes, es sind vielmehr Steuerzeichen für RS-232 und andere Schnittstellen, mit denen "früher" (noch in/bis WinNT) direkt auf Schnittstellen/Hardware allgemein zugegriffen werden konnte (sowas ist bei moderneren Windowsversionen nicht mehr ohne weiteres möglich, da liegt eine Windows Funktion dazwischen, die allerdings auch bei manchen Softwarepaketen die Umlaute als Steuerzeichen interpretiert ).

Uli

 

[TrippleBlack1250]

Servus Uli!
Danke, dass auch DU dir die Mühe machst. Ich tue selbiges/ähnliches ebenfalls, wenn es die Zeit erlaubt. Ich möchte nur sicherstellen, dass wir alle das selbe Verständnis haben: der Wegpunkt, der Probleme macht ist Avanti-OSM. Zumindest lassen mich die Halbsätze

Koordinaten des WP der nicht funktionierenden Garmin-Datei einsetzen

und

eine Änderung nach der anderen, bis es auch mit der Garmin-Datei funktioniert.

vermuten, dass mein Post nicht richtig angekommen ist und du annimmst, dass der WP Avanti-Garmin der problematische Punkt ist.



Danke und Liebe Grüße - Rallye

 

[TrippleBlack1250]

Ich habe lange herumprobiert und mit viel try-and-error habe ich das Problem identifiziert. Zuerst dachte ich, dass die Koordinaten, die sich ab der 6. (oder so) Nachkommastelle unterscheiden das Problem machen. Denn nach einem Export des Avanti-WPs, Änderung der Koordinaten und re-Import des Avanti-WPs war der Import der Route am Nav6 so blitzschnell wie mit den Garmin-Koordinaten. Ich wollte mich an die Nachkommastellen "herantasten" und habe zuerst die Anzahl der Nachkommastellen bei "lat" angepasst (1 Stelle am Ende gelöscht). Und wieder flutschte es nach dem Import. DAS konnte ich nicht glauben, dass dies das Problem ist. So habe ich den WP exportiert und wieder importiert ohne etwas zu ändern - und siehe da; schnell wie wenn's unter Garmin erzeugt worden wäre.
Dem bin ich nun nachgegangen und habe herausgefunden, dass es an der gpxx:Subclass des WPs liegen muss.

Ich hänge hier 3 Dateien mit "langsam" und 3 Dateien mit "schnell" an (SPEED in der Dateibezeichnung ist entweder "langsam" oder "schnell").
Avanti-OSM-SPEED.gpx ist die Route exportiert aus BC.
Waypoints-SPEED.gpx bzw. Route-SPPED.gpx sind die "Waypoint-Datei" bzw. "Route-Datei", die bei der Routenübertragung auf das Nav6 übertragen wird. Und zwar im Zustand BEVOR ich die Routen importiert habe.

Im Prinzip sehen die Datei-Paare immer ident (wenn ich jetzt einmal vom Zeitstempel absehe) aus. Der einzig gravierende Unterschied - und ich denke, das macht die lange Neuberechnung aus - ist das <gpxx:Subclass> </gpxx:Subclass> beim Avanti-WP.
In der "langsamen" Version finden wir
<gpxx:Subclass>2F08B063C10306000E011200000000000000</gpxx:Subclass> und in der "schnellen" Version steht
<gpxx:Subclass>000000000000FFFFFFFFFFFFFFFFFFFFFFFF</gpxx:Subclass>

Ein rasches Googeln über die gpxx:Subclass hat mich noch nicht erleuchtet, und wie man solche "faulen Eier" in seiner Datenbank findet weiss ich auch noch nicht. Tatsache ist, dass dies der einzige Unterschied ist, der offensichtlich den Unterschied in der Berechnungszeit ausmacht.

Wie gesagt: lediglich den WP exportieren und wieder importieren (ich hab nicht ausprobiert den WP "drüber zu importieren", sondern hab den WP im BC vor dem re-import umbenannt und danach den WP re-importiert und in der Route ersetzt) - that's it.
Ich werde mich damit auch weiterhin beschäftigen, wenn Ihr zu neuen Erkenntnissen kommtwäre es nett sie ebenfalls zu teilen.

LG Sepp

 

[Reisetourer]

....puh , jetzt hab ich alle Post ein 3.mal gelesen.
Ich finde das Thema hier sehr spannend und verfolge es gerne. Nur um jetzt nicht den Faden zu verlieren, für mein Verständnis.
Es ging darum, eine BC Route auf das NAV zu exportieren, hier am NAV wurde dann die Route mit der App (Routenplanung) aus dem Speicher/Speicherkarte des NAV Importiert.
Dies wiederum führte zu:
A - der Import der Route über die App Routenplanung nur sek. dauert und wenn man dann die Route Startet es die 1:40min dauert bis er die Route berechnet hat um zu navigieren.
B - Die Ursache der langen Berechnung, eventuell aus jetziger Sicht, durch einen Importierten WP aus einem anderen Kartenmaterial hervorgerufen wurde.
C - Sollte ich nur mit BC arbeiten ohne "Fremdimporte" eventuell dieser Fehler der langen Neuberechnung nicht auftauchen würde.
Bitte Verbessert mich wenn ich jetzt was falsch verstanden habe.
Danke Axel

 

[qtreiber]

Schon immer habe ich "Fremdimporte", eine Route, auf meinem System neu mit dem Routentool nachgezogen. Geht sehr schnell und erspart Ärger und Fehler unterwegs.

 

[Orlando123]

Schon immer habe ich "Fremdimporte", eine Route, auf meinem System neu mit dem Routentool nachgezogen. Geht sehr schnell und erspart Ärger und Fehler unterwegs.

Macht das z. B. BC nicht automatisch wenn Route/Fremdimport verwendet werden soll?
Korrigiert BC das dann nicht auch automatisch so das der BMW Navigator damit klar kommt?

 

[qtreiber]

Nein. Wenn überhaupt wird die Fremdroute nur neu berechnet. Das bedeutet nicht, dass alle Ursprungsfehler raus sind. Anderes Kartenmaterial und andere Einstellungen kommen hinzu.

Auch von möglichen Umwegen/Konvertern halte ich nicht viel. In dieser Zeit habe ich die Fremdroute locker auf meinem System neu erstellt - und diese passt dann.

 

[TrippleBlack1250]

@Reisetourer
Fast alles richtig verstanden. Nur dieser Punkt ist nicht ganz korrekt:

A - der Import der Route über die App Routenplanung nur sek. dauert und wenn man dann die Route Startet es die 1:40min dauert bis er die Route berechnet hat um zu navigieren.

Sollte lauten:
A - der Import der Route über die App Routenplanung dauert anstatt Sekunden wegen Neuberechnung der Route bis zu mehreren Minuten.

 

[Reisetourer]

@TripleBlack1250
Danke, dann kann ich euch wenigstens weiter folgen