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.
Ne…da hab ich das ja umgesetzt 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.
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}’;}}
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.
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.
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.
Solche Listen fasse ich gerne per Hilfsvariable zusammen. Ich persoenlich finde das uebersichtlicher, vorallem wenn die Listen haeufiger im Style vorkommen:
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.
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”
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:
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.)
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.
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.
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.)
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:
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.
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.
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.
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.
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.
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.
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.