Beiträge von JürgenD

Set heute gibt es 'maptk.dnsalias.com' nicht mehr ! Richtig ist jetzt maptk.de.

Aktuell ist MapTk Version 4.4.3 und Südtirol-Karte 4.60.

Für die Südtirol-Karte vermisse ich Änderungs- und Fehlermeldungen !

MapTk ist umgezogen: Von 'maptk.dnsalias.com' nach maptk.de. Die alte URL wird z.Zt. noch umgeleitet.

Aktuell ist MapTk Version 4.4.2 und Südtirol-Karte 4.60.

Gäste dürfen doch nicht schreiben ? Dann ist es genug die 'Offiziellen' zu kennzeichen. Der Rest bringt keinen Mehrwert. Also weg damit.

Einfach nur die Zahl der Beiträge zeigen, die mit der Qualifikation des Benutzers wenig zu tun hat.

Die Zahl der Beiträge ist bestenfalls ein Maß für die Kommunikationsfreude. Ein Benutzer mit 100 Beiträgen kann durchaus ein Erleuteter sein - und umgekehrt.

Zitat von GuSy

Das war sicherlich von Garmin nicht beabsichtigt, sondern ... Zufall.

Da bin ich nicht ganz sicher. Vor etwa 10 Jahren habe ich mal ein Zitat von Garmin gelesen: Wir begrüßen die freien Karten - unterstützen sie aber nicht. Garmin wird wegen der freien Karten schon den einen oder anderen Dollar über Verkauf von Hardware verdient haben, für die niemals eine Garmin-Karte verkauft worden wäre.

Die Aufzeichnung ist Schrott. An vielen Punkten springt die Zeit um ca. 7 Minuten zurück. Erstmal bei Punkt 18 -> 19. Dieser Rucksprung erfolgt alle 43 Punkte und wird offenbar als Betrag einfach aufaddiert.

Ich gratuliere zu Besitz einer Zeitmaschine.

BaseCamp 4.7.1 und das gleichzeitig installierte MapInstall 4.2.1 können wieder die über die Windows-Registry verwalteten Karten installieren.

Fehlerbehebung und Erweiterung in Version 3.4.2:

• IMGs ohne Routing werden wieder disassembliert (Meldung war: 'Error: local variable 'nod3' referenced before assignment').
• Es ist jetzt möglich leere IMG-Dateien zu erzeugen.
• Compiler: '~[0x1b]' kann Teil eines Label sein.
• Editor für Scripte: Mehr Worte für Syntax-Highlight.

[FONT=Arial, sans-serif][FONT=Arial, sans-serif]Problem behoben in '[/FONT]Find not connected near roads' (Meldung: 'Error: tuple indices must be integers, not str') [/FONT][FONT=Arial, sans-serif].
[/FONT]

Neue Version 3.4:

• Script: Warnmeldungen schreiben zusätzlich eine Markierung in die MP-Datei.

• Disassemblieren von Karten mit 6-Bit-Label korrigiert.

• Für die Markierung von nicht verbundenen Routenknoten werden Bookmarks in MapEdit verwendet.

• Python 2.7.6

• Diverse Optimierungen (Zeit & Speicher).

• Das Manual wurde aktualisiert.

Neue Version der Südtirol-Karte 3.50:

• Ab Version 3.50 werden die Höhenlinen aus dem Laserscan-Geländemodell der Povinz benutzt. Abstand 10 m ( sichtbar alle 20 m), Auflösung 22 Bit ( ~ 10 m).
• Ergänzungen und Korrektur aller bekannten Fehler.

JürgenD

Neue Version 3.3.7

• IMG: Höhenangaben in feet sind wieder möglich. Meldung war: 'UnboundLocalError: local variable 'unit' referenced before assignment'.

• Script: Freundliche Meldung 'out of memory' wenn die MP-Datei zu riesig wird.

Neue Version der Südtirol-Karte 3.40:

• Ergänzungen und Korrektur aller bekannten Fehler.
• Vereinheitlichung verschiedener Namen.

JürgenD

Neue Version 3.3.6:

• Fehlerbehebung bei ungültigem Label in 'reorganize' und 'script'. Meldung war 'Error: Key Error (Data,)' .

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

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

@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.

Eine ganz kurze Kurzanleitung:

• Alle MP-Dateien in einem Verzeichnis bereitstellen. Dazu gehört eine Übersichtskarte (kann mit MapTk aus den Kacheln erstellt werden) !
• Ein Projekt im Verzeichnis der MP-Dateien erstellen. Die Felder ausfüllen. Startpunkt im Manual Kapitel 5.1. Das ist beim ersten Mal etwas Mehrarbeit. Dafür reicht dann nach Änderungen an einer oder mehreren Kacheln 'Make' um alle abhängigen Dateien zu aktualisieren. Fummelei mit verschiedenen Tools gibt es nicht.
• 'Make'
• Es wird sicher Fehlermeldungen geben. Diese Probleme mit Hilfe des Manual beseitigen und weiter bei Punkt 3.
• Doppelklick auf *.reg zu Anmeldung bei BaseCamp und MapSource. Eine GMAP-Version kann man erstellen. Die wird aber erst in einer späteren Version von MapTk automatisch aktualisiert.

Man muss sich das schon mit einiger Mühe erarbeiten. Der Komfort der automatischen Aktualisierung entschädigt aber vielfach. Wichtig ist noch: Garmin nicht gegen den Strich bürsten, d.h. keine faulen Tricks. 'Sample,zip' auf dem Server zeigt alle Komponenten in einen Beispiel mit TYP-Datei, Index und Autorouting.

Dann werden da wohl noch andere Merkwürdigkeiten versteckt sein. Das Meer jedenfalls wird in Basecamp und MapSource wie erwartet dargestellt.

Das polygon hat viel zu viele Nodes. Bei 256 zu das Ende der Fahnenstange erreicht. Mit dem richtigen Tool wäre das nicht passiert.

JürgenD

Neue Version 3.3.3;

• Ungültige Höhenangaben und Angaben in Feet werden nicht mehr unterdrückt.
• Ungültige POI-Typen erzeugen anstelle einer Warnung jetzt einen Fehler.

JürgenD