Beiträge von JürgenD

Konversion MP <--> GPX in MapTk: Aufbereiten von Tracks und POIs sowie zusammenführen von Linien und POIs aus MP-Datei. Ziel: Daten zum Erstellen / Bearbeiten von Karten gewinnen und dabei die Handarbeit minimieren. Die GPX-Dateien sind nur ein Zwischenschritt und im GPX-Format nur wegen des für Tracks und POIs üblichen Formats.

Zeit, die ich in MapTk investiere, muss mir einen erkennbaren Nutzen bringen. Wenn andere etwas davon haben ist das ok und ich stelle ihnen das Programm gern kostenlos zur Verfügung. Die Verbreitung von MapTk spielt dabei kaum eine Rolle. Für ein Umsonst erstelle ich keine Software auf Nachfrage - gegen Bezahlung auch nicht.

Bookmarks in GPSMapEdit werden vermutlich nicht funktionieren. Sie sind in der MP-Datei auch Kommentar, nur in einem anderen Format. Export von Bookmarks in eine CSV-Datei wäre eine Alternative wenn sich Bookmarks beim Import von ESRI-Dateien erzeugen ließen. Google-Suche 'shp gpx converter' bringt einige Treffer hinter denen sich eine Lösung verbergen könnte.

Programmierkenntnisse sind von Vorteil. Nicht nur hier. Vielleicht ein Anlass damit zu beginnen ?

Es gibt kein Feld dafür in MP-Dateien. Ich vermute, dass GPSMapEdit als Konverter herhalten muss. Als Option kann man da alle Datenfelder in den Kommentar der MP-Datei übertragen. Das ist aber Kommentar zu einem Objekt der MP-Datei, beginnend mit einem Semikolon außerhalb der Definition eines Objektes ( alles zwischen [...] und [END] ). Für die Erzeugung von IMG-Datien sind diese Informationen irrelevant und werden von MapTk überlesen bzw. ignoriert. Eine Erweiterung in diese Richtung geht am Sinn von MapTk vorbei. Ein kleines Programm, dass dieses Format in in eine GPX-Datei verwandelt, ist dann auch nicht so schwierig zu schreiben. Viel Spaß dabei !

Beim Konvertieren von Daten muss für jedes Datum in beiden Formaten ein Feld vorhanden sein. Fehlt ein Feld, geht der Inhalt des Feldes bei Import / Export verloren. Bei GPX ( zumindest in der von Garmin verwendeten Weise ) gibt es ein Feld '<cmt>.....</cmt>'. Dieses Feld kennt man im MP-Format so nicht. MapTk nutzt diese Feld um sich beim Export den Typ eines POI oder einer Linie zu merken. Ein neues Feld für MP-Dateien einzuführen ist an sich problemlos oder sinnlos: Es gibt keine Programme die damit ohne Klimmzüge etwas anfangen können. Für die Einbettung solcher Kommentare oder gar Bilder in eine 'normale' IMG-Datei sehe ich keine Möglichkeit. Wozu auch ? Um Informationen über einen Ort auf einem Gerät zu hinterlegen sind doch GPX-Dateien und georeferenzierte Bilder bestens geeignet ! Dazu noch unabhängig vom Kartenmaterial und ohne lizenzrechtliche Rücksicht verteilbar.

JürgenD

MapTk passt auf seinen Benutzer auf.

Der nutzbare Bereich für Polylines geht von 0x01 bis 0x3f ! Das Bit 6 ( 0x40 ) ist die Richtungsangabe, Bit 7 ist der Indikator für 2-Byte-Bitstream-Length. 0x47 & Co kann damit in der IMG-Datei nicht dargestellt werden, ist also illegal.

Von MapTk akzeptiert aber nicht unbedingt problemlos: 0x00 ist möglich, sollte aber vermieden werden wegen ggf. interner Anwendung für Markierungen. 0x2C bis 0x2f brauchen eine TYP-Datei. 0x30 bis 0x3f kann von (manchen ?) Geräten zwar angezeigt werden, wird von BaseCamp oder MapSource ignoriert. Der vernünftige Bereich reicht damit von 0x01 bis 0x2b.

Reicht das nicht, bleiben die 3-Byte-Codes wie z.B 0x10f0c für eine Hecke ( wie in Garmin-Topos ). Die brauchen ausnahmslos eine TYP-Datei.

Beispiel zum Download für ein Projekt: 'Sample.zip' zeigt ziemlich alle Variationen eines Kartensatzes, auch die 3-Byte-Codes.

JürgenD

Ich hab mich erbarmt.

Das beste Ergebnis meiner Experimente habe ich mal in MapTk 3.2 als alternative Palette eingebaut. Die Palette ist lose gebunden an das Projekt. In 'Header' gibt es eine Checkbox dafür. Das soll ungewollten Farbveränderungen durch unachtsames Speichern etwas vorbeugen. Ein Wechsel ist jederzeit möglich. Vorsichtige belassen es für ein Projekt bei einer der beiden Paletten. Soll eine TYP-Datei auch mit alten Geräten verwendbar sein, empfehle ich die Garmin-Palette - zumindest bis sicher ist, dass andere Farben verwendet werden dürfen.

• Neue Startparameter '-make' und '-script'.
• 'IMG': Profil für Routen kann in BaseCamp oder MapSource dargestellt werden wenn alle Kacheln einer Karte Höhenlinien enthalten.
• 'IMG Analysis': Der Name der MP-Datei kann ist mittels 'tdb.dict' im Verzeichnis der IMG-Datei bestimmbar ( 'tdb.dict' erzeugt durch 'TDB analysis' ).
• 'Make': Eine REG-Datei wird auch ohne TYP-Datei erzeugt.
• 'Script': Script entfernt überflüssige Routing-Nodes.
• 'GPX/MP': Zusammenführen von GPX-Dateien verbessert.
• 'GPX/MP': Verbesserte Suche nach nicht verbundenen Routing-Nodes. Option: Einige Knoten können automatisch miteinander verbunden werden.
• 'Typ': Vollständig transparente POIs, Linien und Polygone.
• 'Edit': Zweite Palette mit helleren Farben im Projekt-Header wählbar.
• 'File': Einheitliche Namen für GPX-Dateien.
• Verschiedene Optimierungen und Fehlerbehebungen.
• Handbuch wurde überarbeitet.

Das war es, was ich mit dem Experiment zeigen wollte. Neben dem Editor stattfindende Änderungen können lästige Effekte haben und sollten lieber vermieden werden.

Zu den 256 Farben: Ich habe trotz des schönen Wetters mit Farben über den ganzen Farbraum experimentiert und die möglichen Farben immer wieder auf eine Karte übertragen. Die Unterschiede müssen schon recht groß sein um in der Karte Wirkung zu zeigen. Am Beispiel 0xffffff und 0xffecff ist das schön zu sehen: Am PC sind die Farben im direkten Vergleich ( rosa Linie auf weißem Grund ) noch unterscheidbar. Auf einem Garmin-Display im Freien wird davon zu wenig oder nichts übrig bleiben.

Für einen Moment sollte man mal überlegen wofür die Farben stehen. Eine Landkarte ( egal ob Papier oder Elektronik ) ist nicht die Abbildung der Welt. Dafür gibt es Satelliten- und Luftbilder. Vielmehr ist es eine abstrakte. auf das Wesentlich beschränkte symbolische Darstellung. Farben und Symbole müssen ohne Mühe unterscheidbar sein, möglichst auf den ersten Blick. Also Symbole in der richtigen Größe und ohne Schnörkel. Sie sollen nicht schön sein, so wie ein Foto oder mit Farbverläufen, sondern mir klar zeigen wo z.B. das nächste Gasthaus ist. Das gilt auch für für Linien und Flächen. Nicht nur zur Planung ist es interessant, wie der Weg beschaffen ist, ob mit Autos zu rechnen ist, geht es durch den Wald oder übers Feld, ... Auch hier sind angemessene Symbolgrößen und Farbkontraste erforderlich. Auf die Farbe selbst kommt es nur wenig an, sie ist nur ein Symbol. Wichtig ist, dass ich mich draußen und bei schlechter Beleuchtung mühelos auf der Karte orientieren kann. Im Auto gilt das sogar bei hervorragenden Beleuchtungsverhältnissen.

Mein Fazit: Ähnliche Überlegungen wird man sich bei Garmin schon vor vielen Jahren gemacht haben. Die Farben von Garmin sind nicht schlecht für eine Karte, sowohl die Anzahl als auch die Farben selbst. Linien und Flächen haben max. 2 Farben. Symbole eben ! Mehr und andere Farben muss es nicht geben. Damit erübrigt sich auch die Frage nach der Kompatibilität.

@Speichernippel: Machen wir mal ein kleines Experiment. Was steht denn in der TYP-Datei bei der Farbe 0xffecff ( Typ -> TYP analysis ) ?
Die Farbpalette stammt aus alter Zeit. Ob das heute noch notwendig ist, oder überhaupt notwendig ist, weiß ich nicht. Alternativen kann ich nur mit Outdoor-Geräten ab GPSMAP60 testen, nicht mit den eTrex, Nüvi und dem Rest. Anders ausgedrückt: Ich traue mich nicht. Mir reicht die Palette eigentlich, auch wenn die Farben insgesamt heller und bunter sein könnten. Für Hilfswillige könnte ich eine Beta mit einer anderen Palette bereitstellen ( auch 239 Farben + 16 mal grau + transparent ). Das ist nur wenig Aufwand.

@Celtus: Mettwurst ist schon ok. Ich fische hier nicht nach Komplimenten. Zur Erklärung: MapTk habe ich eigentlich für mich geschrieben ( -> Süditrol-Karte ). Wenn andere damit etwas anfangen können, so ist mir das recht. Kleine Wünsche sind auch drin. Große Umbauten oder Erweiterungen, die mir nichts bringen: Nein.
Echte Fehlermeldungen sind hoch willkommen. Es kommt nur leider fast nichts ( 4 - 5 mal / Jahr und dann meist aus Spanien ). Was im Releasereport steht habe ich zu 98% selbst entdeckt.

Mal eine hinterhältige Frage: Funktioniert das denn mit dem Bearbeiten als Textfile ?

Hallo Cletus,

da ist überhaupt nichts falsch angekommen und Honig esse ich lieber auf einem Brötchen. Hinweise wo es hakt sind immer willkommen. Das von Post #4 habe ich schon in die Doku eingearbeitet. Wird vermutlich am Wochenende mit einer neuen Version von MapTk erscheinen. Version 3.2 bringt einige, weniger wichtige Änderungen.

Hallo Anton,

Ok, das akzeptiere ich. Ich selbst würde mir das nicht antun.

Natürlich sind das keine Kartenformate. IMG steht für ein Dateiformat. GMAP ist eine Ansammlung von Dateien in einem Verzeichnis <Kartenname>.gmap. Der Begriff 'Kartenformat' als Oberbegriff für eine von Garmin akzeptierte Form einer Karte macht es nur einfacher in der Kommunikation. Jeder weiß eigentlich was damit gemeint ist.

Das 'GMAP-Verzeichnis' enthält am Ende die selbe Information, die Beschreibung einer Karte - nur das Format ist unterschiedlich. Die Struktur im GMAP-Verzeichnis ist ähnlich dem Aufbau einer IMG-Datei. Verschiedene, organisatorische Teile der Kachel ( sogenannte Subfiles wie RGN, TRE, LBL, NET, NOD, ... ) sind jeweils in eigenen Dateien gespeichert. Also bei Karten mit Autorouting-Daten mindestens die 5-fache Anzahl Dateien, untergebracht in 3 Verzeichnisebenen. Die Subfiles einer IMG-Datei sind in einem Unterverzeichnis mit der Kachel-ID als Name zusammengefasst. Dadurch entfällt die, einer Platte ähnliche Struktur ( FAT ) am Anfang einer der IMG-Datei. Der Index hat ein eigenes Verzeichnis. Die TYP-Datei steht ganz oben, zusammen mit MDX und 2 kleinen Dateien: '.author' mit unbekanntem Sinn ( scheint nicht unbedingt notwendig zu sein ) und 'Info.xml' mit einer etwa der Registry entsprechenden Funktionen. Die einzelnen Subfiles im Kachel-Unterverzeichnis von *.gmap sind Byte für Byte identisch mit den Subfiles in der IMG-Datei. Die Umcodierung ( oder gleich erzeugt ) ist nicht schwierig, nur das Ergebnis ziemlich sperrig. Vorteile, die den Arbeitsaufwand rechtfertigen, sehe ich nicht. Weder für den Autor noch für den unbedarften Konsumenten.

Hallo Anton,

was ist denn daran anachronistisch ? Solange Garmin das alte Format unterstützt werde ich mir nicht die Mühe machen das Programm umzubauen. Das bringt für mich keinen Mehrwert und bezahlt werde ich dafür auch nicht. Das GMAP-Format hat auch Nachteile: Die Kachel ist nicht einfach mit GMSMapEdit zu öffnen.

Und zum Schluss: Als Moderator würde ich mir zynische Bemerkungen verkneifen, aufhören zu stänkern und weniger Apple-religiösen Eifer zeigen. Dafür lieber technisch fundierte, aussagekräftige Beiträge. Mir drängt sich immer mehr der Eindruck auf, dass die Qualität der Beiträge umkehrt proportional zur Anzahl der Beiträge mancher User ist. "Masse statt Klasse" ist ein guter Wahlspruch zum Untergang des Forums !

OSM ist nicht meine Welt und wird es auch nicht werden. Zum Rest:

'traditionell':

MapSource und BaseCamp holen sich alle Informationen aus der Registry. Fehlt dort ein Eintrag wird die Funktion ggf. nicht ausgeführt ( z.B. bei TYP ). Bei anderen fehlenden Einträgen oder Fehlern in den Einträgen schmiert Garmin ab oder ignoriert den Kartensatz je nach Version. Der Kartensatz darf irgendwo auf dem PC gespeichert sein - solange die Verweise in der Registry richtig sind.

GMAP-Format:

Alle Dateien stehen, zerlegt in Subfiles in einem Verzeichnis mit vielen Unterverzeichnissen. Der Speicherort ist von Garmin vorgegeben. Alternativ kann im vorgegebenen Verzeichnisein Link auf den Speicherort eingerichtet werden. Das macht Garmin mit den eigenen Installationen. Das vorgegebene Verzeichnis ist "%APPDATA%\Garmin\Maps" und der Zugang ist versteckt. Einen Registry-Eintrag gibt es hier nicht.

Wer es mag. Ich habe IMG2MS noch nicht einmal runtergeladen. Wozu auch ?

Der 'normale' Weg ist doch

• Kacheln mit Editor bearbeiten
• einen Kartensatz erstellen ( dazu braucht man einen Compiler und ein Tool, dass TDB, TYP und die anderen Dateien erzeugt, Routing-Nodes überprüft, ...)
• Testen der Karten in MapSource / BaseCamp
• Übertragen auf das GPS-Gerät wenn das Ergebnis ok ist

fertig und Spaß haben.

Schritt 1 ist reine Handarbeit. GPSMapEdit ist dafür ein super Werkzeug in jeder Hinsicht. Den Schritt 2 erledigt MapTk automatisch wenn das Projekt in wenigen Schritten erst mal eingerichtet ist. Schritt 3 und 4 sind wieder leichte Handarbeit. Wo ist da ein Raum für IMG2MS und andere Programme ? Auf dubiose Manupulationen an bestehenden Karten kann ich gut verzichten - mal abgesehen von TYP-Datien die ich natürlich auch mit MapTk anpasse.

Soll die Karte z.B. via Internet verteilt werden, muss noch eine Installation vorbereitet werden. Ähnlich wie der Erstellprozess kann das mit 'Inno Setup' automatisiert werden, mit einer EXE für Windows als Ergebnis wird alles erledigt. Für die Apple-Jünger gibt es am PC Garmins MapConverter, der ein passendes Archiv erzeugt.

Der große Aufwand liegt sicher nicht im Zusammenbau der einzelnen Kacheln sondern in der Einarbeitung in das Thema 'Garmin-Karten' selbst. Da hilft kein Programm, da geht es um Verstehen und Erkennen der Zusammenhänge, Möglichkeiten und Restriktionen. Das NaviBoard ist da eine gute Informationsquelle, aber leider nicht fehlerfrei. Dann noch etwas Erfahrung was man kann und was man lieber lässt. Am Ende eines nicht kurzen Weges steht eine Karte, die geeignet ist in Stückzahlen mit den verschiedensten Garmin-Programm und -Geräten problemlos benutzt zu werden. Beispiel 'Südtirol' ( 120000 Objekte = POI, Polyline und Polygon, 30000 km Straßen/Wege mit 80000 Routing-Nodes, davon 14000 km Wirtschaftswege und 10000 km Fußweg im Schnitt 200 Downloads/Woche.

Ohne die Bereitschaft zum Lernen und einem erheblichem Zeitaufwand sollte man lieber beim Konsum fertiger Karten bleiben.

@Speichernippel: Wo Garmin die FID herholt weiß ich nicht sicher. Ich denke das die TDB-Datei die zentrale Stelle ist. Zumal im GMAP-Format die Registry nicht gefüllt ist. Dafür gibt es dann noch die kleine INFO.XML mit der Information. Sicher ist nur, dass alles zusammenpassen muss. Das ist wieder ein Grund nicht händisch an die Sache heranzugehen.

@macnetz: ... und Apple ist eine Religion. Man glaubt oder bleibt kritisch.

MapTk

• Homepage: http://www.maptk.dnsalias.com
• Lizenz: völlig frei
• Sprache: englisch
• Beschreibung: Kartensätze für Garmin aus MP-Dateien automatisiert erzeugen ( Compiler, Autorouting, Suchindex, TYP-Datei, ... ). Dazu nützliche Funktionen zur Aufbereitung des Quellmaterials ( Konversion GPX <-> MP, Filter, ...).
• Betriebssystem:MS Windows, Systeme mit Python 2.5 bis 2.7 (z.B. Mac, Ubuntu)

Warum und wozu cGPSMapper in der MP-Datei braucht ist mir nicht bekannt - und auch ziemlich egal. MapTk braucht das nicht. Schon weil in der IMG-Datei kein Platz dafür vorgesehen ist ! Das sollte ich eigentlich wissen. Denn "Wissen ist Macht. Unwissenheit macht auch nichts." ( aus dem WWW ).

Die FID steht in der TDB, MDX, der TYP-Datei und natürlich auch in der Registry. Das wird alles von Garmin zur 'gmapsupp.img' verwurstet.

@Cletus: Das Manual von MapTk ist als Referenz gedacht. Eine Anleitung zum erstellen von Karten für Garmin zu schreiben ? Dafür fühle ich mich nicht berufen. Nach einem Versuch vor langer Zeit habe ich es aufgegeben. Zu viel Aufwand. Ergänzungen und eine Liste von wissenswerten Fakten für die Doku werde ich aber erstellen.

Zu den bereits umschifften Klippen:

• Ein mit Garmin anzuzeigende ( und damit auf ein Gerät übertragbare ) Karte braucht immer eine Übersichtskarte. Die wird spätestens nach Erstellung in die Liste der Maps eingetragen um sie im Make zu berücksichtigen ( compilieren ). Kapitel 3.5
• Die IDs ( ID=... ) von Kacheln ist immer eine 8-stellige Dezimalzahl. Die Übersicht sollte auch 8 Zeichen lang sein, beginnend mit einem Buchstaben. Kapitel 1.3

Warum so umständlich ?

'Make' in MapTk erstellt nach Änderungen jeglicher Art immer einen aktualisierten Kartensatz für MapSource oder BaseCamp. Nur die Registry muss ggf. händisch durch Doppelklick auf die REG-Datei ( nach Änderung von Daten in 'Header' ) aktualisiert werden. Dieser Kartensatz kann, auch wenn es nur eine Kachel gibt, auf ein Gerät oder Speicherkarte mit MapSource ( oder MapInstall für BaseCamp-Liebhaber ) als 'gmapsupp.img' transferiert werden. Andere Tools sind nicht nötig.

'gmapsupp.img' ist ein Container, der alle Kacheln und alle TYP-Dateien enthält ( eine Kachel oder eine TYP-Datei ist auch 'alle' ). Dazu kommen die Daten der Kartensätze, wie sie in der TDB-Datei enthalten sind. In der TDB-Datei steht die FID, nie in einer Kachel-IMG ( müsste ja sonst im Header der MP-Datei stehen ). MapTk erzeugt und aktualisiert die erforderlichen Dateien. Die Programme von Garmin fügen diese zuverlässig zu 'gmapsupp.img' zusammen.

Aus der Erinnerung, ohne es näher untersucht zu haben:

• POIs werden immer gezeichnet.
• Beschriftungen schreibt Garmin wenn man glaubt genug Platz dafür zu haben.
• Linien nach dem Typ absteigend in der Zeichenreihenfolge. Also Autobahn zuletzt (Type=0x01) über Bundesstraße (Type=0x02) und anderen Wegen. Ganz unten, also zuerst gezeichnet, die erweiterten Typen. Damit fließt ein Fluss (Type=0x1f) über einen Lift (bei Type=0x10e15).
• Die DrawPriority regelt die Zeichenreihenfolge der Polygone. Damit kann man dann z.B. Häuser über Orten in niedrigem Level darstellen.

In der Summe ist das sinnvoll.

Tipp: Für Tunnel und Brücken habe ich eine Linie definiert, die breiter ist als alle Straßen und damit eine Markierung daneben zeichnet.

Eine Alternative: Im Tunnel die Straße durch eine transparente Linie (routingfähig) mit den Restriktionen der Straße ersetzen. Eine falsche Klasse oder Geschwindigkeit des kleinen Teilabschnittes wird keinen merkbaren Einfluss auf die Berechnung einer Route haben. Ähnliches verwende ich um z.B. Seilbahnen in Routenberechnungen einzubeziehen ohne die wenigen, für Routing geeigneten Linien dafür zu verschwenden. Diese Linie verwende ich auch um nicht sinnlos Plätze mit nicht vorhandenen Wegen zu pflastern.

Die TDB-Datei muss aber entsprechend ausgerüstet sein. Sonst tut es eine 'echte' DEM-Karte der Region auch.

DEM-Subfiles in Karten einzubinden ist kein Problem. 'Freie' DEM-Subfiles gibt es z.Zt. nicht. An der Erzeugung von bin ich bisher gescheitert. MapTk wird deshalb das Einbinden von DEM-Subfiles nicht ermöglichen. MapSource und BaseCamp berechnen das Profil aus Höhenlinien. Bei den Geräten reicht es für die Region eine Karte mit DEM-Subfile installiert zu haben.
Mit der Möglichkeit bei der Planung das Profil darzustellen hat meine Motivation 'echtes' DEM zu erzeugen stark gelitten. Enthalten alle Kacheln eines Kartensatzes Höhenlinien wird in der nächsten Version von MapTk die Profildarstellung automatisch bereitgestellt.