Beiträge von rowdy

Hallo gautschi,

auf der Nord-Süd-Route von Hamburg nach München muß man sich bereits bei Hannover entscheiden ob man weiter die A7 benutzen will oder über die A2, A14 und A9 fährt.
Wenn so eine Entscheidung durch eine Navigationssystem unterstützt oder getroffen werden soll, dann ist eine vergleichende Berechnung beider Strecken unter Einbeziehung aller bekannten Verkehrsstörungen notwendig.

Beim Routing wird die Strecke jedoch "Etappenweise" ermittelt, ist obige Route z. B. bis Würzburg ermittelt so wird nicht wegen einer TMC-Meldung erneut geprüft, ob es evtl. sinnvoller ist diese Störung ab Hannover zu umfahren, sondern es wird lediglich eine lokale Umleitung gesucht.

Während der Navigation reagiert die in MN|4 implementierte Lösung immer nur auf genau eine Störungsmeldung und das auch nur wenn diese Meldung das erste Mal empfangen wird. Deshalb können auch hier nur einzelne Verkehrsstörungen jeweils lokal umfahren werden. Daher ist es völliger Blödsinn, auf eingehende Verkehrstörungen sofort zu reagieren, auch wenn die Störung mehrere 100 km von der jeweiligen Position entfernt ist.

Die primitive Lösung für das Ereignis "Störung wird Empfangen"

liegt die Störung auf der Strecke?
- ja
- .. soll automatisch eine neue Route ermitteln werden?
- .... ja
- ...... "Ansage: Neue Route wird ermittelt"
- ...... "Route ermitteln"
- .... nein
- ...... "Störung anzeigen"
- ...... "Ansage: Bitte beachten Sie den Hinweis"
- ...... soll die Störung beachten werden?
- ........ ja
- .......... "Route ermitteln"
- ........ nein
- .......... "Störung unbeachtet lassen"

ist nun wirklich nicht besonders überzeugend.

Das System müßte jeweils im Hintergrund prüfen, ab wann eine andere Route sinnvoll ist und dann rechtzeitig darauf aufmerksam machen oder automatisch die neue Route errechnen.

Viele Grüße
Bernhard

Zitat

Original von gautschi

....

Das hat schon seine Richtigkeit, dass Störung, die mehrere hundert Kilometer vor der eigenen Position liegen, zu Neuberechnungen führen. Ich verweise da immer wieder gerne auf das "St. Gotthard- / San Berhardino-Problem", wo man sich tatsächlich _sehr_ früh für die eine oder andere Variante entscheiden MUSS *gg*.

...

Meint jedenfalls das gautschi

Alles anzeigen

Hallo gautschi,

und hier kommt ein extremes Gegenbeispiel.
Auf einer Fahrt von Cottbus nach Visselhövede, zeigt MN|4 noch vor dem Dreieck "Spreewald" an, das es am Walsroder Dreieck einen Stau gibt. Bis Hannover gibt es keine wirkliche Alternative zur A2.

Es ist ja nicht schlecht, wenn MN|4 schon mal im Hintergrund nach alternativen Routen sucht, aber eine neue Route wirklich ermitteln, oder die Störung anzeigen sollte das System erst, wenn es wirklich sinnvoll ist eine neue Route zu ermitteln. Beim "St. Gotthard- / San Berhardino-Problem" schon sehr frühzeitig, bei anderen Störungen aber erst später.

Das Alles wirkt (noch) nicht besonders durchdacht, sondern eher "wie mit der heißen Nadel gestrickt", da muß Navigon noch viel Nacharbeiten.

Viele Grüße
Bernhard

@waschtl,

poste doch mal die Routingpunkte.

Seit MN|4 gibts bei mir auch so eine Ecke.
Es ist aber kein Kartenfehler, da es von der geografischen Lage des Ziel abhängt, ob man nach links abbiegen soll doch erst nach rechts um dann einen Kreisverkehr vollständig zu umrunden.

Viele Grüße
Bernhard

Hallo zusammen,

die gesamte Verarbeitung der TMC Meldungen von MN|4 ist verbesserungsbedürftig.
Ich hatte zwar noch nie, das eine Störung die nicht auf der Strecke lag eine Neuberechnung verursachte, aber
- Störung die mehrere hundert Kilometer vor der eigenen Position liegen führen zu Neuberechnungen
- wird eine Störung aufgehoben die MN|4 nicht kennt, da das PGM als die Störung gesendet wurde, nicht aktiv war, führt das zu einer Neuberechnung.

Daher habe ich MN|4 so eingestellt, dass keine automatische Neuberechnung erfolgt, sondern die Störung zuerst angeziegt wird. Danach entscheide ich dann, ob die Route neuberechnet werden soll.

Wenn eine Störung ignoriert wurde, dann erfolgt keine neue Anzeige, auch wenn sich der Schweregrad der Störung ändert, daher ist ratsam die Route gelegentlich neu zu berechnen.

Insgesamt ist der Umgang mit den TMC-Meldungen nicht besonders sinnvoll.

Einen Straßenatlas besitze zwar noch, aber der liegt im Kofferraum und da soll er auch bleiben.
Dank der Profile von 944S2 sind die ermittelten Routen relativ gut.
Wenn man jede Route auf der Karte kontrollieren muß, dann braucht man ein anderes Navigationssystem.

Viele Grüße
Bernhard

Hallo,

der PocketLoox 410 wird gerade bei Saturn im Bundle mit
- MN|4
- 256 MB SD-Card
- Blauzahn-GPS-Empfänger

für 579 Euronen angeboten.

Wie bei Bundles üblich mal wieder Verkauf von Restbeständen.

Die 300 MHz-CPU ist wohl nicht leistungsfähig genug für MN|4. Bei meinem auf 530 MHz getaktetem e800 liegt die CPU-Auslastung fast nie unter 70% und in Städten bei mindestens 95 %.

Viele Grüße
Bernhard

Zitat

Original von DeJe

Zur Kartenanzeige kann man nur soviel sagen:
Es ist (gerade bei transparenten Anzeigen) deutlich zu sehen wie jedes einzelne Fenster/Anzeige aktualisiert wird. Das zeugt irgendwie nicht davon das hier mit Double-Buffering für die Anzeige gearbeitet wird und die Aktualisierung mehr oder weniger direkt im Videospeicher abläuft. Dieser ist aber für aufwendige Pixeloperationen bei vielen Geräten extrem langsam.
Ich habe jetzt alle Anzeigen "nicht transparent" und bilde mir ein das der Kartenaufbau und die Anzeige-Aktualisierung merkbar schneller geht, auch beim Menüaufbau.

zur CPU-Belastung hat DrDiste vor ein paar Tagen hier Stellung bezogen.

Zitat

Original von DrDiste
...
die Ursache Deines Problems liegt wahrscheinlich darin, dass auf einem Gerät mit 480x640 Pixeln eine Karte mit 4-facher Größe im Vergleich zum 1940 gezeichnet wird.
Da das Zeichnen der Karte (zumindest beim MN) sehr viel Rechenpower braucht, kann das der schnellere Prozessor nicht ausgleichen.
...

Viele Grüße
Bernhard

Zitat

Original von ebi_ham
...so interessant das Nachhinken ist:

die Frage der Abspeicherung der *.ini's im RAM sollte nicht untergehen.

Hat schon jemand Erfahrungen gemacht?

Hallo,

dazu muß Johannes (0815_Typ) Stellung beziehen, denn bis jetzt ist offen, ob mit dem PGM alle Dateien umgeleitet werden könne, oder nur die aus den Archiven.

Viele Grüße
Bernhard

Zitat

Original von 944S2

Sooo neu ist die Erkenntnis nicht.

Ich habe schon oft gesagt, dass Medion 3.1A mit gleicher Komprimierung nicht merklich hinkt - und dass es aus unbekannten Gründen den Prozessor weitaus weniger auslastet, was bisher die einzig plausible Erklärung für das Hinken in MN4.x ist.

Hallo 944S2,

ja stimmt, das hast Du schon oft schlüssig dargelegt aber jetzt ist aus der Annahme eine sichere Erkenntnis geworden.
Vielleicht ist es ja sinnvoll, das Thema noch einmal in einem neuen Thread zu diskutieren.

Viele Grüße
Bernhard

@DeJe,

jetzt haben wir jedenfalls eine neue Erkenntnis:

Das Nachhinken der Karte liegt nicht an der mit MN|4 eingeführten höheren Komprimierung.

Viele Grüße
Bernhard

Zitat

Original von Wolfgang
Und warum sagt dann der Support von Navigon ausdrücklich FAT16 Das widerspricht ja deinen Beobachtungen...

Hallo,
warum der Support von Navigon solche Aussagen macht weiß ich nicht, technisch begründet ist das jedenfalls nicht.
Die Aussage von Navigon hätte nur dann einen Sinn, wenn MN|4 am Betriebssystem vorbei direkt lesen und schreiben würde.

Viele Grüße
Bernhard

Hallo Erloeser,

meine 1-GB-Karte ist schon seit ewigen Zeiten mit FAT32 formatiert.
Abweichungen zwischen dem Richtungspfeil und den "Befehlen" von Tusnelda habe ich bisher nicht bemerkt, was ja nicht heißt, dass es sie nicht gegeben hat.
Routen gemerkt hat sich mein MN|4 leider auch noch nicht.

Wenn MN|4 auf Deinem PDA mit einer FAT32 formatierten Karte anders arbeitet als bei einer FAT16 formatierten, dann hat Dein Betriebssystem einen BUG, aber nur dann, wenn Du tatsächlich die selbe Karte benutzt hast.

Viele Grüße
Bernhard

Hallo Johannes,

[edit] B.K. [d]vielleicht hinkt die Karte dann ja nicht mehr so sehr nach.[/d] [/edit]

Habe jetzt einen ersten Test durchgeführt. Die Karte hinkt genausoweit nach.
Ich habe zwar keine Messungen, denke jedoch die gesamte Systembelastung zum Einlesen der entpackten Daten (3 mal soviel Daten) ist höher, als die gesamte Systembelastung zum Einlesen und Entpacken der gepackten Daten. Nur mit sehr schnellen Erweiterungskarten ist evtl. ein kleiner zeitlicher Vorteil zu erreichen. Der max. Datendurchsatz von 6,5 MB/sec meiner TOSHIBA CF XTRA GREEN ist dafür wohl nicht ausreichend.

Ich habe aber ein anderes Ziel.
Wenn das alles so funktioniert wie ich es verstanden habe, dann kann man mit Deinem PGM die Installation von MN|4 endlich trennen.
Software auf eine Erweiterungskarte, *.ini in den Speicher.
Dafür müßte Dein Programm aber alle Dateien umleiten können und nicht nur die aus den Archiven.

Viele Grüße
Bernhard

Hallo 0815_Typ,

angeregt durch Dein Posting habe ich mal von der 67 MB großen Karte "D-NORD" folgende *.SFS-Archive entpackt
D_NORD\kwa\kwa.SFS
D_NORD\maps\maps.SFS
D_NORD\tmc\tmc.SFS.

Dabei sind 33 Dateien mit insgesamt 189 MB entstanden:

Diese Dateien habe ich auf eine CF-Card in das Verzeichnis
\CF-Karte\Navigon\D_NORD\ENTP
kopiert.
Die Dateien kwa.SFS, maps.SFS und tmc.SFS habe ich umbenannt,
damit diese Dateien mit Sicherheit nicht benutzt werden können.

Die sfs_config.txt hat folgenden Inhalt.

Maps=Default
InitFailuresAreFatal=1

[Default]
*.dat=\CF-Karte\Navigon\D_NORD\ENTP
*.dcr=\CF-Karte\Navigon\D_NORD\ENTP
*.fsr=\CF-Karte\Navigon\D_NORD\ENTP
*.map=\CF-Karte\Navigon\D_NORD\ENTP
*.nam=\CF-Karte\Navigon\D_NORD\ENTP
*.rid=\CF-Karte\Navigon\D_NORD\ENTP

Das NM|4 läßt sich starten, die Karte wird aber nicht erkannt, sondern nach jedem Start kann ich nur die "Karte wählen", die Funktionen "Ein Ziel eingeben", "Mehrere Ziele eingeben" und "Karte anzeigen" sind nicht aktiv.

Wo liegt mein Fehler?

Viele Grüße
Bernhard

Zitat

Original von alx
Eine Idee für den Export wäre noch, die Detailtiefe bestimmen zu lassen, sowohl innerorts, als auch außerorts. So eine "oberflächliche" (mit 360MB) Karte von Europa wäre wirklich nicht schlecht, für den Fall, dass man nicht die Zeit für den Export hat.

ALexander

Hallo,

so etwas gibt es bei Digi-Map. Das führt im Zweifel zu
- erheblichen Umwegen
- fehlerhaften Ansagen für Kreisverkehre.

Außerdem ist dann ein dynamisches Routing nicht mehr möglich, weil dafür auch Straßen die nicht zu den "Hauptverkehrstrecken" gehören benötigt werden.
Ein Routing von "Tür zu Tür" ist dann nur mit kartenübergreifenden Routing möglich.

Lediglich der geringere Speicherbedarf spricht dafür, aber das ist bei den derzeitigen Preisen für Speicherkarten kein besonders durchschlagendes Argument.

Viele Grüße
Bernhard

Hallo zusammen,

ich halte einen neuen Map-Export für völlig überflüssig.

1.) Ich habe alle mir bekannten fehlerhaften Routen mit der alten vorexportierten Deutschlandkarte und einer neu exportierten Karte getestet.
Alle Routen waren völlig identisch.

2.) Die meisten der von Tower erwähnten "echten Routingfehler" ließen auch schon in der Version 4.01 durch andere Geschwindigkeitsprofile beheben oder umgehen. Das spricht sehr stark gegen Fehler im Map-Export.

3.) Geblieben ist die unnötige Runde um den Kreisverkehr auf der Strecke Visselhövede, Orchideenstraße - Bremen, Achterstraße. Dieser Fehler liegt auch mit dem neuen Map-Export vor.

4.) Viele der Ergebnisse sind nicht mit Kartenfehler sondern nur mit Programmfehlern zu erklären. z.B.
Visselhövede, Orchideenstraße (9.5723 / 52.9793)
nach Bremen, Achterstraße, Ecke Millstätter Straße (8.86075 / 53.09976) und zurück.

Hinweg: 60,71 km in 1 Stunde 41 Minuten.

Rückweg: 59,16 km in 53 Minuten.

Der Hinweg unterscheidet sich vom Rückweg nur durch den Umweg über den Kreisverkehr, sonst werden genau die gleichen Straßen benutzt.

Viele Grüße
Bernhard