Garmin-Karte mit mkgmap oder Composer selbst erstellen

Ich habe mir zum Ziel gesetzt, einen individuellen Garmin-Plan zu erzeugen, und möchte hier meine Erfahrungen mit mkgmap und dem Composer wiedergeben.
Im Anschluss daran habe ich auch ein paar Fragen zum direkten Aufruf von mkgmap und hoffe auf weitere Infos zu dem spannenden Thema der OSM-Garmin-Maps.

Wie man mit mkgmap einen Garmin-Plan erstellt ist bereits mehrmals zusammengefasst worden. Hier einige Links, die dabei hilfreich sein können.

http://wiki.openstreetmap.org/wiki/Mkgmap mkgmap im wiki
http://wiki.openstreetmap.org/wiki/Mkgmap/help Zusammenfassung der mkgmap Doku
http://wiki.openstreetmap.org/wiki/User:Garmin-User Anleitung des Users Garmin-User
http://wiki.openstreetmap.org/wiki/User:Pixt Anleitung des Users Pixt
http://forum.openstreetmap.org/viewtopic.php?id=8094 Anleitung des Users speedpilgrim
http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/POI_Types Liste der Garmin POI Typen
http://composer.waldpfa.de/index.php/Main/HomePage Homepage des Composers von Nop

Zuerst an dieser Stelle einen Dank an die Programmierer von mkgmap und an Nop, den Programmierer des Composers sowie an alle, die mit ihren Anleitungen die erfolgreiche Anwendung dieser Tools ermöglichen.
Ohne nochmals diese ausführlichen Anleitungen wiederholen zu wollen hier nur eine kurze Zusammenfassung. Ich beschreibe zuerst die Erstellung ohne Composer und zeige dann, welche Vorteile der Composer bietet.
Der Planerstellung gliedert sich grob in folgende Schritte.

1.) Download der OSM-Daten (genannt Planet-File).

Der komplette Datensatz oder auch nur ein Ausschnitt nach Koordinaten können per Download-Manager von einem der drei Full-Mirror-Server (siehe http://wiki.openstreetmap.org/wiki/Planet.osm)) heruntergeladen werden.
Damit wird der Hauptserver weniger belastet. Der Download kann auch per Batch-Script erfolgen oder man erzeugt sich per täglichen Changefiles selbst ein tagesaktuelles Abbild (siehe Beschreibung des Garmin-Users).

Weiters gibt es Extracts-Server auf denen einzelne Gebiete (Länder oder bei D sogar Bundesländer) zu finden sind.
Der Nachteil bei so einem Plan ist, dass er kein rechteckiges Gebiet mehr umfasst sondern an der Grenze abgeschnitten ist. Noch dazu lassen sich die einzelnen Gebiete nicht mehr nahtlos zusammenfügen. Wer jedoch zum Beispiel einen Europa-Plan (oder einen Ausschnitt daraus) erzeugen will, kann mit diesen Extracts sicher etwas anfangen. Am bekanntesten ist vermutlich der Download von http://download.geofabrik.de/osm/

Der Composer kann sowohl mit vorab geladenen Planet-Files arbeiten, als auch den automatischen Download von einem der Server selbst durchführen.
Das Mergen von Changefiles wird vom Composer derzeit nicht direkt unterstützt und müsste daher händisch oder per Script vorab erfolgen.

Zusammenfassend:

a.) Download von einem Full-Mirror-Server (gesamtes Planetfile oder Ausschnitt nach Koordinaten) händisch, per Script oder über den Composer.
VT: jedes beliebige Gebiet abrufbar / NT: hohe Datenmenge

b.) Download von einem Extracts-Server
VT: vorgefertigte Gebiete je nach Wahl / NT: Grenzen nicht nahtlos, Nord-Amerika nicht verfügbar (zu hohe Datenmenge)

c.) Download per Changefiles
VT: geringe Datenmenge (nur tägliche Änderungen) / NT: Aufwand des Zusammensetzens per osmosis.

2.) Schneiden der Daten mit Osmosis http://wiki.openstreetmap.org/wiki/Osmosis

Osmosis kann Gebiete aus einem Planet-File nach Koordinaten ausschneiden oder auch Changefiles zusammenführen. (Es gibt noch weitere Funktionen die hier nicht benötigt werden.)
Wer das gesamte heruntergeladene Gebiet als Plan erstellen möchte, der kann sich diesen Schritt natürlich sparen.

3.) Splitten der Daten in einzelne Kacheln. http://www.mkgmap.org.uk/page/tile-splitter

Da größere Gebiete (mehrere km²) nicht am Stück erzeugt werden können, teilt der Tile-Splitter das Gebiet in einzelne Kacheln, mkgmap kann diese Kacheln wieder nahtlos zusammenfügen.
Der Composer hat einen eigenen Splitter eingebaut, der jedoch anders arbeitet und kein nahtloses Zusammenfügen durch mkgmap ermöglicht. Routing über Kachelgrenzen ist damit nicht möglich.

4.) Planerstellung mit mkgmap http://wiki.openstreetmap.org/wiki/Mkgmap

Hier kann man über Styles sehr schön festlegen, welche Linien (bzw. Flächen) und Punkte wie und ab welcher Auflösung dargestellt werden sollen.
Wer nicht das Standard Look&Feel von Garmin verwenden möchte, kann über TYP-Files auch das Aussehen der Objekte verändern.
Hier gibt es jedoch eine Stolperfalle. Garmin hat einige hartcodierte Einstellungen, die nicht verändert werden können. Diese sind leider bisher nirgends dokumentiert, man merkt es daher erst dann, wenn sich etwas nicht ändern läßt.

Das TYP-File kann entweder mit dem Online TYP-Editor http://ati.land.cz/gps/typdecomp/editor.cgi erstellt und bearbeitet werden, oder wesentlich komfortabler mit dem Composer.

Das Ergebnis ist ein fertiger Garmin-Plan im img-Format, den man mit GPSMapEdit http://www.geopainting.com/en/ direkt am PC ansehen kann.
Wichtig! Diesen Plan immer auf eine Speicherkarte in den Garmin laden, niemals in den internen Speicher. Im Falle eines Fehlers kann es sein, dass das Gerät nicht mehr bootet.

Liste weiterer Programme:

http://www.cgpsmapper.com/ ist eine alternative (aber nicht kostenlose) Möglichkeit, Garmin-Pläne zu erstellen.

GMapTool http://www.anpo.republika.pl/download.html kann img-Files zusammenfügen und auch wieder trennen. (nützlich für Multi-Layer-Pläne)

http://wiki.openstreetmap.org/wiki/Srtm2osm wandelt Daten von Höhenlinien in das OSM-Format.

sendmap20: Überträgt eine img-Datei zu einem Garmin-Gerät. Da diese SW bei der Übertragung den Namen des Plans zerstört, verwende ich lieber Copy-Paste zur Übertragung.

Hier meine ersten Erfahrungen:

Mein Einstieg in die Planerstellung erfolgte über den Composer. Dieses Programm ist mehr als nur ein Frontend für mkgmap.
Für mich bietet der Composer folgende Vorteile gegenüber dem skriptgesteuerten Aufruf von mkgmap.

1.) Einfach zu bedienende Oberfläche und sehr gute Anleitung. Bereits nach kurzer Einarbeitung konnte ich Pläne im mitgelieferten Composer-Style erzeugen.

2.) TYP-File Erstellung über den Online-Editor entfällt. Einfach die gewünschten Icons als png-File erstellen, den Rest macht der Composer.
Das ist für mich der wichtigste Grund, warum ich heute nicht mehr auf den Composer verzichten möchte. Mein jetziger Plan ist eine Mischung aus Composer-Style, All-in-One Style und einigen eigenen Ideen.

3.) Automatische Erstellung von Höhenlinien (über srtm2osm), wer mag auch von Markierungen für Wanderrouten, … - und das alles unter einer Oberfläche.
Zusätzlich ist es möglich, am Ende ein eigenes Batch-File aufzurufen, mit dem man weitere Schritte automatisiert anhängen kann.

Es gibt jedoch auch einige Einschränkungen in der aktuellen Version, die sich laut Nop nicht so leicht beheben lassen.

1.) Der Composer soll möglichst einfach zu bedienen sein und bietet daher keine Unterstützung für Multi-Layer-Karten.
Die All-in-One (http://wiki.openstreetmap.org/wiki/DE:All_in_one_Garmin_Map) zeigt vorbildlich auf, was mit Multi-Layer alles machbar ist.
Meine Anforderungen sind etwas geringer, mir genügt ein Overlay für Höhenlinien und ev. ein zweiter für Skipisten.
Es ist mir gelungen, mit dem Composer ein Overlay für Höhenlinien zu erstellen, aber es war viel Handarbeit notwendig. Zum Glück ändern sich Höhenlinien kaum.

2.) Der Composer bietet keine Möglichkeit, den Tile-Splitter statt dem internen Splitter zu verwenden. Routing ist damit nur bis zur nächsten Kachelgrenze (also wenige km) möglich.
Ich habe keine Möglichkeit gefunden, diese Einschränkung zu umgehen und laut Nop ist es auch nicht zielführend, eine Schnittstelle zum Tile-Splitter einzubauen, da die Arbeitsweisen der Splitter zu unterschiedlich sind.
Daher rufe ich aktuell nach dem Composerlauf nochmals den splitter und mkgmap direkt auf, um mit dem TYP-File aus dem Composer einen voll routingfähigen Plan zu erstellen.
Auf diese Art kann ich von beiden Programmen das jeweils beste kombinieren.
Leider sind die Ersetzungen des Composers nicht 1:1 auf Styles für mkgmap übertragbar. Dafür ist also immer noch Handarbeit notwendig. Da mein Style jedoch großteils fertig ist, erwarte ich nicht mehr allzu viele Änderungen.

Ein aktuelles Problem bei der Übertragung der Styles ist folgendes:
Beim Composer konnte ich problemlos Overlay-Icons auf Flächen setzen, nicht jedoch auf Punkte.
Bei mkgmap ist es mir gelungen, Overlay-Icons auf Punkte zu setzen, nicht jedoch auf Flächen.
Meine erste Frage lautet jetzt: Wo gibt es weitere Anleitungen zu mkgmap bzw. wie kann ich dieses Problem lösen?

Ich hoffe, hier eine brauchbare Zusammenfassung erstellt zu haben und werde in den nächsten Posts weitere Erfahrungen bringen.

Walter

Hallo Walter,
wie es mit den Overlays auf Flächen aussieht kann ich dir leider nicht sicher sagen, aber hast du schonmal mit continue im polygon-file herum gesspielt? Ansonsten frag doch mal auf der mkgmap-dev ML nach. Ich geh mal nicht davon aus, dass du nur ein Icon auf der Fläche gerendert haben möchtest.

Das was du als “Overlay für Höhenlinien” ist ja kein Overlay sonder einfach nur eine transparente, zusätzliche Karte. Das kann doch der Composer auch, gut du brauchst eine zweite Installation, da su unterschiedliche Styles haben möchtest. Ich glaube aber nicht, dass der Composer nur Höhenlinien verarbeiten kann. Sprich, er wird auch dann ein planetfile-extract haben wollen und verarbeiten, wenn du keine Renderregeln hast.
Die Einzelkarten kannst du dann entweder mit MapSource oder mit mkgmap verheiraten.

Hallo Henning,

genau so wie du es beschreibst habe ich die Höhenlinien mit dem Composer auch erstellt. Ein zweiter Lauf (mit einem Dummy-POI, sonst rendert er nicht) und dann zusammengefügt.
OK, den Begriff Overlay habe ich jetzt doppelt verwendet, die zusätzliche transparente Karte bereitet mir auch keine Probleme mehr.

Den continue Befehl verwende ich, aber er funktioniert nur innerhalb eines Style-Files.
Ich kann also damit auf einen Punkt einen zweiten setzen, oder auf eine Linie eine zweite (das verwende ich z.B. für Einbahnen und Brücken).

Mit dem mkgmap Parameter --add-pois-to-areas werden zwar POIs auf Flächen gesetzt, aber es funktioniert dann weder der Continue Befehl noch die Namensänderung des POI.

Beispiel:
shop=supermarket & name=Aldi [0x6901 resolution 22 continue]
shop=supermarket [0x2E02 resolution 23]

Bei einem Aldi-Supermarkt als Punkt wird das Aldi-Symbol (0x6901) gesetzt, bei dem gleichen Supermarkt als Fläche wird jedoch das Standard-Symbol (0x2E02) gesetzt.
Den gleichen Trick verwende ich bei Tankstellen, um Geschäfte mit WLAN-Netz besonders zu kennzeichnen, für Sehenswürdigkeiten, …
Damit diese Tankstellen und Supermärkte auch als Garmin POI gesucht werden können sind natürlich die Standard-POIs weiterhin notwendig.

Ich bin derzeit auf der Suche nach einem Anwenderforum für mkgmap, diese Mailingliste ist ja eher etwas für Entwickler. http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Walter

In dem Fall bräuchtest du kein continue. Continue brauchst du nur, wenn du mehrere Tags eines Objekts auswerten möchtest.

Ich bin mir nicht ganz sicher, wie add-pois-to-area funktioniert. Wenn ich es richtig angenommen habe, dann müsstest du im polygon-File auch die Regel shop=supermarket & name=Aldi haben. Hast du das schonmal ausprobiert?

Hallo Henning,

deine Aussagen verstehe ich leider beide nicht.

1.) mit
shop=supermarket & name=Aldi [0x6901 resolution 22]
shop=supermarket [0x2E02 resolution 23]
bekämen alle Aldi-Märkte nur einen 0x6901 Punkt und keinen 0x2E02 Punkt mehr. In der Liste der POIs werden aber nur Supermärkte mit 0x2E02 aufgelistet.
Daher benötige ich den continue Befehl und er macht ja auch genau das, was ich erwarte - leider aber nicht bei den von Flächen zu Punkten gemappten Objekten.

2.) Welche Regel soll ich denn im Polygon-File einbauen? Dort kann ich doch nur Flächen darstellen und keine POIs.
Meine derzeitige Regel hier lautet: shop=supermarket [0x0B resolution 22]
Die Fläche wird auch als Gebäude gezeichnet, aber das hat doch nichts mit den POIs zu tun.

Walter

Acheo, ja dafür brauchst du dann ein continue. Da hast du recht.

Mein Verständnis von add-pois-to-areas ist so, dass er zu den Flächen im polygon-file im point-file schaut und das Symbol nimmt, welches hinter der entsprechenden Regel hinterlegt ist.
Wenn du im polygon-file jetzt nur shop=supermarkt auswertest, schaut er auch im point-fle nur unter shop=supermarkt und nimmt dieses Icon. Wenn du aber im polygon-file shop=supermarket & ( name=Aldi | operator=Aldi ) auswertest, dann dürfte er auch das Aldi-Symbol rendern. Es kann aber auch sein, dass ich mich irre.

Hallo Henning,

ich habe folgende Polygon-Regel eingefügt:

shop=supermarket & name=Aldi [0x0B resolution 22 continue with_actions]

geholfen hat es aber nichts.

Was mir ebenfalls aufgefallen ist.
Ich füge oft Zusatzinfos zum Namen hinzu, auch das funktioniert bei mir nur bei Punkten, nicht bei Flächen die auf POIs gemappt werden.

Beispiel:
tourism=hotel & stars=* { add name=‘’; name ‘${name} (${stars}-Stern)’ } [0x2B01 resolution 22]

Mit add name=‘’ wird ein Leerzeichen als Name eingefügt, falls kein Name existiert. Damit wird die Regel für die Namensersetzung immer ausgeführt.
Leider entgehen mir jedoch alle Hotels die als Fläche erfasst sind.

Mache ich da irgendetwas falsch?

Es scheint mir so, als ob nach --add-pois-to-areas nicht mehr die gesamten Regeln des points Styles auswertet.

Walter

Hallo Walter,

diese Regel für die Namensersetzung wird ebenfalls immer ausgeführt, aber vielleicht ist sie weniger fehleranfällig:

{ name ‘${name} (${stars}-Stern)’ | ‘${stars}-Stern’ }

So kommt die nachträgliche Benamung in der Reihenfolge des angegebenen Umfangs der zu testenden Tags zur Geltung, also ohne dem Namens-Tag der zweite Teil.

Sollen keine extra Symbole für jede Sterne-Kategorie angezeigt werden, reicht auch ein

tourism=hotel { name ‘${name} (${stars}-Stern)’ | ‘${name}’ | ‘${stars}-Stern’ } [0x2B01 resolution 22]

Wird keiner der “${Tags}” gefunden, also auch kein Name, erscheint dann die allgemeine Bezeichnung aus dem Typfile. Diese Möglichkeit ist aber vergeben, wenn man den POI mit Leerzeichen benamt hat und es wäre umständlich, jeden dieser Fälle mit einer eigenen Tag-Test-Kombination abzufangen.

Probier’s mal aus bei den Flächen, viel Glück…

Viele Grüße
Mario

Hallo Mario,

vielen Dank für deinen Tipp, ich habe meine Regeln gleich umgebaut.
Leider besteht mein Problem immer noch.

Wenn ein amenity in OSM als Punkt erfasst ist, dann kann ich den Namen im Style-File beliebig ändern.
Wenn ein amenity jedoch als Fläche erfasst ist und mit der Option add-pois-to-areas zum POI wird, ist der Name nicht änderbar,
und auch der continue Befehl greift bei solchen Objekten nicht.
Ich habe auch schon probiert, die Option name-tag-list zu entfernen bzw. die Option no-poi-address zu setzen, auch das hat nichts geholfen.

Ich habe mir gerade das Style-File der All-in-One angesehen, dort gibt es Namen-Ersetzungen nur bei POIs die immer als Punkt erfasst werden.
Daher hier meine Frage: Gibt es jemanden, der den Namen von POIs ändern will, auch wenn diese als Fläche erfasst sind? (z.B. Hotels, Shops, …)

Walter

Hallo Walter,

das beste wäre wohl das Problem mit den Flächen bzw. dem add-pois-to-areas mal auf der dev-Liste anzusprechen. Evtl. ist sowas ja noch nicht implementiert.