Karte erstellen

Für jedes Ausgabeformat geht das anders.

Die Karte soll in Basecamp genutzt werden.

Garmin-Format hast du doch schon einige Male hier angesprochen, langsam sollte das laufen. Wenn nicht, dann bleibe bitte bei deinen anderen Threads.

Dann fängst Du einfach hiermit an:

http://wiki.openstreetmap.org/wiki/Mkgm … eate_a_map

Und wenn Du das am laufen hast, kommt der nächste Schritt, die Dateien anpassen.

Java, mkgmap und splitter sind installiert. Die OSM Daten habe ich von http://download.geofabrik.de/europe/alps.html (alps-latest.osm.pbf)

In der Anleitung steht

Use splitter to split the raw map data into smaller pieces, called tiles. This is necessary because most of the downloaded region extracts are too big to be processed by mkgmap.

Gilt das auch für den Alpen Extrakt?

Da du mich im anderen Thread darum gebeten hast hier zu beschreiben wie ich meine Karte erstellt habe:

Ich habe erst mal mit dem Default mkgmap Style angefangen, also einfach erst mal mit splitter und mkgmap vertraut machen. Dann habe ich mich an ein angepaßtes Style-File und TYP-File gemacht. Dazu habe ich nicht bei Null angefangen sondern Styledatei und TYP-Datei der Süddeutschland+ Karte von Joachim Moskalewski verwendet (http://www.gpxtour.de/de/page/getmap/). Man sollte sich dazu auch unbedingt die im Internet vorhandene Doku zu Styledateien und TYP-Dateien durchlesen. Ich bin dann fast alle Punkte in der Style-Datei und analog jeweils das selbe in der TYP-Datei durchgegangen und habe für die TYP-Datei auch jede Menge neuer Icons mit Gimp entworfen. Die Icons werden im XPM Format gespeichert, welches letzendlich nichts anderes als ein Textformat ist. Daher ist die Ausgangsbasis für die binäre TYP-Datei ebenfalls eine simple Textdatei in die ich die XPM-Dateien eingefügt habe. Auch die Styledatei ist eine simple Textdatei deren Format im Wiki beschrieben wird. Die Garmin-Hexcodes welche in der Styledatei verwendet werden müssen, finden sich in diversen Dokus die ich im Internet gefunden habe.

Wenn man eine Routingfähige Karte möchte: Achtung! Nicht alle Garmin Hexcodes für Ways sind auch routingfähig. Generell gibt es leider viel weniger Garmin Types als Varianten von OSM-Wege Typen. Daher muß man immer irgendwie Informationen unter den Tisch fallen lassen. Welche, das macht dann den Verwendungszweck der Karte aus. Für eine Wanderkarte lassen sich zum Beispiel Autobahnen und Bundesstraßen mit nicht Routingfähigen Garmintypen belegen. Aber selbst die nicht Routingfähigen Garmintypen werden einem schnell ausgehen, wenn man viele Wegearten berücksichtigen will. Die Freizeitkarte beispielsweise faßt jeweils 2 sac_scale Grade zu einer Darstellung zusammen. Für eine Freizeitkarte ist dies OK, eine Bergwanderkarte sollte dies aber weiter differenzieren: Bei meiner Karte werden lediglich T5/T6 zusammengefaßt und ansonsten gibt es für jedes sac_scale eine eigene Linie.

Das manuelle Editieren der TYP-Datei ist etwas fehleranfällig. Für Windows gibt es auch entsprechende Editoren, da ich aber Linux und OpenBSD verwende editiere ich die TYP-Datei direkt und habe mir dazu ein paar passende vim-Makros gemacht.

Was den Kartenausschnitt angeht: Wie bereits gesagt verwende ich (wenn ich nicht einen Geofabrik-Extrakt direkt verwende) osmconvert um eine passende bbox aus einem größeren Extrakt auszuschneiden (-b Option von osmconvert). Dieses Verfahren benutze ich insbesondere bei der Grenzkarte und allen Pluskarten.

Ein paar Shellscrips erleichtern mir inzwischen Kartenupdates (die ich aber im wesentlichen immer noch von Hand mache).

Der Workflow sieht dann so aus:

- Runterladen eines größeren Geofabrik Extraktes (oder Alternativ: Update eines vorhandenen Extraktes mit osmupdate)
- Mit osmconvert den benötigten Ausschnitt ausschneiden.
- Mit splitter diesen Ausschnitt teilen
- Das Resultat dann mit mkgmap weiterverarbeiten, mkgmap nutzt das vorher erstellte TYP- und Stylefile.
- Fertig

Die meiste Arbeit im Vorfeld verursacht das vertraut machen mit der Syntax des Stylefiles, das Erstellen/Anpassen des Stylefiles und das Erstellen/Anpassen des TYP-Files.

Wühl dich erst mal durch die Doku:
http://wiki.openstreetmap.org/wiki/Mkgmap/help
Dieses wären Beispiele für routingfähige und funktionierende Style- und TYP-Datei (in diesem Fall zum Radfahren):
http://gps.maroufi.net/download/myradstyle.zip
http://gps.maroufi.net/download/TYPMASTER-RAD.TXT

Gruß
unixasket

yow wrote:

Gilt das auch für den Alpen Extrakt?

Ja! Sofern es mehr als ein paar MB sind gilt dies immer (Es gilt zum Beispiel nicht für ein Liechtenstein-Extrakt).

Gruß
unixasket

Vielen Dank! Das muss ich wahrscheinlich mehrmals durchlesen damit ich alles verstehe.

Wenn Garmin so eingeschränkt ist wäre es vielleicht besser die Karte für andere Programme zu erstellen?

java␣-jar␣splitter.jar␣alps-latest.osm.pbf

steigt mit

Exception␣in␣thread␣"main"␣java.lang.OutOfMemoryError:␣Java␣heap␣space

aus.

Im Wiki steht

If you get an "OutOfMemoryError: java heap space" error, you'll need to increase the available memory by using the -Xmx parameter. (eg. java -Xmx2000M -jar mkgmap.jar ...)

Wie berechnet sich dieser Parameter? Der Rechner hat 8 GB RAM.

Moin,

Dir ist aber schon bekannt dass es auch fertige Karten für BaseCamp gibt?
Freizeitkarte z.B. hier: http://osm.geoclub.de/

LG,

-moenk

yow wrote:

Im Wiki steht

If you get an "OutOfMemoryError: java heap space" error, you'll need to increase the available memory by using the -Xmx parameter. (eg. java -Xmx2000M -jar mkgmap.jar ...)

Wie berechnet sich dieser Parameter? Der Rechner hat 8 GB RAM.

Sowohl splitter, als auch mkgmap brauchen für große Regionen auch viel Speicher. Wenn du 8 GB hast und nicht zu viele andere Prozesse parallel laufen kannst du zum beispiel 6 GB für splitter reservieren:

java␣-jar␣splitter.jar␣-Xmx6000M

6000M ist eigentlich etwas weniger als 6 GB.

@moenk:

Hättest du alle seine Threads verfolgt, wüßtest du das er die Freizeitkarte bereits ausgiebig ausprobiert hat, aber mit dem Routing nicht zufrieden ist.

Gruß
unixasket
P. S.: Für den Einstieg habe ich auch mal was geschrieben:
http://gps.maroufi.net/mkgmap.shtml

Gibt es auch einen Parameter der allen vorhandenen Speicher verwendet? Man muss es ja nicht künstlich beschränken, oder doch?

Und muss der Parameter vor oder hinter -jar, weil im Wiki steht

java -Xmx2000M -jar mkgmap.jar

Bitte noch beachten, dass das mkgmap style-System vor kurzem ziemlich umgekrempelt wurde.
Wer also bestehende Fremd-styles als Basis nimmt muss auf die passende mkgmap Version achten.

yow wrote:

Wenn Garmin so eingeschränkt ist wäre es vielleicht besser die Karte für andere Programme zu erstellen?

Ja. 🙄

yow wrote:

Gibt es auch einen Parameter der allen vorhandenen Speicher verwendet? Man muss es ja nicht künstlich beschränken, oder doch?

Doch! Schließlich willst du nicht, daß Java allen verfügbaren Speicher deines Systems benutzt, immerhin gibt es noch andere Prozesse.

yow wrote:

Und muss der Parameter vor oder hinter -jar, weil im Wiki steht java -Xmx2000M -jar mkgmap.jar

Sorry, mein Fehler: Es muß davor stehen, meine Zeile oben ist also falsch, die Angabe im Wiki korrekt.

Gruß
unixasket

Ich habe es jetzt so gemacht:

java␣-Xmx8G␣-jar␣splitter.jar␣alps-latest.osm.pbf␣>␣splitter.log

Läuft gut und hat nur wenige Minuten gedauert. Übrigens zeigt das Logfile insgesamt 139 Zeilen mit Incomplete multipolygon relation Meldungen.

Als nächster Schritt steht im Wiki

These tiles can be compiled into a map as-is, but the resultant map would lack addressing data (e.g. city or zip code). Addressing data comes from preprocessed bounds tiles, and you can either download them from navmaps.eu or create them yourself as described in Mkgmap/help/options#Using_preprocessed_bounds_for_the_address_index. Place the resultant files into a subdirectory named bounds.

Adressen und Postleitzahlen spielen fürs Bergsteigen eigentlich keine Rolle. Muss ich das trotzdem machen? Gipfel, Hütten usw sollten natürlich enthalten sein.

yow wrote:

Adressen und Postleitzahlen spielen fürs Bergsteigen eigentlich keine Rolle. Muss ich das trotzdem machen? Gipfel, Hütten usw sollten natürlich enthalten sein.

Nein, ich mache das auch nicht. Da geht es nur um die Adresssuche. Alles andere funktioniert auch ohne. Laß diesen Schritt einfach weg.

Gruß
unixasket

Dann muss der Parameter --bounds in mkgmap auch weggelassen werden, oder? Also

java -Xmx8G -jar mkgmap.jar --route --add-pois-to-areas --index --gmapsupp 6324*.osm.pbf > mkgmap.log

yow wrote:

Dann muss der Parameter --bounds in mkgmap auch weggelassen werden, oder?

--bounds kenne ich gar nicht, ich weiß nicht was das macht. Ich verwende es jedenfalls nicht. Der Adressindex wird über --index erzeugt. Das benütze ich auch nicht.

Gruß
unixasket

Also nur?

java -Xmx8G -jar mkgmap.jar --route --add-pois-to-areas --gmapsupp 6324*.osm.pbf > mkgmap.log

chris66 wrote:

Bitte noch beachten, dass das mkgmap style-System vor kurzem ziemlich umgekrempelt wurde.
Wer also bestehende Fremd-styles als Basis nimmt muss auf die passende mkgmap Version achten.

Das habe ich gar nicht mitbekommen. Könntest Du da mehr dazu sagen bzw. findet man irgendwo Infos dazu?

Ich verstehe das so, daß ich derzeit keinen SVN Update auf meiner Kopie von mkgmap machen sollte, wenn ich will daß meine Karte weiterhin baut, oder?

bye, Nop

yow wrote:

Also nur?

java -Xmx8G -jar mkgmap.jar --route --add-pois-to-areas --gmapsupp 6324*.osm.pbf > mkgmap.log

Kommt drauf an was du sonst noch machen willst. ich verwende zum Beispiel auch noch:

--gmapsupp um direkt eine gmapsupp.img Datei fürs Garmin zu erstellen. Wenn du es aber nur für Basecamp erstellen willst, ist das nicht nötig.

--remove-short-arcs verhindert Routingfehler bei kurzen Bögen.

--description="Text" setzt eine im Garmin sichtbare Beschreibung
--family-name="Text" setzt einen Namen der ebenfalls im Garmin sichtbar ist
--series-name="Text" setzt ebenfalls einen Namen der aber bei mir nur in QLandkarte sichtbar ist (vermutlich auch in Basecamp)
Diese setzte ich meist alle 3 gleich.

Wenn du eine Style-Datei hast brauchst du noch:
--style-file=styledatei
eine TYP-Datei wird zusätzlich am Ende eingegeben. Für eine TYP-Datei mußt du auch eine family-id mit der gleichen Nummer angeben:
--family-id="1919"

Zu beachten ist, das später am Garmin nur Karten mit unterschiedlichen map-ids und unterschiedlichen family-ids angezeigt werden. Du mußt also andere Nummern verwenden als die der anderen von dir verwendeten Karten (P. S.: ich verwende für meine Karten zum Beispiel für family-ids den Nummernraum von 9000 - 9999 und für map-ids den Nummernraum von 90000000 - 9999999) .

Gruß
unixasket

Wie öffne ich die so erstellte Karte in Basecamp?

Nop wrote:

chris66 wrote:

Bitte noch beachten, dass das mkgmap style-System vor kurzem ziemlich umgekrempelt wurde.
Wer also bestehende Fremd-styles als Basis nimmt muss auf die passende mkgmap Version achten.

Das habe ich gar nicht mitbekommen. Könntest Du da mehr dazu sagen bzw. findet man irgendwo Infos dazu?

Siehe:
http://www.mkgmap.org.uk/news/2013/12/2 … iles-style

yow wrote:

Wie öffne ich die so erstellte Karte in Basecamp?

Mit Basecamp habe ich noch nie gearbeitet (habe nicht das passende OS dafür). Ich nutze QlandkarteGT und da öffnet man einfach die osmmap.tdb Datei und muß dann noch die passende osmmap.img auswählen. Ich würde in Basecamp einfach mal das gleiche Probieren.

Gruß
unixasket

Mit QLandkarte GT konnte ich die Karte direkt öffnen, allerdings komme ich mit dem Programm nicht zurecht. Basecamp finde ich deutlich einfacher zu bedienen. Mit dieser Anleitung http://www.kainer.net/mike/content/view … g,germani/ hat es auch mit Basecamp geklappt.

Die Karte ist extrem detailreich, das gefällt mir sehr gut. Wahnsinn, was die Leute alles eintragen!

Aufgefallen ist mir folgendes:
- Keine Umlaute (Beispiele: Hohle statt Höhle; Konig statt König etc)
- Teilweise auf Englisch (Beispiele: Water statt Wasser/Wasserstelle/Trinkwasser; Toilets statt Toiletten/WC; Parking statt Parken/Parkplatz)

Wie kann ich das korrigieren?

yow wrote:

Aufgefallen ist mir folgendes:
- Keine Umlaute (Beispiele: Hohle statt Höhle; Konig statt König etc)
- Teilweise auf Englisch (Beispiele: Water statt Wasser/Wasserstelle/Trinkwasser; Toilets statt Toiletten/WC; Parking statt Parken/Parkplatz)

Wie kann ich das korrigieren?

Indem Du Style (und TYP) selbst erstellst. Werfe mal einen Blick in das mkgmap-Verzeichnis "examples/styles/default". Im OSM Wiki ist mkgmap recht umfassend dokumentiert.

In der points Datei steht z.B.

amenity=parking␣[0x2f0b␣resolution␣24␣default_name␣'Parking']

Wenn ich das ändere auf

amenity=parking␣[0x2f0b␣resolution␣24␣default_name␣'Parken']

Wird dann in der gesamten Karte Parken statt Parking verwendet? Also ist das sozusagen die Übersetzungstabelle?

default_name setzt den Namen eines Objektes, wenn dieser in den OSM Daten keiner hat. Sollte bereits in den OSM Daten ein name= Tag gesetzt sein, kommt default_name nicht zur Anwendung. Bitte lies dir die Doku im Wiki zu Style-Dateien durch.

Gruß
unixasket

yow wrote:

In der points Datei steht z.B.

amenity=parking␣[0x2f0b␣resolution␣24␣default_name␣'Parking']

Wenn ich das ändere auf

amenity=parking␣[0x2f0b␣resolution␣24␣default_name␣'Parken']

Wird dann in der gesamten Karte Parken statt Parking verwendet? Also ist das sozusagen die Übersetzungstabelle?

http://wiki.openstreetmap.org/wiki/Mkgm … fault_name

Es ist weit mehr bzw. es ist nicht "die Übersetzungstabelle": Hat ein Parkplatz z.B. bereits einen Namen aus den OSM Daten, ist Deine Änderung wirkungslos. Es können in den OSM Daten an einem POI aber auch mehrere Namen vorhanden sein - im Style definierst Du, welche Namen wie berücksichtigt werden, ob ein POI überhaupt einen Namen bekommt, wie er dargestellt wird, aber welchem Zoomlevel und ob er überhaupt dargestellt wird (und das war noch nicht alles, was via Style regelbar ist). Im Bereich der Namensgebung spielt aber (nach den OSM Daten und dem Style) auch die bei der Erstellung der Karte verwendete TYP Datei hinein… Du kommst nicht an einer umfassenden Einarbeitung herum, willst Du wirklich eine Karte nach Deinen Vorstellungen.

Zu den Styles werde ich mich einlesen.

Dann möchte ich erstmal auf das Problem fehlender Umlaute zurückkommen.

Im Wiki steht zu mkgmap u.a.:

--latin1

Diese Option ermöglich die Benutzung von non-ascii Zeichen in Straßennamen.
Aktuell ist die Unterstützung hardwareabhängig.
Einige Geräte unterstützen nur ASCII Zeichen.

Mkgmap versucht, nicht darstellbare Zeichen zu konvertieren. Standardmäßig (ohne diese Option) werden die Zeichen mittels Transliteration umkodiert.

--charset=name

Verwende den angegebenen Zeichensatz.

--code-page=number

Verwende die angegebene Codepage.

Welche Parameter sind nötig um Umlaute darzustellen?

--code-page=1252
--lower-case

Macht bei keinem meiner beiden Geräte (Nüvi, Oregon) und auch nicht bei BaseCamp, MapSource oder QLandkarteGT Probleme. Es soll aber wohl Geräte geben, die z.B. bei Straßennamen nur den ersten Buchstaben und dann nur Punkte anzeigen.

Super, danke! Ich habe die Karte mit

java␣-Xmx8G␣-jar␣mkgmap.jar␣--code-page=1252␣--lower-case␣--route␣6324*.osm.pbf

neu erstellt. Damit werden Umlaute korrekt darstellt.

--add-pois-to-areas habe ich weggelassen da mir noch nicht klar ist was es bewirkt.
--gmapsupp braucht man wohl nicht wenn man die Karte mit MapSetToolKit installiert.

add-pois-to-areas wird benötigt, um für ausschließlich als Flächen gemappte Elemente (z.B. Gebäude mit amenity=restaurant) einen POI zu erzeugen, der ja nur dann auch in der POI-Suche erscheint, vorausgesetzt, man hat diesen POI in points (eigener Style) definiert.

gmapsupp erzeugt gleich die gmapsupp.img direkt für's Navi. Die wird im Kartenprogramm auf dem PC nicht benötigt/verwendet - kann außerdem nachträglich mit dem Kartenprogramm erzeugt werden.

Es ist besser, Parameter einzeln zu testen, sich vorher vielleicht in alle einzulesen, notfalls mehrmals bis man verstanden hat, was jeder einzelne bewirkt, als gleich zu viele Parameter in die Befehlszeile zu packen und zu denken, mkgmap kümmert sich schon irgendwie. 🙂

Deswegen habe ich ja einige Parameter weggelassen. 🙂

Gipfel werden in der Karte zwar angezeigt, aber über die POI-Suche in Basecamp nicht gefunden. Wenn ich allerdings "Nächstgelegene POIs suchen" wähle werden sie auch im POI-Suchfenster angezeigt. Ist

--make-poi-index
Generate␣the␣POI␣index␣(not␣yet␣useful).

der richtige Parameter um das zu beheben?

Not yet useful.

Bei "richtigen" POIs wie Gaststätten, Einkaufsmöglichkeiten, Freizeit etc. klappt's auch ohne dem Parameter. Ob was in der Suche zu finden ist und unter welcher Kategorie, entscheidet die Software bzw. der verwendete Garmin-Typ. Orte werden ja auch über die normale POI-Suche (gleiche technische Umsetzung) gefunden.

Das "not yet useful" hat mich irritiert, deshalb die Nachfrage.

Bei mir werden gar keine POIs gefunden. In der Karte werden sie angezeigt, aber der Suchindex scheint zu fehlen.

Die POIs werden normal aus den Kartendaten gelesen. Kann sein, dass dies mit funktionierendem Index schneller ginge, aber benötigt wird er nicht (oder funktioniert nicht, bei gleichem Resultat).

MapSource und BaseCamp findet definitiv die üblichen POIs (letzteres habe ich aber nicht ausgiebig getestet). Wenn du eines dieser Programme verwendest, weiß ich auch nicht weiter.

Ich verwende Basecamp in der aktuellen Version.

Wie gesagt, POIs werden in der Karte zwar angezeigt, aber über die POI-Suche nicht gefunden:

Wenn ich allerdings "Nächstgelegene POIs suchen" wähle werden sie auch im POI-Suchfenster angezeigt:

BaseCamp verhält sich, zumindest bei Gipfeln, etwas komisch. Wenn natural=peak auf der 0x6616 liegt (mkgmap-Pfad\examples\styles\default\points), kann man das Verhalten wohl nicht ändern. Suche doch mal Restaurants, dann sollte es klappen. Eben auch ohne diesem POI-Index.

In der points Datei steht

natural=peak␣{name␣'${name|def:}${ele|height:m=>ft|def:}'␣}␣[0x6616␣resolution␣24]

Die Suche nach Restaurant funktioniert.

Hat QLandkarte GT auch diese Schwierigkeiten?

Also funktioniert es ohne Index und die Software macht sich doof. 🙂

QLandkarteGT sucht und findet keine POIs, jedenfall meine Linuxversion. (zeigt aber dafür wirklich alle vorhandenen Elemente an und sogar die verwendete ID und zusätzlich die Standardbezeichnung, ideal zum Testen)

Schade! Mal sehen wie ich das mit den Gipfeln lösen kann. unixasket hat dazu schon etwas geschrieben. Garmin-Hexcodes. Das schaue ich mir in Ruhe an.