Ich verfolge dieses Thema nun schon eine ganze Weile, weil es mich als Motorradfahrer und experimentiertfreudigen GPSer, als Software-Entwickler und auch als Hobby-Elektroniker sehr interessiert.
Zunächst eine Frage: ich habe seit kurzem ein 278, FW 2.70. Entspricht das der ehemals "besseren" FW 3.irgendwas des 276, oder der neueren 276-Version?
Aber nun zur Sache:
Leider habe ich kein Vergleichsmöglichkeit vorher/nacher. Fest steht, dass "kürzere Strecke" meiner Meinung nach zu "kürzeren Strecken" führen müsste, tut es aber nicht (immer). Bislang nutze ich diese Einstellung z.B. bei Microsoft Autoroute, weil m.E. dabei a Priori die schöneren Motorradstrecken zu erwarten sind. Nicht immer zwar, aber im statistischen Mittel doch eher als bei anderer Einstellung.
Nun macht Autoroute das leidlich gut, aber eben nicht der 278.
Wenn man aber einmal kurz über die Unterschiede eines mobilen GPS und eines PC nachdenkt, kommt man der Problematik vielleicht näher. Das Stichwort heisst schlicht "Ressourcen".
Während ein PC zuweilen mehrere GB Speicher sein eigen nennen kann, und jenseits des Memorys zusätzlich über eine Swapdatei mit ggf. nochmals mehreren GB verfügt, ist so ein Handheld mit seinen Resourcen vergleichweise ein Winzling.
Wer sich mit Programmierung befasst, und sich vielleicht sogar schon mal mit dem Dijkstra-Algorithmus auseinandergesetzt hat, der wird schnell sehen, dass Stack und Heap bei so einem Rechnerchen sehr begrenzt sind, und man mit seiner Rechnerei schnell gegen die Wand läuft, wenn man keine Gegenmassnahmen ergreift.
Für die Nichtprogrammierer: ein Stack ist eine Art "Trackbackspeicher" für Programme, sie merken sich darin, woher sie gekommen sind, und wohin sie nach der Arbeit wieder zurückkehren müssen. Auf dem Heap merkt sich das Programm Werte, die es zur Brechnung braucht (natürlich vereinfacht dargestellt).
Beide (Stack und Heap) residieren im Speicher. Der aber ist bei Handhelds viel begrenzter als bei PC.
Ist der Speicher erschöpft, fährt ein Programm knallhart gegen die Wand, wenn es das nicht beachtet. Bei einem "Embedded Device", nichts anderes ist ein GPS, hiesse das "Totalabsturz". Und wenn sowas bei einem GPS ein paar Mal passiert, dann ist as am Markt schlicht tot.
Was also tun? Die oberste Prämisse eines Herstellers ist immer: "don't scare the Customer", bloss den Kunden nicht erschrecken. Also: wasserdichte Software schreiben.
Man könnte ja sowas machen:
Systemmeldung: "bitte setzen Sie Zwischenpunkte, damit die möglichen Berechnungsknoten reduziert werden, und wir Ihrem Wunsche gemäss Autobahnen vermeiden können!"
Oder: "Die Berechnung ist unter Berücksichtigung Ihrer Vorgaben nicht durchführbar, weil das Gerät, dass Sie in der Hand haben, nur über 1048576 Bytes Hauptspeicher verfügt".
Was würde denn da passieren?
Leute wie ich würden sich freuen, endlich mal ein bischen Einblick in die Interna, und korrekt wäre so ein Programm-Verhalten aus Sicht eines Softwareingenieurs auch noch.
Aber durchschnittliche Kunden? Die würden das Ding zurückschicken "balla balla, die bei Garmin, oder was?"
Was also tun?
Ganz einfach: man verfolgt eine Strategie, die sowohl den Restriktionen der verwendeten Hardware Rechnung trägt, als auch den Kunden nicht erschreckt, und obendrein möglichst korrekte Ergebnisse liefert. In der Praxis bedeutet das: Kurze Strecken werden so geplant, wie vom Kunden eingestellt. Aber was mache ich bei langen Strecken?
Mir ist aufgefallen, dass der 278 längere Strecken (z.B. Darmstadt - Trento / kürzeste Strecke) anfangs ziemlich zügig rechnet, dann aber (in diesem Beispiel) bei etwa 80% plötzlich stehen bleibt, irgendwas herumrödelt, um dann genauso zügig weiter zu rechnen. Meine Vermutung: Das ist der Punkt, an dem die Ressourcen knapp werden. Die errechneten Knoten werden wieder abgeräumt, und intern auf Notprogramm geschaltet: weniger Abbiegungen verwenden. Dann geht das Ganze mit einer anderen Strategie von vorne los.
Und die berücksichtigt eben nicht mehr zu 100% das gewünschte Profil.
Was man da tun kann? Mehr Ressourcen zur Verfügung stellen, d.h: mehr Speicher. DAS ist die einzige Lösung, da beisst die Maus keinen Faden ab.
Und deshalb könnt Ihr an Euren Geräten einstellen was ihr wollt: es wird Euch nichts nützen. Die Ressourcen sind abgezählt, und damit basta.
Es mag sein, dass der Umgang mit eben diesen in einer früheren FW besser war. Aber dafür waren andere Dinge, von denen wir vielleicht nichts wissen, eben magerer, z.B. die Kartendarstellung.
Das ist das Ergebnis meiner Überlegungen, und deshalb ist es zwar interessant, hier zu sehen, wie sich verschiedene Einstellungen auswirken. Aber am grundsätzlichen Problem kann man nichts ändern.
......
