Hallo,
vor einiger Zeit habe ich MN5 auf MN6 upgedatet. Dabei musste ich leider feststellen, dass wesentliche Kritikpunkte von MN5 immer noch unverändert fortbestehen. Habt ihr ähnliche Erfahrungen gemacht und meint ihr, Navigon wird die geschilderten Probleme irgend wann endlich mal abstellen?
Routenberechnung:
Ich fahre einen Daihatsu Cuore, das Profil habe ich auf "Pkw langsam" eingestellt. Festzuhalten ist, dass es bei MN6 wie auch schon bei MN5 vollkommen unmöglich ist, auf Bundesstraßen die angegebenen Zeiten bis zum Ziel zu halten. Ich bin heute sonntags morgens (!) ohne Autobahn von Dortmund nach Kassel gefahren. Es war kein einziger Lkw unterwegs, trotzdem brauchte ich 8 Minuten länger als angegeben. Dabei bin ich wo möglich immer die angegebenen Höchstgeschwindigkeiten auch gefahren. Jede Ortsdurchfahrt, auf der mal einige Kilometer 30 km/h ist, führt zur Verzögerung um eine Minute, jede Ampel, die etwas dauert, verzögert um eine Minute. Werktags, wenn Lkws unterwegs sind, kann man die Berechung völlig in die Tonne hauen. 100 km/h fahren ist dann auf vielen Bundesstraßen kaum mal wann möglich, die Realität ist das Fahren mit ca. 70 km/h auf weiten Abschnitten. Kurven und reger Gegenverkehr lassen schnelles Überholen in der Regel nicht zu. Bei einer langen Fahrt über Bundesstraßen (zB von Würzburg bis Augsburg ohne Autobahn) kann man hier locker 50 Minuten gegenüber der Berechnung drauf schlagen.
Demgegenüber ist die Fahrzeitenberechnung auf Landesstraßen großzügiger und auf Kreisstraßen viel zu großzügig. Fährt man etwa von Obernburg nach Lohr am Main über Eschau und Mespelbrunn auf Kreisstraßen durch den Spessart, so gewinnt man gegenüber der Rotenberechnung 15 Minuten. Auf Grund der Falscheinschätzung der Fahrzeit wird auch fälschlich vorgeschlagen, erst nach Aschaffenburg zu fahren und dann über die B26 nach Lohr. Fährt man so, braucht man 10 Minuten länger als von MN6 errechnet.
Welcher Teufel reitet Navigon eigentlich wenn die davon ausgehen, dass auf Bundesstraßen der Verkehr deutlich schneller läuft als auf Landes- oder Kreisstraßen? Diese sind zwar häufig schmaler, dafür aber weniger befahren. Die Progammierer von Navigon sollen sich doch einmal ins Auto setzen und mal sehen, wie häufig man auf der Bundesstraße einen Lkw hat!
Unbrauchbar sind auch die Berechnungen der Ankunftszeit auf Autobahnen: Heute bin ich vom Gambacher Kreuz bis zum Seligenstädter Dreieck auf der A66 gefahren, die Autobahn war leer, Geschwindigkeit von mit laut GPS ca. 125 km/h. Gewonnen habe ich gegenüber der Berechnung gerade mal eine Minute. Dabei steht das Routenprofil auf "Pkw langsam". Wer 125 km/h fährt, fährt 5 km/h unter der Richtgeschwindigkeit und damit mehr oder minder "normal". Ein langsames Auto fährt für mich 100 km/h auf der Autobahn. Tut man das, kann man die Berechnung in die Tonne werfen. Oft genug muss man es, weil die Autbahn regelmäßig voll ist, kann man die Berechnung in die Tonne werfen. Dass auf Autobahnen regelmäßig Baustellen sind, scheint den Programmieren auch nicht in den Sinn gekommen zu sein. Nach dem Hattenbacher Dreieck Richtung Kassel befindet sich zwei längere Baustellen hintereinander mit 60 km/h-Beschränkung. Nachdem man da durchgefahren ist, hat man 4 Minuten verloren. Bis zum Ende des nordhessischen Berglands bei Göttingen kann man von einem Verlust von knapp 10 Minuten gegenüber der Berechnung ausgehen. Den Programmieren scheint also auch nicht in den Sinn gekommen zu sein, dass mit einem langsamen Pkw auf einer Gebirgsautobahn bergauf regelmäßig mit 80-90 km/h unterwegs ist.
Vierstreifige stark belastete Autobahnen zeichnen sich dadurch aus, dass man häufig auch links nicht schneller als mit 90-100 km/h voran kommt, weil Lkws oder Fahrzeuge mit Anhänger überholen. Schnell stockt es hier - regelmäßig. Tut es das, verliert man innerhalb kürzester Zeit wieder Minuten. Kleiner Tipp für die Programmierer: Auf www.autobahnatlas.de gibt's Karten über den Ausbauzustand und die Verkehrsbelastung auf Autobahnabschnitten. Schaut man sich das mal an, wird etwa völlig klar, dass etwa auf der A3 im Raum Würzburg mit längeren Abschnitten, in denen man nicht über 90 km/h hinaus kommt (auch mit einem schnellen Auto), mit hoher Wahrscheinlichkeit zu rechnen ist. Ist das so, darf das Auftreten einer solchen Verkehrssituation aber eben nicht dazu führen, dass man Minuten verliert.
Baustellen mit Anbau von mehr Fahrspuren dauern mehrere Jahre und sind dauerhaft vorhanden. Die dadurch entstehenden Behinderungen könnten in der Karte berücksichtigt werden. Im Übrigen müssten bei der Durchschnittsgeschwindigkeit Behinderungen durch kürzere Baustellen und Verkehrsstockungen auf der Autobahn viel mehr berücksichtigt werden. Ebenso kann man drum wetten, dass bei einer längeren Fahrt auf der Bundesstraße mit gewisser Wahrscheinlichkeit eine Baustelle mit Ampel und einstreifiger Verkehrsführung kommt; kommt sie tatsächlich, verliert man in der Regel gleich 5 Minuten!
Warum ist es so schwer, vernünftige Durchschnittsgeschwindigkeiten für Bundesstraßen und Autobahnen anzunehmen und dann zu brauchbaren Kalkulationen zu kommen? Wenn man sich dauernd bei der Fahrt auf der Flucht fühlt, weil man mal wieder die Zeitberechnung in die Tonne hauen kann, macht das keinen Spaß. ![]()
TMC-Funktionen:
Die Verarbeitung derTMC-Funktionen weist bei MN5 und MN6 gravierende Mängel auf. Autobahnsperrungen werden fehlinterpretiert als Engstelle. Dementsprechend reagierte MN6 weder angemessen auf eine Sperrung der A3 im Kölner Ring vor einigen Monaten als auch an diesem Samstag auf eine Sperrung der A7 zwischen dem Dreieck Drammetal und Göttingen Süd. Für MN6 ist das ganze nur eine Engstelle mit reduzierter Anzahl an Fahrspuren. Das ganze passiert bei Autobahnsperrungen immer!
Die errechneten Stauumfahrungen sind im Übrigen häufig unsinnig. Ich habe einmal freitags nachmittags einen Wutanfall bekommen, als ich wegen einem Stau auf dem Kölner Ring von der Navi allen Ernstes durch die Kölner Innenstadt (Zoobrücke) geleitet wurde. Staus dort sind zwar nicht gemeldet, aber selbstverständlich jede Menge vorhanden! Und das Fahren ist da viel unbequemer als auf einem verstauten Kölner Ring. Weitere Glanzleistungen war eine Stauumfahrung auf der A3 im Raum Nürnberg durch Nutzung des Frankenschnellwegs mit entsprechendem Stau an dessen Ende sowie eine Umfahrung eines Staus auf der A9/99 ab Holledau durch Befahren der Ortsdurchfahrt Landshut der B11. Die b11 verläuft teilweise direkt neben der verstauten Autobahn. Auf die Idee da längs zu fahren, sind natürlich noch mehr bekommen mit der Folge, dass da weniger ging als auf der Autobahn und das ganze eine furchtbare Quälerei war - viel mehr, als wenn ich auf der Bahn geblieben wäre.
Können Programmierer von Navisystemen nicht so weit denken, dass Ortsdurchfahrten von Großstädten und zur Autobahn parallel verlaufende Bundesstraßen für Stauumfahrungen in aller Regel völlig ungeeignet sind? Eine kleinräumige Stauumfahrung macht in der Regel gar keinen Sinn, hier sollte vorgeschlagen werden, auf der Autobahn zu bleiben. Könnte man das problemlos umfahren, wäre ja gar kein Stau da. Sinn macht eine Stauumfahrung nur, wenn diese frühzeitig und möglichst großräumig erfolgt; beispielsweise bei einem Stau auf der A5 im Raum Vogelsberg über A7 bis Fulda und dann A66/B40 oder von Frankfurt kommend bei einem Stau am Kölner Ring mit Fahrtziel Region Neuss Ableitung auf die A61 und westliche Umfahrung des Kölner Rings bereits im Raum Koblenz. Aber genau das leistet das System nicht.
Ich frage mich, ob Navigon bei MN7 mal endlich aufwacht und diese Mängel behebt. Insbesondere hätte ich eben gern eine verlässliche Routenberechnung, bei der man auch mal etwas vorausschauend fahren kann, ohne schon dafür Minuten draufgehauen zu kriegen. Wenn ich etwa auf der leeren Bundesstraße, niemand hinter mir, bei Herannahen eines Ortseingangsschildes frühzeitig vom Gas gehe und in den 3. Gang runter, um möglichst ohne zu bremsen auf 50 km/h zu kommen, kann ich mir sicher sein, dass ich beim zweiten Mal schon eine Minute drauf kriege. Fahren Navigon-Programmierer mit 100 km/h auf die Ortseingänge zu und hauen dann voll auf die Bremse? ![]()
Gruß,
Tino255