Abnormalitäten bei der Erstellung einer eigenen Garmin-Karte Teil 2

  • Nochwas: prinzipiell ist es richtig, den Fehler zu suchen. Falls Das aber nicht gelingt, könnte man auch drauf pfeiffen und einfach ein zusätzliches 0x28 an der Fläche plazieren, die noch weis ist. Wäre interessant zu testen,was da raus kommt. Die Methode mit überlappenden 0x28 nutzt die frei Canariaskarte. Die kann man nur durch die Draworder des Typfiles richtig darstellen, ohne Typfile wäre alles nur blau.


    Das ist aber eine interessante Idee. Nur wie stelst du dir das genau vor? Es gibt ja ein 0x28 Polygon in ganzer Fläche im .mp File.


    Ich teste deine Idee morgen am Vormittag.


    Peter

  • p.st : Schieb mir die MP-Dateien auf den Server (wird garantiert vertraulich behandelt, kann auch niemand vom Server laden). Ich mache dann ein funktionsfähiges Projekt daraus.
    .


    Ich möchte mich mal ganz herzlich für die angebotene Hilfe von JürgenD bedanken.


    Anmerken möchte ich aber auch noch, dass es mir nun doch noch gelungen ist ein fehlerfreies .img File zu erzeugen, es erfolgreich in MS einzubinden und auf GPS zu senden. Warum das dann plötzlich und eigentlich ganz unerwartet funktionierte kann ich nicht sagen. Ich werde aber weiter in diese Richtung nachforschen.


    Derzeit ist mir nur wichtig, dass die Karte für den bevorstehenden Urlaub einsatzfähig ist.


    Liebe Grüsse und auch Dank an alle die sich mit meinem Problem auseinandergesetzt haben


    Peter

  • Peter kennt die Ursache. Hab' ich ihm am Montag mitgeteilt. Damit alle was davon haben:


    Wenn die DrawOrder des Hintergrundes (0x4b) und die eines anderen Polygons (hier das Mittelmeer 0x28) die gleiche DrawOrder haben, kann es zu den beobachteten Problemen kommen. Dass der Zufall eine Rolle spielt, liegt vermutlich an der Methode der Darstellung: Die kleinste DrawOrder zuerst. Gibt es mehr als ein Polygon in einer Stufe, dann wie es gerade kommt - mit der Gefahr des Überschreibens. Die Reihenfolge in der IMG-Datei ist nicht bestimmt. Die IMG-Datei enthält auch keinerlei Info zur DrawOrder. Die steht nur in der TYP-Datei.


    JürgenD

  • Hallo Jürgen,

    vielen Dank für diese Info. Obwohl es eh naheliegend ist, wär ich nicht drauf gekommen. Hab da etwas zu kompliziert gedacht :).

    lg, Paul

  • Hallo nochmals,

    just FYI: Ich hab mein Typfile nochmals angesehen und ich hab für Background 0x4b gar keine DO eingetragen (genauso keine DO für 0x4a). ALLE anderen Polygone haben eine DO. Hab den File vor langem genau nach Vorgaben angelegt und noch nie Probleme mit der Darstellung gehabt.

    lg, Paul

  • Garmin muss die Polygone in einer Reihenfolge zeichnen, auch wenn in der TYP-Datei keine DrawOrder eingetragen ist. Möglicherweise beginnt Garmin mit 0x4b bei fehlender DrawOrder, so dass hier Probleme nicht vorkommen. Eine Probleme vermeidende Denkweise ist: Eine Stadt wird auf der grünen Wiese gebaut, darauf ein Parkplatz und darauf ein öffentliches WC. Bei in dieser Reihenfolge ansteigender DrawOrder ist die Karte wie erwartet (Stadt verdeckt Wiese, Parkplatz verdeckt, Haus verdeckt Parkplatz). Nur hat das mit den Mechanismen, die es zu berücksichtigen gilt, wenig zu tun. Es funktioniert meistens einfach nur. Überlappen sich Polygone nicht, ist die DrawOrder ohnehin egal. Wenn Hintergrund und Meer die selbe DrawOrder haben sind Probleme nicht ausgeschlossen.


    Ich setze die DrawOrder für alle Polygon ganz gezielt (MapTk erzwingt das, Vorgabe ist 0). Nicht nur um unbekannten Vorgaben von Garmin und Zufällen zu entgehen, sondern auch um mir ganz einfach eine Übersicht verschaffen zu können für den Fall von scheinbar seltsamen Abnormitäten. In der Karte von p.st waren Hintergrund und Meer mit DrawOrder=1 eingetragen. DrawOrder=0 für den Hintergrund hat die 'Abnormität' sofort beseitigt. In einer zweiten Version der MP-Datei (mit mehreren Änderungen) tritt die Abnormität scheinbar nicht mehr auf. Das stützt meine Vermutung, dass Garmin wohl nach der DrawOrder zeichnet, innerhalb einer Stufe aber unsortiert. Unsortiert weil kein plausibles Sortierkriterium bekannt ist, abgesehen von 0x4a und 0x4b. Der Typ der anderen Polygone schreibt keine Verwendung vor. Damit sind Polygone zunächst gleichberechtigt. Bei Linien ist das anders, z.B. die besonderen Linien für Routing. Es ist ratsam sich an die Beschreibung von z.B. GPSMapEdit zu halten. Für die Kreativität gibt die 3-Byte-Typen. Das erleichtert die Übernahme fremder TYP-Dateien, wenn sie nach vergleichbaren Regeln erstellt wurden.


    Meer ist eine dominierende Fläche. Ich möchte nicht wissen wie viele kleine, nicht so ins Auge fallende Flächen verschwinden, ohne dass es bemerkt wird. Die Regel 'alle Polygone zuordnen' ist sicher sinnvoll. Per Software auf die gleiche DrawOrder und gleichzeitiger Überlappung zu prüfen, um Warnungen zu generieren, ist natürlich möglich. Wenn ich mal viel Zeit habe ist das ein Kandidat für eine Erweiterung von MapTk. Bis dahin sollten wir wissen was wir tun.


    JürgenD