mkgmap-Regeln

Hallo!
Ich hab mal ein paar Fragen bzgl. Regeln für mkgmap-Styles.

  • bei highway=track|path surface=paved setzen, wenn dieser surface=asphalt|concrete|… enthält
  • einen bestimmten Tag löschen
  • sowie Wege, die einer Relation mit type=bicycle und network=rcn angehören einen bestimmten Tagg verpassen und diesen dann mit einem Overlay hinterlegen.

Könnt ihr mir da evtl. weiter helfen?

Willst Du das mit Composer umsetzen?

Viele Grüße
tippeltappel

Ne…da hab ich das ja umgesetzt :wink: Aber wie schon in composer-Thread geschrieben ist mir das Erstellen der Karte zu ressourcenhungrig (HDD und RAM). Ich hab einfach mal die Karte direkt von splitter.jar und mkgmap erstellen lassen und war angenehm überrascht. Weitere Vorteile sind das bessere Routing (Kachelgrenzen), die Unterstützung von Relationen und eine größere Unterstützung seitens der Programmierer (Zusammenspiel splitter <-> mkgmap). Der größte Nachteil des Composers ist mMm die Konturdichtenanalyse, die bei einem größeren Gebiet schonmal Stunden dauern kann.

Bisher bin ich beim Composer geblieben, da die Integration der Höhenlinien ganz einfach ist. Mittlerweile finde ich aber seperate Höhenlinien besser, da ausschaltbar und nicht Kartengebunden. Außerdem war das Erstellen und pflegen des Styles sehr angenehm und das werde ich wohl weiterhin mit dem Composer machen.

Der Composer regelt aber die Ersetzungen intern und nicht über die mkgmap-Stylefiles, sodass ich diese nun transformieren muss.

Verstehe.

Hast Du Dich schon im Naviboard http://www.naviboard.de/vb/forumdisplay.php?f=84
oder bei den Naviusern http://www.naviuser.at/forum/forumdisplay.php?f=35
umgehört? Da sind Leute unterwegs, die sich mit mkgmap gut auskennen.

Viele Grüße
tippeltappel

Ich bin nun erstmal im wiki fündig geworden:
http://wiki.openstreetmap.org/wiki/Mkgmap/help/style_rules

Mal schauen, wie weit ich damit komme.

highway=* & surface=asphalt {set surface=paved}

highway=* {set surface=“”}

Wenn die Werte nur fuer die weitere Auswertung geloescht werden sollen (wie z.B. das surface-Tag) und nicht direkt aus der Anzeige (z.B. das Name-Tag), dann verbiege ich die Werte eigentlich lieber: set surface=deleted. Dann kann man spaeter immer noch unterscheiden, ob die Tags nie gesetzt waren, oder ob sie von mir geloescht worden sind.

Fuer das Overlay musst du eine eigene, transparent Karte bauen, die du dann in einem zweiten Schritt mit der eiegntlichen Karte mit mkgmap in eine gemeinsame gmapsupp.img packst.

In dieser Extrakarte brauchst du dann in der relations-Datei sowas wie

type=route & route=bicycle & network=rcn { apply { set mkgmap_rcn_bicycle_route=yes; set mkgmap_rcn_bicycle_route_name=‘${name}’;}}

und in der lines-Datei dazu dann noch

highway=* & mkgmap_rcn_bicycle_route=yes {name ‘${mkgmap_rcn_bicycle_route_name}’} [0x05 resolution 20 continue]

Gruss
Torsten

Hallo Torsten,
vielen Dank für deine Hinweise.
Gibt es auch eine Möglichkeit zu überprüfen, ob ein Key vorhanden ist bzw. ob er fehlt?

Hier mal ein Bsp.:

highway=cycleway !& bicycle=* {set highway=path & add bicylce=yes}
highway=cycleway {set highway=path}

Geht sowas und wie wäre die richtige Syntax?

Wie schaut es aus, wenn ich eine Liste von values habe. Kann ich die alle mit einmal angeben, oder muss ich für jedes Element der Liste eine Ersetzung schreiben.

Hallo Henning,

die Position des Ausrufezeichens ist wichtig.

Ob der Key (mit beliebigem Inhalt) vorhanden ist, testet man mit

… & bicycle=*

oder ob er gar nicht vorhanden ist:

… & bicycle!=*

oder ob er vorhanden ist aber nicht “yes” enthält (also jeden beliebigen anderen Wert inne hat):

… & bicycle!=yes

Noch nicht vorhandene Tags werden mit {add …} hinzugefügt, vorhandene mit {set …} geändert. Mehrere gleichzeitig lassen sich ergänzen/ändern, die Tags/Values werden dabei mit Semikolon getrennt:

… {set highway = path; set bicycle = yes; add…}

Am Besten, Du gibst mal ein ganz konkretes Beispiel, was wie getaggt ist und wie es geändert werden soll. Logische Verknüpfungen (mathematisch betrachtet) sind Konstrukte mit für Ungeübte manchmal recht erstaunlichen Ergebnissen.

Grüße
Mario

Hallo Mario!
danke für deine Hilfe!

Obige Ersetzung soll die cycleways in path umtaggen. Wenn der cycleway bereits ein bicycle-Tag hat, soll es erhalten bleiben, ansonsten soll bicycle=yes gesetzt werden.

Ein Bsp. für eine Liste wäre:

Wenn oneway=yes und cycleway=opposite|opposite_lane|opposite_track dann soll oneway gelöscht werden.

Dann ist der obige Ansatz schon richtig (nur die NOT-Bedingung steht an der falschen Stelle). Mittels Kombination von AND/OR lässt sich eventuell einiges optimieren.

Würde ich folgendermaßen machen:

(highway=path | highway=cycleway) & (cycleway=opposite | cycleway=opposite_lane | cycleway=opposite_track) {add oneway=no}

Man beachte auch die runden Klammern, sonst gilt UND vor ODER.

Vielen Dank, ich glaub, nun sind mir die Logik-Formatierungen von mkgmap klar.

Solche Listen fasse ich gerne per Hilfsvariable zusammen. Ich persoenlich finde das uebersichtlicher, vorallem wenn die Listen haeufiger im Style vorkommen:

highway=* & cycleway=opposite {set mkgmap_opposite_cycling_allowed=yes}
highway=* & cycleway=opposite_lane {set mkgmap_opposite_cycling_allowed=yes}
highway=* & cycleway=opposite_track {set mkgmap_opposite_cycling_allowed=yes}

und spaeter dann die Abfrage

conditionXYZ=true & mkgmap_opposite_cycling_allowed=yes …

Ausserdem bevoruge ich grundsaetzlich das set-Kommando gegenueber dem add-Kommando, ich finde es einfach klarer in der Anwendung. Im obigen Beispiel von Garmin-User wird das add meines Wissens nach naemlich nur ausgefuehrt, wenn an dem entsprechenden Weg noch kein oneway-Tag gesetzt ist. Ein bereits vorhandenes oneway=yes wird also nicht ueberschrieben sondern bleibt unveraendert erhalten.

Gruss
Torsten

Ich hab nochmal eine Frage zum Overlay. Ich glaub, ich hab das etwas blöd ausgedrückt. Ich will keine extra Karte, sondern will bloß die Wege hervorheben. Also bspw. sollen alle Wege mit surface=cobblestone neben dem eigentlichen Wegstück eine Markierung erhalten. Das sollte doch über diese overlays-Datei gehen. Ich hab damit auch schon etwas rumgespielt, bekomme beim testen mit --list-styles aber den Fehler angezeigt: “List of numbers expected”

lines:


highway=primary & surface=cobblestone [0x104 road_class=1 road_speed=1 resolution 16]
highway=secondary & surface=cobblestone [0x105 road_class=1 road_speed=1 resolution 18]
highway=tertiary & surface=cobblestone [0x106 road_class=1 road_speed=1 resolution 18]
highway=unclassified & surface=cobblestone [0x107 road_class=2 road_speed=4 resolution 19]
highway=minor & surface=cobblestone [0x107 road_class=2 road_speed=4 resolution 22]
highway=residential & surface=cobblestone [0x108 road_class=2 road_speed=4 resolution 20]
highway=living_street & surface=cobblestone [0x108 road_class=2 road_speed=4 resolution 22]

overlays:


0x104: 0x04, 0x1A
0x105: 0x05, 0x1A
0x106: 0x06, 0x1A
0x107: 0x07, 0x1A
0x108: 0x08, 0x1A

Keiner eine Idee?

Ich habe die Overlays nur einmal kurz ausprobiert, ansosnten benutze ich sie nicht.

Das Hervorheben von einigen Wegen realisiere ich lieber ueber einen extra Kartenlayer, das hat doch zwei entscheidende Vorteile:

  1. Bei einem extra Layer kann man die Darstellungsreihenfolge mittels drawpriority beeinflussen. Wenn man dagegen mit overlays arbeitet, ist es nicht definiert, in welcher Reihenfolge die vershciedenen Linien gezeichnet werden. (Insofern ist der Begriff OVERlay eigentlich ziemlich daneben.)

  2. Wenn man mit verschiedenen Kartenlayern arbeitet, dann kann man am Geraet je nach Bedarf auch einzelne Layer deaktivieren. Da die kleinen Displays nicht all zu uebersichtlich sind, hilft das manchmal enorm.

Einziger Nachteil vom Multi-Layer-Ansatz ist die tatsache, dass man im Mapsource imme rnur einen Layer zur Zeit sehen kann, QLandkarte soll da besser sein.

Gruss
Torsten

Hallo,
auf der mkgmap-Mailingliste hab ich den entscheidenden Tip bekommen…es hat eine Leerzeile am Ende gefehlt :frowning:

Wie macht ihr das egtl. mit dem Zeichnen von Brücken und Tunneln?
Ich hab im lines File ein bridge=yes [… continue] und dann die ganzen highways. Allerdings passt dann die Reihenfolge nicht. Also der Weg auf der Brücke wird nicht oberhalb vom anderen Weg gezeichnet.

Hi Henning,

ich zeige Brücken und Tunnel gar nicht an. Oft ist es doch so, dass sich mehrere Weg-/Straßentypen eine Brücke teilen. Je nach Zoomstufe überschneiden sich die “Geländer” oder verdecken den Nachbarweg oder werden gar selbst überdeckt.

Die einzig sichere Methode für eine definierte Darstellungsreihenfolge ist, mit einem extra Layer zu arbeiten. (Klappt natürlich nur für Markierungen, Straßen auf anderen Layern wären ja nicht routingfähig.)

Grüße
Mario

Also wertet mkgmap das layer-Tag nicht aus. Ok…dann muss es halt so bleiben…

Meine Garmin-Karten sind recht vielschichtig. Das hat zum Teil Darstellungsgruende, zum Teil ist es aber auch einfach praktischer in der Kartengenerierung oder bei der Kartenbenutzung. Von unten nach oben sehen meine Karten wie folgt aus:

  1. Suche-Schicht. Hier habe ich die POIs drin fuer dieSuchmenues der Garmin-Geraete. Da muss man ja feste Code-Nummern fuer verwenden, da finde ich es praktischer, wenn man das irgendwo im Untergrund versteckt und das nicht mit der Anzeige zusammenmischt.

  2. Routing-Schicht. Auch das Routing habe ich im Untergrund versteckt. Ein Grund ist hierfuer wieder, dass die Garmin-Geraete fuer bestimmte Ansagetexte bestimmte Code-Nummern voraussetzt (z.B. Kreisverkehr), in der Anzeige moechte ich da aber durchaus unterscheidne koennen (ein primary-Kreisverkehr soll anders aussehen als ein secondary-Kreisverkehr). Ein anderer Grudn ist, dass ich mir verschiedene Karten baue (Rennrad, Trekkingrad, Auto), die sich (quasi) nicht in der Anzeige sondern nur im Routing unterscheiden. So kann ich die meisten Schichten fuer diese Karten gleich halten, und muss nur einzelne Schichten gegeneinander austauschen.
    Fuer die verschiedenen Routing-Anwendungen verbiege ich alle Access-Tags kraeftig. Fuer das Haupt-Routing meiner Karten muss das Geraet im KFZ-Navigations-Modus betrieben werden, da nur hier die Geraete die roadclass und roadspeed Daten ordentlich auswerten. Daneben lassen sich meine Karten auch noch fuers Fussgaengerrouting gebrauchen, wenn man das Navi in den Fahrrad-Routing-Modus schaltet. Den Fussgaenger-Routing-Modus der Garmingeraete finde ich unbrauchbar.

  3. Topo-Basis-Schicht. Das ist die Hauptschicht meiner Anzeige, quasi das Level Null. Alles, was nicht in den folgenden Shcichten explizit ueber dieses Ebene gelegt wird, wird hier angezeigt. Da sind z.B. auch die Tunnel enthalten. Erst ahtte ich gedacht, diese in eine tiefere Schicht zu legen. Aber das waere ein ziemlicher Aufwand geworden und ausserdem waerens ie dann unter irgendwelchen flaehcen komplett verschwunden, also nicht mehr sichtbar gewesen. Jetzt zeichne ich sie also auf der selben Ebene wie normale Strassen, allerdings wesentlich schwaecher (nur gepunktet), so dass sie in der Karte deutlich zu unterscheiden sind.

  4. Hoehenlinien-Schicht (transparent). Die Hoehenlinien habe ich in eine eigene Schicht gepackt, da diese ja nur einmalig bestimmt werden und nciht regelmaessig wieder aktualisisert werden muessen.

  5. Topo-Overlay-Schicht (transparent). Hier habe ich die Elemente versammelt, die ich aus darstellunsggruenden ueber meienr Basisschicht ageordnet haben moechte. Das sind zum Beispiel Elemente mit bridge=yes (als Strasse plus eine zusaetzliche Markierung) oder aber auch Strassenbahnen, die ich nicht von den breiteren Linien der Strassen ueberdeckt haben moechte. Ich unterschiede also nur zwei Darstellungsebenen, wenn drei Elemente uebereinander liegen, oder aber z.B. eien Brueck ueber eine Strassenbahn fuehrt, dann ist die Anzeige nicht ganz 100%-ig. Aber solche Faelle sind doch recht selten, so dass ich gut damit leben kann.

  6. Access-Restrictions-Schicht (transparent). Hier habe ich Markierungen fuer gesperrte Wege und fuer Einbahnstrassen drin. Zum einen sollen diese Markierungen uber den betroffen Strassen angezeigt werden, zum anderen sind die Beschraenkungen aehnlich wie die Routing-Informationen abhaengig vom gewuenschten Nutzungszweck (Fahrrad anders als Auto). Das ist also die zweite Schicht, die ich nutzungsabhaengig ersetze.

  7. Wanderwege-Schicht und 8. Radwanderwege-Schicht (transparent). Die Routen der (Rad-)Wanderwege habe ich hauptsaechlich in eine extra Schicht gelegt, damit ich diese im Geraet je nach Bedarf ein oder ausschalten kann.

Gruss
Torsten