Beiträge von chris1234

Die merkwürdigen Luftlinien kann ich auch mit dem Quest I reproduzieren.

Bisher habe ich immer die alte MapSource-Version 6.13.7 verwendet und nie irgendwelche Probleme gehabt. Nachdem ich jetzt mal Routen mit der MapSource-Version 6.16.3 erstellt und aufs Quest übertragen habe, wurde ich nicht nur an einigen Stellen mit den seltsamen zusätzlichen Luftlinien beglückt, sondern das Quest hat sich an einer bestimmten Stelle (reproduzierbar) auch noch so aufgehängt, dass es erst nach ca. einer halben Stunde wieder funktioniert hat! Die entsprechende Stelle bin ich schon zig mal ohne Problem mit dem Quest gefahren.

Ein Routenstück, in dem eine zusätzliche Luftlinie auftauchte, habe ich aus der Gesamtroute herausgelöst und jeweils mit MapSource und BaseCamp ans Quest übertragen.

Ergebnis:
BaseCamp 3.2.1 funktioniert fehlerfrei.
MapSource 6.13.7 funktioniert fehlerfrei.
MapSource 6.16.3 erzeugt auf dem Quest an einigen Stellen Luftlinien, die bei Zoom-Einstellungen unter 800 m auf dem Bildschirm erscheinen. Die Luftlinien verschwinden, wenn man eine Neuberechnung der Route auf dem Quest durchführt.

Ob das Aufhängen auch durch MapSource 6.16.3 verursacht wurde, kann ich nicht mit Gewissheit sagen.

Es wäre für eine Fehlereingrenzung gut, wenn ein Zumo-220-Besitzer auch mal die alte MapSource-Version 6.13.7 ausprobiert. Dass es mit BaseCamp beim Zumo keine Fehler gibt, wurde ja schon in einem anderen thread berichtet.

Die Streckensperrung in 63549 Hüttengesäß-Marköbel ist entfallen.

Die Streckenverläufe und Wegpunkte sind jetzt auf CN2012.10 mit MapSource 6.16.3 gesetzt.

Streckensperrungen für Motorräder

Das einzige, was mir an der fehlerhaften Route "Koblenztagestour 2" auffällt, ist das Zwischenziel "B146 und Staustufe". Es ist in der Route das einzige Zwischenziel, das genau auf einer Kreuzung liegt.

Versetze das mal ein winziges Stück, so dass es nur noch auf der B146 liegt. Wenn das Luftlinienrouting dann weg ist, scheinen die Zumos Probleme mit solchen Zwischenzielen zu haben, die zwei Kartenmerkmalen zugeordnet sind (hier den Straßenlinien "B146" und "Staustufe").

Sowas ist durchaus möglich, weil auch andere Geräte in der Vergangenheit schon Probleme mit ganz bestimmten Zwischenzielen hatten und dann ein unsinniges Routing produzierten.

Das Problem mit den Luftlinienrouten ist vermutlich auf mehrere Faktoren zurückzuführen.

Eine mögliche Ursache liegt in der Definition von Zwischenzielen:
Die alten MapSource-Versionen (bis 6.13.7) speichern in gpx-Dateien Zwischenziele mit 7 Stellen hinter dem Komma, die neueren mit 15.
Bei einem angenommenen Erdradius von 6378135 m bedeutet das für die Genauigkeit der Koordinatenangabe:
MapSource bis 6.13.7: 6,3 cm
MapSource ab 6.13.7: 6,3 pm (Billiardstel m)

Die 6,3 cm möglicher Abweichung von der Straße dürften keine Rolle spielen und soweit ich das festgestellt habe, werden die Zwischenziele in MapSource immer auf der Straße liegend angezeigt, wenn eine Route in der alten Version erstellt und dann in der neuen geöffnet wird.

Schwieriger wird es, wenn die Route auf anderem Kartenmaterial erstellt wurde als das auf dem Zumo vorhandene. Ich habe mehrere Routen mit CN2009 in der alten MapSource-Version erstellt, die alle zu dem Luftlinienrouting auf einem Zumo 220 mit CN2011NT geführt haben.

Die Frage ist, wie die Zumos mit Zwischenzielen umgehen, die neben der Straße liegen. Ich habe leider keine genauen Aufzeichnungen, bei welchen Zwischenzielen das Luftlinienroutimg auftrat. Wahrscheinlich ist tatsächlich ein Fehler in der Software, der zwei neben der Straße liegende Punkte mit einer Luftlinie verbindet, anstatt nur kurze Abstecher von der Straße zu den Zwischenzielen zu berechnen.
Um das Problem etwas einzugrenzen, sollte man daher mal zwei Alternativen ausprobieren:

1. Die Route in der alten MapSource-Version und dem Kartenmaterial, das auf dem Zumo ist, erstellen. Eine vorhandene Route, die ein Luftlinienrouting erzeugt hat, kann man entweder als Vorlage nehmen und eine neue Route "nachklicken" oder man verschiebt jedes Zwischenziel ein kleines Stück auf der Straße. Damit ist sichergestellt, dass es im vorhandenen Kartenmaterial auf der Straße liegt.

2. Das selbe wie in 1., nur mit der aktuellen MapSource-Version.
Vielleicht kann ja ein Zumo-Besitzer das mal durchspielen. Eine Route, bei der das Luftlinienrouting schon in unmittelbarer Nähe zum Startpunkt erzeugt wird, bietet sich da ja für einen relativ schnellen Vergleich an.

Edit: Hatte die Abweichungen in den MapSource-Versionen fälschlicherweise im Bogenmaß gerechnet.

Zitat von Wolfgang_26XX

Die sollten solche Kleinigkeiten im Griff haben.

Ahh, ich wußte natürlich nicht, dass es nur eine Kleinigkeit war.

Dann spann uns doch nicht weiter auf die Folter und erkläre mal kurz, was es war.

Zitat von cterres

Wer bei einem Ausfall eines Webservers oder gar nur der Datenbank lediglich von "technischen Problemen" spricht, brauch sich über Vergleiche mit ähnlichen Vorfällen nicht wundern.

Sie hätten es natürlich auch als ein religiöses Problem darstellen können, dann hätten einige vermutlich sogar mehr Verständnis aufgebracht.

Zitat

Warum wurden die Server erst ab Dienstag nach Pfingsten gewartet und nicht schon am Samstag zuvor?

Ja, die Welt wäre eine bessere, wenn immer alle alles sofort machen würden - möglichst schon, bevor ein Fehler auftritt.

Zitat

Was wäre gewesen, wenn das Shopsystem oder der Kartenupdateserver ausgefallen wäre?

Ich vermute mal, dass es dann nicht mehr funktioniert hätte?

Zitat

Warum lief das US-Forum weiter.

Das ist tatsächlich eins der großen Rätsel der Neuzeit! Wenn bei mir irgendetwas nicht funktioniert, frage ich mich auch immer, warum es bei anderen funktioniert.

Zitat

Warum läuft das deutsche Forum auf Maschinen in den USA, wenn dort das Wartungspersonal erst reagiert, nachdem in Deutschland der gesetzliche Feiertag Pfingsmontag verstrichen war? (in USA ein Arbeitstag)

Ja, Wartungspersonal in Deutschland macht immer alles vor den Feiertagen fertig. Und Rechner, die nicht auf meinem Schreibtisch stehen, waren mir auch schon immer suspekt.

Macht euch mal locker, da ist irgendwo auf der Welt irgend ein bisschen Hard- oder Software kaputt gegangen oder kaputt gemacht worden, das nicht die geringste Relevanz für irgendeine wichtige Funktion irgendeines Menschen hat und ihr regt euch auf, weil nicht binnen Sekunden die ganze Welt zu einer Krisensitzung berufen wird, Spezialeinsatzkräfte aus aller Herren Länder rekrutiert werden und ein Minutenprotokoll aller Abläufe über alle Medien der Welt verbreitet wird?

Da ist für die Menschheit kein Sack Reis umgefallen, sondern ein Reiskorn vom LKW geweht!

Interessante Sache. Jetzt braucht man seine Routen nur noch als Rundtour über die Gefahrenstellen planen und hat vermutlich eine perfekte Mopedtour!

Wenn da schon zu viele Zwischenziele drin sind, ist das mit ziemlicher Sicherheit eine aus irgendwelchen Importen aus irgendwelchem Kartenmaterial zusammengestückelte Route.

Die sicherste Variante ist es, die Route in BaseCamp einfach mit dem Routenwerkzeug nachzuklicken. Mit Start- und Ziel anfangen und dann mit der Gummibandfunktion die Route auf die gewünschte Strecke ziehen.

Hört sich erstmal kompliziert an, ist aber in der Summe meist die schnellste Variante. Die sicherste sowieso, weil die Route dann zu deinem Kartenmaterial passt.

Zitat von Wolfgang_26XX

Ich hatte mal Dateien gelöscht, ...

Ich hatte mal meinen Rechner ausgeschaltet. Rechner wieder eingeschaltet, fertig.:D

Ihr seid schon ganz schöne Experten, dass ihr per Ferndiagnose ohne irgendwas über den Schaden zu wissen, mal eben so entscheiden könnt, dass man eine beliebige, beschädigte Datenbank quasi per Knopfdruck wieder herstellen kann.

Das hast du falsch verstanden!
Nicht ablesen kann man das Navi ja nur bei Sonnenschein.

Damit man es auch bei Regen nicht ablesen kann, muss man es in einen Regenschutzbeutel packen!

Jetzt fehlt nur noch eine spezielle Lösung für bedeckten Himmel ohne Regen.

Das Autorouting über lange Strecken und mehrere Grenzen funktionierte bei Garmin noch nie richtig. In Verbindung mit Ausschlüssen kommt dann etwas heraus, was eher einer Zufallsroute entspricht.

Ich vermute, dass in MapSource und auch den Garmin-Navis nur eine relativ geringe Anzahl alternativer Streckenverläufe probiert werden, um mit geringen Rechnerressourcen auszukommen.

Daher hilft es auch, ein Zwischenziel ungefähr auf der Hälfte der direkten Verbindung zwischen Start und Ziel zu setzen. Damit verkürzt man die zu berechnenden Teilabschnitte und schränkt auch die Anzahl möglicher sinnvoller Alternativen ein.

Andere Fabrikate bekommen das ohne Hilfsmittel hin. Möglicherweise liegt das auch an der Anzahl verschiedener Straßenkategorien, Garmin verwendet da ziemlich viele.

Wie auch immer, Garmin-Navis sind nur in Verbindung mit MapSource und etwas eigener Planung gut. Will man das nicht, ist man mit anderen Navis besser bedient.

Nimm mal die Vermeidungen bis auf "unbefestigte Straße" raus. Dann werden es 450 km und Berechnungszeit um die 2s.

Zitat von Trebron

Warum die Abweichung und vor allem diese nicht gewollte Routenanzeige????

Vermutlich hast du die automatische Neuberechnung eingeschaltet. Wenn dann dieses merkwürdige Luftlinienrouting auftritt, fährst du nicht mehr auf der Route (der Luftlinie) und das Navi berechnet die Route neu.

Kann es sein, dass SendMap unter Windows 7 nicht richtig funktioniert?

Die Gerätekennung des Quest bekomme ich noch heruntergeladen, beim Versuch, Karten zu löschen oder neue aufs Gerät zu laden, hängt sich SendMap auf. Auch wenn es mit Administrator-Rechten ausgeführt wird.

Eigentlich kann man Wegpunkte nicht "falsch" setzen. Selbst wenn man einen Wegpunkt neben die Straße setzt, funktioniert das problemlos, wenn das Kartenmaterial, bzw. die Routingengine fehlerfrei ist.

Es nützt auch nichts, nach einer Tour zu wissen, dass man den einen oder anderen Wegpunkt bei der Routenplanung besser nicht verwendet hätte.

Mit der CityNavigator CN2009 funktioniert die Routenberechnung auch mit dem Wegpunkt L 106 einwandfrei. Das lässt darauf schließen, dass das verwendete Kartenmaterial fehlerhaft ist - und zwar an sehr vielen Stellen.

Zur Routenplanung allgemein:
Du hast relativ viele Wegpunkte in Ortschaften gesetzt. Wenn es nicht wirklich unbedingt genau durch diese Straße in der Ortschaft gehen soll, ist es geschickter, Wegpunkte außerhalb der Ortschaften auf die Straße zu setzen.

Statt Wegpunkten, die auch in der Wegpunktliste in MapSource auftauchen, ist es günstiger, Zwischenziele mit dem Pfeilwerkzeug zu setzen. Wenn du Start und Ziel der Route festgelegt hast, lässt sich eine Route relativ schnell mit dem Pfeilwerkzeug dahin verlegen, wo man langfahren möchte.

Ich versuche einigermaßen sparsam mit Zwischenzielen umzugehen. Für deine Route benötigt man ungefähr 20 Stück. Die Gefahr, dass man dann mal ein Zwischenziel etwas neben die Straße setzt, ist dann einfach geringer.



Zu dem Problem mit den Luftlinienabschnitten:
Ich bin mir nicht sicher, woran es liegt. Ich vermute, dass es die Kombination aus Kartenmaterial und Routingengine ist. In MapSource 6.16.3 tritt dieses Problem bei mir mit bestimmtem Kartenmaterial auf, das mit MapSource 6.13.7 fehlerfrei routet.

Das Zumo 220 eines Freundes zeigt dieses Verhalten jedenfalls auch häufig. Ich habe aber noch nicht herausgefunden, ob es an der Planung mit MapSource 6.16.3 liegt oder am Zumo. Ich schlage vor, mal eine Route ohne MapSource direkt im Zumo zu planen, um zu sehen, ob dieser Effekt da auch auftritt. In deiner Route ist z. B. bei Wegpunkt L106 ein unsinniges Routing zu sehen. Erstelle mal eine Route mit drei oder vier Wegpunkten, die in dem Bereich wie deine Route verläuft einmal mit MapSource und einmal direkt im Zumo, vielleicht lässt sich der Fehler eingrenzen.

Eine Parallelinstallation von MapSource 6.13.7 wäre auch noch ein Ansatz. Ich glaube aber mittlerweile, dass der Fehler eben die Kombination Zumo und Kartenmaterial ist. Ziemlich ärgerlich, weil es dann im Moment keine Abhilfe gibt und das Zumo definitiv zeitweise, bzw. in bestimmten Abschnitten nicht funktioniert.

Wir haben jedenfalls im direkten Vergleich zwischen einem Zumo 220 und einem Quest I feststellen können, dass das Quest bei Abbiegehinwiesen die Karte schneller aktualisiert und exakter die Position anzeigt und das Zumo praktisch bei jeder Route bisher zwischendurch irgendwelches wirres Luftlinienrouting produziert.

Den Fehler halte ich für so gravierend, dass man das Zumo 220 in diesem Zustand jedenfalls nicht empfehlen kann. Ich würde daher mal bei Garmin nachfragen, was sie zu dem Problem sagen.

An der Firmware liegt es vermutlich nicht, aber da alle anderen Versionen als die 4.1 mehr oder weniger fehlerhaft waren, ist ein Update schon mal ein sicherer erster Schritt.

Aus dem Satz "Was mich wundert ist, daß die Feindaten bei Erscheinen des Abbiegepfeils kurz sichtbar sind." werde ich nicht so recht schlau.

Heißt das, du hast die Kartendaten ohne Fehlermeldung auf das Quest übertragen bekommen? Dann hast du eventuell nicht alle für die Route benötigten Kacheln übertragen. Mach einen Test mit einer einzigen Kachel und einer Route, die nur auf dieser Kachel verläuft.

Wenn beim Übertragen der Daten keine Fehler kommen und die Kartendetailierung gering ist, kontrolliere im Quest unter "Karteneinstellungen", "Karte" ob dort bei "Detail" mindestens "normal" eingestellt ist.

Werden die Karten nicht ohne Fehlermeldung auf das Quest übertragen, ist eventuell die MapSource-Installation fehlerhaft. Eine Deinstallation von Karten und MapSource und am besten ein Löschen aller Schlüssel in der Registry die "Garmin" oder "MapSource" enthalten, ist manchmal die einzige Möglichkeit, eine vermurkste MapSource-Installation zu korrigieren.

Das Kartenmaterial heißt vollständig "City Navigator Europe 2009", ohne "NT".

Edit:
Unsere Posts haben sich vermutlich überschnitten. Als Ergänzung: Wenn du die MapSource.exe nicht herunterladen kannst, stimmt etwas mit deinem Windows nicht. Melde dich mal als Administrator an und versuche es noch mal.

Sehr gut, habe es berichtigt.

Streckensperrungen für Motorräder

Ok, habe es berichtigt. Die Sperre wegen Straßenbauarbeiten lasse ich raus, weil die vermutlich bald wieder aufgehoben wird.

Streckensperrungen für Motorräder

Da hast du dann versehentlich eine falsche Datei hochgeladen. In deiner angehängten Datei sind drei Streckenabschnitte enthalten, die ich nicht mehr als Streckensperrungen in meiner Datei habe. Das sind aber nicht die Strecken
63599 Biebergemünd
63639 Floersbachtal Mosborn

Die beiden letzgenannten habe ich noch als Streckensperrungen gelistet. Wenn die nicht mehr existieren, nehme ich sie natürlich raus.

Kannst du also bitte nochmal bestätigen, ob es sich um die Strecken in deiner Datei oder um
63599 Biebergemünd
63639 Floersbachtal Mosborn
handelt?