@ Navigon: Neu exportierte Karten als Download zur Verfügung stellen

@HaPeWe

1. würde es mich schwer wundern, wenn irgendein Programm "zufälligen Speichermüll" erzeugt.

2. deutet für mich nichts darauf hin, dass irgendwo zulässige Höchstgeschwindigkeiten gespeichert wären.

möglich, dass die Ausgangssituation nicht klar definiert ist bzw. durch einen vorangegangen Export überschrieben wird.

Aber vergesst auch nicht, dass das Ergebnis gepackt wird. eine kleine Änderung am Anfang kann große Änderungen im weiteren Verlauf verursachen.

Aber das ist jetzt müßig den Navigon wird sich dazu nicht äußern. Da müsste man schon mäußchen bei Navigon oder compiler sein

...und dass der Map-Export besser sein könnte (vor allem schneller) ist denke ich mal unstrittig

nSonic

@terra_x

ich hatte ja bereits in meinem Text vermutet, dass es Leute geben wird, die nicht das Prinzip verstehen wollen, sondern lieber blöde Kommentare von sich geben möchten.

@944S2

> 1. würde es mich schwer wundern, wenn irgendein Programm "zufälligen Speichermüll" erzeugt.

Wenn du, egal in welcher Programmiersprache, einen Speicherbereich für Daten allozierst, dann befindet sich in diesem Speicherbereich "Datenmüll". Dies ist unabhängig davon, ob es dich wundert oder nicht.

> 2. deutet für mich nichts darauf hin, dass irgendwo zulässige Höchstgeschwindigkeiten gespeichert wären.

Ich ahnte es vorher - ich hätte besser ein themenfremdes Beispiel wählen sollen. Z.B. die Datenbank eines Schneiders, bei dem beim Geschlecht "männlich" das Datenfeld "Körbchengröße" nicht belegt würde - vermutlich hättest du dann aber klug festgestellt, das im MN4 keine Körbchengrößen gespeichert sind.

Gut, ich beginne langsam zu verstehen - es sind wohl nur Verschwörungstheorien gegen Navigon erwünscht - mögliche plausible Erklärungen kann man ruhig ins lächerliche ziehen. Ich sag ja nicht, dass mein Ansatz die Erklärung ist, aber es ist eine Erklärung, die man zumindest in Erwägung ziehen sollte, bevor man wieder mit Mistgabeln und Fackeln auf die Navigonburg zumaschiert.

Zitat

Gut, ich beginne langsam zu verstehen - es sind wohl nur Verschwörungstheorien gegen Navigon erwünscht - mögliche plausible Erklärungen kann man ruhig ins lächerliche ziehen. Ich sag ja nicht, dass mein Ansatz die Erklärung ist, aber es ist eine Erklärung, die man zumindest in Erwägung ziehen sollte, bevor man wieder mit Mistgabeln und Fackeln auf die Navigonburg zumaschiert.

Vielleicht gibt es ja eine plausible Erklärung, auf die wir jetzt nicht kommen und höchstens raten können. Ich persönlich finde es jedenfalls merkwürdig, wenn bei gleichen Ausgangsbedingungen solche unterschiedlichen Ergebnisse auftreten.

Ich spinne jetzt mal ein Beispiel. Ob dies wirklich so ist, kann ich natürlich auch nur raten.

In der Entwicklung von Navigon werden einmal Karten erzeugt, mit denen die Programmierer testen können. Da man bei Navigon auch weiß, wie lange ein Export einer großen Karte dauert, wird das sicher nicht jeder für sich selbst machen sondern die werden einmal auf den Server gelegt.
Also greifen bei der Programmierung alle auf die gleichen Karten zu und optimieren die Programmierung und das Routing damit. Vielleicht klappt es damit ja wirklich mehr oder weniger gut.

Jetzt kommen die User ins Spiel, die sich mangels neuer vorexportierter Karten, diese selbst erzeugen müssen.
Wenn sich durch Ungereimtheiten im Mapexport jetzt andere Karten ergeben, als die Grundlage bei der Entwicklung, kommen natürlich teilweise unsinnige Sachen raus, die vorher nicht bemerkt werden konnten.

Könnte ja durchaus auch so sein.

Das liegt zumindest für mich nahe, weil es hier im Forum ja öfters schon den Verdacht gab, daß auch unterschiedliche Karten die unterschiedlichen Routings bewirken können. Man war nur bisher davon ausgegangen, daß es evtl. an unterschiedlichen Kartenausschnitten liegen könnte. Ich hatte ja selbst schon bei drei verschiedenen neu erzeugten Karten unterschiedliche Routenvorschläge bekommen. Das hatte mich da schon stutzig gemacht. Da waren es allerdings nicht exakt gleiche Kartenausschnitte, sondern Deutschland mit verschiedenen angrenzenden Gebieten, die ich ab und zu befahre.

Wenn mir jemand plausibel erklärt, daß dieses Verhalten des Mapexport völlig in Ordnung ist, will ich es gerne glauben. Nur mich macht es stutzig, daß bei mir die zwei Luxemburgkarten unterschiedliche Größen hatten, bei jemand anderem zwar gleiche Größe, aber trotzdem interne Unterschiede. Das zeigt mir jedenfalls, daß dort irgendein Zufallsgenerator am Werk ist.

Jürgen

@HaPeWe

Ich bitte vielmals um Entschuldigung!
Hättest Du vorher gesagt, dass Du der Verkünder der Wahrheit bist, wäre ich natürlich niemals auf die Idee gekommen, eine abweichende Meinung zu haben, geschweige denn sie öffentlich zu äußern.

Nee, im Ernst. Ich bin ja auch an einer Erklärung der Merkwürdigkeiten im Mapexport interessiert und schließe nicht aus, dass an Deiner Theorie etwas dran ist. Wundern würde es mich trotzdem, und ich sehe auch den Beitrag von terra_x nicht als "blöden Kommentar" sondern als eine ebenso legitime Meinungsäußerung wie Deine und meine.

@HaPeWe

auf programmierer die so simple fehlerquellen an so zentraler stellen in die navigon-software einbauen, würde ich nicht nur als kunde sondern als chef mit "mistgabeln und fackeln" losgehen. spannend bleibt die frage schon, warum ein relativ kleiner kreis von nutzern auch beim mapexport schnell fehler lokalisieren kann, navigon aber nicht.

Manchmal ist es schon traurig, wie inflationär mit dem Wort Meinung umgegangen wird.

Zitat

Original von 944S2
Hättest Du vorher gesagt, dass Du der Verkünder der Wahrheit bist, wäre ich natürlich niemals auf die Idee gekommen, eine abweichende Meinung zu haben, geschweige denn sie öffentlich zu äußern.

Wenn ich erkläre, dass bei vielen Programmiersprachen beim Anfordern eines Speicherbereichs für Daten dieser mit "Speichermüll" gefüllt ist, du darauf antwortest, dies sei nicht so, dann stehen keine Meinungen - sondern eine richtige und eine falsche Aussage gegenüber.

Zitat

Original von 944S2
Nee, im Ernst. Ich bin ja auch an einer Erklärung der Merkwürdigkeiten im Mapexport interessiert und schließe nicht aus, dass an Deiner Theorie etwas dran ist. Wundern würde es mich trotzdem, und ich sehe auch den Beitrag von terra_x nicht als "blöden Kommentar" sondern als eine ebenso legitime Meinungsäußerung wie Deine und meine.

Wenn ich schreibe:
"Bitte jetzt keine Spitzfindigkeiten, wie: "In einer 30-Zone könnte doch Tempo 10 gelten" - es ging mir daraum an einem einfachen Beispiel ein Prinzip zu erläutern - ich hoffe es ist mir zumindest ein wenig gelungen."

und terra_x darauf nichts besseres zu schreiben weiß als:
"Das würde ja heißen das die Software bei den Geschwindigkeits- Profilen bei Tempo 30 mit einen zufals Generator arbeitet"

Dann mag dies für dich vielleicht eine legitime Meinungsäußerung darstellen, eine Meinung, geschweige denn eine "legitime" kann ich in diesem Satz von terra_x nicht erkennen. Für mich bleibt es ein blöder Spruch.

Nun, ich versuche mal Meinungen abzuleiten:

Meine Meinung wäre dann:
Mein Beispiel ist ein denkbarer Lösungsansatz.

Eine gegenläufige Meinung wäre:
Mein Beispiel ist auf gar keinen Fall ein Lösungsansatz.

Wenn du oder terra_x letztere Meinung vertreten, dann erwarte ich zumindest eine gleichwertig qualifizierte Begründung. Wird diese nicht gegeben, dann ist eure Meinung für micht halt nur "blödes Gerede".

Nun werd mal nicht beleidiget !!!!

Wir wollen in Sachen der Programmierung doch mal eines Klar stellen.

jeder Programmierer der meint einer zu sein wird verwendeten Speicher vorher definieren sprich mit nach vollziehbaren Daten voll schreiben, sonst kann er nämlich keine Ergebnisse Ãberprüfen (Kann ja letztlich selber ein klein wenig Programmieren)

AuÃerdem, selbst wenn ich als Programmierer mir diese mühe NICHT mache und es der Programier Sprache Ãberlasse so ist der bereich späestens nach durchlaufen meiner Routinen mit meinen Daten beschrieben.

Es ergibt keinen sin was du schreibst, die end Daten (Sprich fertige karte) sollte IMMER gleich sein. Zumindest wenn die Grund Bedingungen gleich sind.

Also wen ich ein Programm Programmiere das aus einer Datenbank (Nichts anderes ist die Europa karte) einen teil heraus schneidet und komprimiert, so sollte das Ergebnis wenn ich die gleiche stelle aus schneide immer gleich sein.....

Wer hier blödsin schreibt bleibt also mal dahin gestellt.

@HaPeWe Du musst nicht meinen das du die GroÃe kenne hast und alle anderen wie ich auch mit ihren Ãberlegungen nur falsch liegen und blöd sind.....

Auf jeden fall konntest du mich nicht Ãberzeugen, den dafür habe ich leider zu viel Verständnis fürs programmieren.

Ich kann die Unterschiedlichen GröÃen und Inhalte der karten bei gleicher ausgangs Position nicht vernünftig erklären. Weil ich so was so nie programmieren würde. Logisch währe wenn der Inhalt und GröÃe immer gleich ist.

Das ganze ist sicher ein BUG und dürfte nicht sein....

ABER es muss nicht unbedingt Auswirkungen auf die fertige karte haben, es kann wirklich sein das es ein Start Bug ist, heist beim berechnen der karte wird aus unerklärlichen gründen nicht immer die selbe stelle angesprungen.....

Aber eines ist doch auch seltsam die ersten 180 Byte stimmen bis auf 2 byte überein......

@HaPeWe wenn du also so ein super Profi bist erklär mir das mal ?????

Ich f�nde es eben klasse wen Navigon hier mal Stellung nehmen würde und eine logische Erklärung für dieses seltsame verhalten nennt.

Aber wie sagt man so schön "KEINE ANTWORT IST AUCH EINE ANTWORT"

Vielleicht macht es Sinn, wenn Ihr beide erst einmal kurz im "Blauen Bock" gemeinsam einen trinken geht und danach dann gelassen in der Sache weiterdiskutiert. Prost !

Hi

wie man sieht, scheint es wohl unterschiede in den Kartendaten zu geben.

Allein dies sollte schon reichen, um ein Download der Kartendaten zu rechtfertigen.

Da es bei Navigon ja keine Fehler gibt, sollten diese Karten dann wohl optimal sein.

@terra_x

Ich bin von deinem Schreibstil und deinen unqualifizierten Äußerungen und Angriffen ziemlich angenervt und ziehe mich mit dieser abschließenden Erlärung aus dem Thema zurück.

> jeder Programmierer der meint einer zu sein wird verwendeten Speicher vorher definieren sprich mit nach vollziehbaren Daten voll schreiben

Hättest du geschrieben: Es ist ein besserer Programmierstiel, Datenbereiche zuvor mit definierten Daten zu füllen, dann würde ich dir zustimmen. Bei der Aussage: "Jeder Programmierer ... wird verwendeten Speicher vorher definieren" widerspreche ich. Die damals als Slag-Aera benannten (nicht gefüllten) Datenbereiche gab es sowohl im FAT-Dateisystem unter DOS (was genau genommen auch eine Art Datenbank ist) als auch in dBase-Datenbanken - beides, sowohl DOS als auch dBase wurde durchaus von Programmierern entwickelt.

> selbst wenn ich als Programmierer mir diese mühe NICHT mache und es der Programier Sprache Ãberlasse so ist der bereich späestens nach durchlaufen meiner Routinen mit meinen Daten beschrieben.

Einen Gegenbeweis kann ich liefern - deine Aussage könnte ich nicht beweisen. Wenn ich z.B in der Programmiersprache C++ einen Datenbereich von 512 Byte anfordere und in einer Schleife in jedem Schleifendurchlauf die ersten 100 Byte fülle, dann sind selbst nach unendlichen Durchläufen die hinteren 412 Byte nicht mit meinen Daten belegt.

> die end Daten (Sprich fertige karte) sollte IMMER gleich sein. Zumindest wenn die Grund Bedingungen gleich sind.

Ja, du magst Recht haben, die Enddaten "sollten" immer gleich sein. Hier im Forum haben jedoch Leute festgestellt das dies bei Kartenexporten vom MN4 nicht so ist und ich habe versucht zu erläutern, wie so was passieren kann.

> Wer hier blödsin schreibt bleibt also mal dahin gestellt.

:-)))

> @HaPeWe Du musst nicht meinen das du die GroÃe kenne hast und alle anderen wie ich auch mit ihren Ãberlegungen nur falsch liegen und blöd sind.....

Nur mal eine Frage: Welche Überlegung anderer habe ich als falsch hingestellt?

> Das ganze ist sicher ein BUG und dürfte nicht sein....

Es mag ein Bug sein - es kann aber auch belanglos sein. Wer von uns beiden akzeptiert hier keine anderen Meinungen?

> Aber eines ist doch auch seltsam die ersten 180 Byte stimmen bis auf 2 byte überein......
> @HaPeWe wenn du also so ein super Profi bist erklär mir das mal ?????

Warum sollte ich versuchen, dir das zu Erklären. Ein sachlicher Ansatz basiert auf meiner vorangegangenen Erklärung und die willst du ja nicht als denkbar akzeptieren.

Jetzt lass uns dies aber nicht unendlich in die Länge ziehen. Ich könnte mich ja bemühen, hier keine Erklärungen mehr zu liefern und stattdessen auch destruktiv mitzuwirken.

> Ich f�nde es eben klasse wen Navigon hier mal Stellung nehmen würde und eine logische Erklärung für dieses seltsame verhalten nennt.

Ich fände es auch Klasse, von Navigon die Erklärung dafür zu hören - ob sie jedoch eine hier schreiben bleibt wohl allein in Navigons Hand.

also ich werde mich auch aus dem Thread zurückziehen, denn wie ich schon schrieb: Navigon wird sich dazu ganz sicher nicht äußern.

Und: es kann in der Tat völlig belanglos sein.

Möchtet Ihr evtl. doch noch ein weitere Beispielt was für einen Unterschied sorgen kann?

OK:
- nehmen wir mal an, die Straßenkarte (Europa) ist eine Art Datenbank
- Jetzt werden bestimmte Abschnitte daraus gelesen damit man diese exportieren kann

Fakt 1: Ohne vorgegebene Sortierung kann es, abhängig von der Leseroutine, dem "Zufall" überlassen sein, welcher Abschnitt zuerst ans Programm zurückgesendet wird.

Klingt weit hergeholt? OK, weiter gehts:

- Jetzt sollen die Daten vielleicht in Reihenfolge gebracht werden (z.B. nach Vektoren sortiert, oder die Abschnitte nach Straßennamen oder was weiß denn ich - sortieren eben)

Fakt 2: Nun schreibt mal bitte einen Sortieralgorithmus der einfach nur mal "Zahlen" sortieren kann. Ich gebe mal vor:
(um Dupletten zu unterscheiden hänge ich mal einen eindeutigen Zähler voran, der für die Sortierung aber nicht relevant ist)
1.) 005
2.) 003
3.) 010
4.) 154
5.) 003
6.) 007
7.) 154

So, und jetzt lasst das mal sortieren und sagt mir (mit dem eindeutigen Zähler) wie die Reihenfolge aussieht und welche "richtig" ist

EINE Variante wäre
2.) 003
5.) 003
1.) 005
6.) 007
3.) 010
4.) 154
7.) 154

eine Andere:
5.) 003
2.) 003
1.) 005
6.) 007
3.) 010
7.) 154
4.) 154

Für das Ergebnis völlig unwichtig - Wenn aber an diesen Zahlen weitere Informationen verknüpft sind (und bei sowas komplexen wie einer Straßenkarte gehe ich davon aus), dann könnte das Ergebnis vor und vor allem auch nach dem Komprimieren deutlich anders aussehen - ohne wirklich eine spürbare Auswirkung haben zu müssen

nSonic