Neue Version MapTK

Lesen bildet: Doku Kapitel 1.2

Moin,

das Maß der Dinge ist für mich Garmin. Was der Online-Editor oder QLandkarte machen ist mir dagegen relativ egal. 'koizen' schreibt da was von einem 1. Byte 0x6e ( in Polygon ? ). Da ist Bit 6 gesetzt, was ich bisher in keiner Garmin TYP-Datei gesehen habe. Folglich werde ich es auch nicht setzen ( wobei es Garmin scheinbar nicht weiter auswertet, zumindest nicht in MapSource ). Die PRJ-Datei enthält keine Vorgaben wie eine Objektbeschreibung ( Quellcode ) in die Binärdatei umgesetzt wird. Das ist Sache des Compilers. Es gibt also keine Möglichkeit neue oder alte Formate zu steuern. Warum auch ? Je weinger Parameter, desto weniger Probleme beim Anwender und im Support.

Die unterschiedlichen Formate zur Bestimmung der 'Drawpriority' beziehen sich auf die PRJ-Datei - früher als eigene Tabelle wie bei cgpsmapper, heute zusammen direkt in der Beschreibung des Polygons. Das macht Kopieren und Vergleichen einfacher und das Programm für den grafischen Editor übersichtlicher. Die TYP-Datei ändert sich dadurch nicht.

Der Polygon-Typ 0x2d und andere sind zwar bei cgpsmapper und MapEdit nicht definiert, wurden aber in der Zeit vor den User-Typen ( 3-Byte-Typen ) gelegentlich in topografischen Karten benutzt. Eine TYP-Datei macht das möglich. QLandkarte kann des gern ignorieren, macht für mich aber wenig Sinn. Oder hat man den Sinn einer TYP-Datei nicht verstanden ? Solange Garmin das mitmacht werde ich nicht einmal eine Warnung anzeigen. Bedenklicher finde ich da schon die Sub-Typen >= 0x20 bei POIs, wie ich sie mehrfach in OSM basierten Karten gesehen habe.

An das Ende der TYP-Datei hängt MapTk seit einiger Zeit eine Signatur. Die Dient dazu festzustellen ob und mit welcher Version MapTk die Datei erzeugt hat. Das habe ich eingeführt nachdem man mir fehlerhafte Dateien vom Online-Editor unterschieben wollte. Wenn man hinter dem Ende der definierten TYP-Beschreibung weitermacht, Pech gehabt.

Zufällig habe ich etwas gefunden: Wenn in der Übersichtskarte für größere Orte im Bereich 1 bis 0x0b die Region und das Land definiert werden, kann man in MapSource nach diesen Orten mit dem Namen suchen. Das funktioniert ohne MDR- und MDX-Dateien ! Ist im Moment wohl nicht mehr so interessant, könnte aber für ältere Karten nützlich sein ( durch Austausch der Übersichtskarte ).

Noch eine Bemerkung zum Index: Die Definition von Ort, Region und Land sollte unbedingt einheitlich vorgenommen werden. Nur dann kann man vernünftig die Suche nach Ort, Region und Land eingrenzen. OSM-Karten sind eine Musterbeispiel wie man es nicht machen sollte. Das ist aber wohl prinzipbedingt ...

Schönen Tag noch
JürgenD

@extremcarver: Ich meine den Inhalt der OSM-Karten, nicht mkgmap. Auch wenn es eine Regel für die Einträge gibt darf doch jeder I... dagegen verstoßen. Dabei ist es völlig unwichtig was darin steht. Es muss nur für einen Kartensatz einheitlich sein. Das lässt sich per Programm auch nicht korrigieren. Geräte werden sich daran bestimmt nicht aufhängen, eher der Besitzer. Von der Verwendung von Sub-Typen > 0x1f kann ich nur dringend abraten. Der Compiler sollte das ablehnen. Die Bits 5 bis 7 werden an manchen Stellen anderweitig benutzt. Seit den User-Typen gibt es auch keinen Grund dafür, selbst wenn nachteilige Folgen nicht gleich zu beobachten sind. Auch hier gilt: Wenn keine Garmin-Karte Sub-Typen >= 0x20 benutzt, sollten man es ebenfalls lassen.

Wenn Stan mit seinem cgpsmapper die Lust verliert, kann ich ihn nicht sonderlich bedauern. In der freien Version jede Kachel mit einer deutlich sichtbaren Duftmarke zu versehen hat mich zu MapTk genötigt, der Preis der Pro-Versionen wohl zu mkgmap. Wenn er davon leben will, hat wohl sein Marketing nicht so recht funktioniert. Ein Compiler für die Kommandozeile passt nicht mehr in die Zeit. IDE ist angesagt. Das gilt auch für mkgmap. Dass wir alle hinter Garmin her dackeln, wird sich kaum umgehen lassen und sollte nicht zu Frust führen. Illegales MPC zu verwenden ist auch nicht die Lösung. Ich jedenfalls arbeite an MapTk zum Vergnügen, im Bewusstsein jederzeit einen Schlussstrich ziehen zu können.

kiozen: Das erste Byte der TYP-Datei ist das Längenbyte eines Subfile-Header. 'Normal' ist 0x5b. Was zusätzlich bei Längen von 0x6e und 0x9c in der Datei versteckt ist habe ich bisher nicht analysiert. Sobald die erweiterten Typen auftauchen muss mit einem 32-Bit-Feld die Reihenfolge definiert werden. Mir ist es dabei egal ob das wirklich nötig ist. MapTk benutzt immer das Bitfeld. Auch für die 'alten' Typen, da ist das Bitfeld 0x00000000 (andere Werte blenden das Polygon aus ). Daran scheint Garmin zu erkennen, dass es sich um den traditionellen Stil handelt. Eine Kennzeichnung im Kopf braucht es dazu nicht.

JürgenD

Hallo Oliver,
von Behinderung kann nicht die Rede sein. Ich will nur mit Garmin kompatible Karten erzeugen können. Andere 'Verbraucher' dieser Karten werde ich nicht berücksichtigen um die Kompatibilität mit Garmin-Produkten nicht zu gefährden. Ich implementiere auch nur was ich glaube verstanden zu haben. Das ist die Richtung.
Auf eine qualifizierte Frage werde ich immer eine qualifizierte Antwort geben - wenn ich denn eine habe. Konstantin ( MapEdit ) habe ich z.B. bei der Implementation der User-Typen unterstützt. Fragen, die geeignet sind z.B. den Kopierschutz zu umgehen werde ich ignorieren. Das gilt auch für das Geplapper von ein paar selbst ernannten Experten. Die Sourcen oder eine interne Doku werde ich sicher nicht veröffentlichen. Sie könnten zu illegalen Aktivitäten anleiten. Keine Lust auf Support und ellenlange Diskussionen ist ein weiterer Grund.

Zitat

Erweiterte Typen als Type|Subtype codiert kommen nicht vor.

Doch. Der Typ steht ganz normal in der Reihenfolge, der Subtyp ist im 32-Bit-Feld kodiert. Das ist z.B. einer der Gründe für die Begrenzung des Subtyps auf 0...0x1f.
Um die freien Karten mache ich mir keine Sorgen. Die Aufregung um einen neuen Kopierschutz kann ich nicht teilen. Schreibt doch ein Administrator des Garmin-Forums, dass Garmin freie Karten begrüßt https://forum.garmin.de/showthread.php?t=1209. Dass die interne Struktur der Dateien nicht publiziert wird oder MPC nicht an jeden gegeben wird, kann ich gut verstehen. Der unqualifizierte Umgang damit würde Garmin im Support auffressen. Was ich hier im Forum zu MapSource lese belegt das. Wenn jemand MapTk nicht mag oder nicht damit umgehen kann/will, soll er es einfach lassen. Diese Einstellung kann sich Garmin einfach nicht leisten, obwohl manchmal der Eindruck erweckt wird.

Schönen Tag noch
JürgenD

Die Adresseinträge haben eine Baumstruktur. An der Wurzel das Land ( Country ), Äste sind die Regionen ( z.b. Bundesland, Region ) und die Blätter sind die Orte ( Citiy ). Die Verweise gehen in der IMG-Datei per Index von City -> Region -> Country. Das kann man sehr gut bei MapEdit sehen. Bei OSM ist diese Kette meist nicht vollständig definiert. Dazu kommt, dass die Definitionen selten durchgängig sind. Mal ist Region ein Bundesland, mal eine Stadt ( City ist dann eine Vorort) u.s.w. Manchmal sind auch die Zuordnungen schlicht falsch. MapTk füllt jetzt die unterbrochene Kette mit Dummies auf.

In der IMG-Datei steht nichts falsches, es ist nur unvollständig.

Ich betrachte das als symptomatisch für offene Projekte bei denen jeder - egal ob qualifiziert oder nicht - alles eintragen darf. Für OSM gilt das vermehrt weil am Ende nicht einmal auf Plausibilität geprüft werden kann, wie es zumindest teilweise bei Software möglich ist.

Entschuldigung, es hat mit den Daten zu tun, nicht mit den Programmen die die IMG erzeugen. Im Gegensatz zu MapEdit war MapTk beim Decompilieren auf die Lücken in der Definition nicht vorbereitet. In der IMG-Datei kann nur drin sein was auch in der MP-Datei steht, es sollte aber auch nicht mehr sein.

Es hat nichts mit der Suche nach Adressen zu tun, nur mit der Anzeige und der Eingrenzung bei der Suche nach POIs und Orten.

Automatische Zuodnen von Orten zu Regionen und Ländern könnte schon funktionieren - wenn denn die entsprechenden Flächen von Gemeinden, Regionen und Ländern bekannt wären und der Compiler eine entsprechende Funktion hat. Wozu das, wenn man die Daten gleich richtig eingibt ?

Ich benutze mkgmap nicht, kenne deshalb auch die Funktion von 'location-autofill=2' und die vielen anderen Parameter nicht. Mir reicht MapTk ohne Parameter.

Seit April 2011 kann MapTk Karten für automatische die Routen-Berechnung erzeugen. Ich habe hier mal zusammengefasst was bis dahin ( Version 3.0 bis 3.1 ) neu ist oder geändert wurde:

Compiler

• Daten in IMG-Dateien für die Berechnung von Routen, einschließlich Abbiegebeschränkungen. Doku Kapitel 4.
• Die Verteilung der Objekte ( POI, Linien, Polygone ) auf die sogenannten Subdivisions bei ungewöhnlicher Karten ( kleine Insel im Meer, teilweise sehr hohe lokale Objektdichte ) wurde verbessert. Die kryptische Fehlermeldung wurde durch eine verständlichere ersetzt wenn sich solche Karten nicht kompilieren lassen.
• Warnung wenn für Autorouting das Hintergrundpolygon Type=0x4b fehlt. Ohne Hintergrundpolygon kein Routing !
• Zwei neue Funktionen helfen nicht verbundene, in der Nähe gelegene Straßen / Wege und nicht zusammengehörige externe Knotenpunkte zu finden. Doku Kapitel 4.3.
• Der Endlevel für das Hintergrundpolygon wird automatisch auf den höchsten Level der Karte gesetzt.
• 'Preview=Y' in Kopf einer MP-Datei kennzeichnet eine Übersichtskarte unabhängig vom Namen / ID.

Script

• Die neue Variable 'dirindicator' wird gesetzt bei Linien mit Richtung ( kleine Pfeile in MapEdit ). Im Script kann damit in den Restriktionen die Straße auf 'Einbahn' gesetzt werden.
• Menü 'IMG/MP → Reorganize': Teilt Linien und Polygone mit > 256 Punkte, beseitigt doppelte Datendefinitionen, entfernt Daten in EndLevel > 0 u.s.w. Das entspricht einem leeren Script, siehe Kapitel 3.1.
• Aus Koordinaten eines POI innerhalb definierbarer Flächen ( Ort, Gemeinde, Land ) kann z.B. der Name des Ortes auf einen POI übertragen werden. Stichwort: 'domain' und Beispiel Kapitel 8.8.

TYP-Datei

• Der Import von Pixelbildern für POIs im Editor für TYP-Dateien ist wieder möglich.
• 'TYP Analysis': Problem behoben wenn die Bilder für Tag und Nacht eine unterschiedliche Anzahl Farben haben. Nachtdesign wurde und wird jedoch nicht implementiert.

Nur Windows

• 'Tile cache' wird optional automatisch gelöscht für MapSource, BaseCamp und MapInstall. Händisch auch im Menü 'File → Clear cache'.
• Eine REG-Datei wird nicht geschrieben wenn der Name des Produktes im Header ( 'Product name' ) fehlt.
• Warnung wenn ein Family-ID-Konflikt beim Lesen der Registry bemerkt wird.

Allgemein

• Eine optionale LOG-Datei wird für ausgewählte Zeilen der Statusanzeige geschrieben.
• Allgemein verbesserte Fehler- und Warnmeldungen.
• Alle bekannten Fehler wurden repariert.
• Das Handbuch wurde überarbeitet.

Das Programm ist weiter kostenlos für Windows ( inkl. Windows 7 64-Bit ), Linux ( Test mit Ubuntu 9 ) und andere Systeme mit Python 2.5 ( mit Tkinter ) verfügbar.

Der Zusammenhang zwischen automatischer Routenberechnung ( PC, Geräte habe ich nicht geprüft ) und dem 0x4b-Polygon ist unklar. Hat die Karte nur einen Teil-Hintergrund kann auch nur über dem Hintergrund geroutet werden. Entweder habe ich ein Flag, das das Verhalten einstellt nicht gefunden oder Garmin braucht den Hintergrund wirklich. Bitte die Aussage, dass mkgmap wirklich keinen Hintergrund braucht, nachprüfen.

Die Unterschiede im Verhalten von BaseCamp und MapSource sind schon eigenartig. Grob gesagt wird bei BaseCamp alles mit 4 Rädern als Auto behandelt, Ambulanz und Fußgänger dürfen überall, Motorräder sind Autos oder Ambulanz. Fahrräder haben 4 Räder wenn das Häkchen bei 'Gemeinschaftspuren vermeiden' gesetzt ist, andernfalls ist alles erlaubt. Ich vermute noch weitere Absonderlichkeiten ähnlicher Art, wie z.B. bei kürzester Route die Abhängigkeit vom Schieber 'Kleinere Straßen - Autobahn'. Scheinbar gibt es mehrere kürzeste Routen. Das gilt für frisch mit MapTk erzeugte und möglicherweise auch für 'alte' Garmin-Karten ( Topo D 2010 macht sparsam Gebrauch von Restriktionen ). Etrex verhält sich möglicherweise wie BaseCamp, zumindest Oregon und älter passt zu MapSource. Sollte Etrex wie MapSource sein - Fehler in Bascamp ! Meine neueste Straßenkarte ist von 2008 ( ich nutze Garmin nicht mehr im Auto ). Wie verhält sich der aktuelle CN in BaseCamp und MapSource ?

Im Compiler lässt sich das sicher lösen. Es gibt im betreffenden Bereich noch ein paar nicht identifizierte Bits. Das Problem liegt für mich an ganz anderer Stelle:

• In einer MP-Datei lassen sich nur 8 Fahrzeugtypen definieren ( Syntax ). Motorrad ( ohne Auto ) kommt nicht vor. Eine Erweiterung / Umdefinition, zusammen mit einer neuen Steueranweisung 'alt' / 'neu' ist für meinen Compiler leicht möglich, führt aber zum Problem Nummer 2.
• MapTk setzt mit MapEdit bearbeitete MP-Dateien voraus. Eine Syntaxanpassung muss somit voll vom Editor unterstützt werden. Das Eingabefenster der Routing-Eigenschaften muss die Parameter anders setzen oder ganz neu gestaltet werden. Und das noch abhängig von alt / neu, was für alle Straßen / Wege gilt. Unter 'Extras' einzugebende Statements sind mir zu mühsam.
• Dazu noch ein weiteres Problem: Karten müssen nach diesem Kenntnisstand in zwei Varianten erzeugt werden. Wie handhabt Garmin das ?

Das Bild ist ausgesprochen diffus. Solange die Probleme 1 und 2 nicht befriedigend gelöst sind werde ich keine weitere Zeit spendieren das Chaos zu sortieren. MapTk zielt auf die Herstellung topografischer Karten. Für die meisten Handgeräte und topografische Karten ist die Bedeutung der Restriktionen sowieso relativ gering. Für den Autofahrer empfehle ich die originalen Karten von Garmin.

Übrigens: MapTk erzeugt kein intelligentes Autorouting - das machen bestenfalls Garmins PC-Programme und die GPS-Geräte mit jeder routingfähigen Karte.. Versuche die Verwendung freier Karten einzuschränken habe ich bei Garmin nicht beobachtet. Garmin-Forum: Garmin begrüßt freie Karten https://forum.garmin.de/showthread.php?t=1209. Garmin erweitert aber die Funktionalität und passt die Karten daran an. Glücklicherweise fressen die Geräte auch die alten Formate. Dass keine Spezifikationen des Kartendesign veröffentlicht werden ist für mich absolut verständlich. Damit ist Garmin den freien und kostenlosen Karten ein Stück voraus und kann verkaufen - besonders im Massensegment 'Straße'. Die freien Karten besetzen Nischen und werden verschwinden, sobald eine hochwertigere und vollständigere Karte zu vernünftigem Preis gekauft werden kann. OSM wird bestenfalls für 'Geiz ist geil' und Leute mit geringen Ansprüchen Bestand haben. Jeder der seine eigenen Karten baut sollte sich dessen bewusst sein.

Zwei kleine Korrekturen:

• 'IMG/MP': MP-Datei wird immer in des Verzeichnis der IMG-Datei geschrieben.
• 'New project file' : Anlegen eines neuen Projektes wurde repariert.