Aber verstehen tue ich das nicht, diese attribute gehören in die rule road_class=3 road_speed=6
aber toll=yes gehört in den action block, schon komisch. Aber egal, hauptsache es geht.
toll=yes ist ein ganz normales Tag was auch in OSM dafür verwendet wird, um Mautstraßen zu kennzeichnen. Das wird von mkgmap mit ausgewertet. Das hat zur Folge, dass du zuerst alle nicht benötigten toll=yes löschen musst. Sonst schließt du die Straßen auch über deinen Schalter von dem Routing aus.
Das ist in meinen Augen eine Unsauberkait, die sich in der historischen Entwicklung von mkgmap immer mehr eingeschlichen hat.
Anfangs beschraenkten sich die Moeglcihkeiten bei der Garmin-Karten-Erzeugung darauf, dass man untershciedliche Objekte bei verschiedenen Aufloesungen anzeigen konnte, z.B.: [0x02 resolution 16]
Nach und nach ist das Garmin-Kartenformat immer besser verstanden worden und entsprechend immer mehr Erweiterungen sind in mkgmap eingebaut worden. Z.T. ist das ordentlich gelaufen, wie z.B. bei road_class und road_speed, die ueber die Auswertung des Styles gesetzt werden.
Eine ganze Menge von Erweiterungen ist aber auch so in mkgmap eingebaut worden, dass sie nicht durch die Style-Auswertung ausgeloest werden sondern fest auf die Tags in den OSM-Quellen gucken. Das betrifft z.B. die Auswertungen der access-Tags, des surface-Tags, und halt eben auch des toll-Tags.
Ich sehe das als sehr suboptimal an, bin aber leide rnicht in der Lage das selber zu veraendern. Also nutze ich jede sich bietende Gelegenheit, mich darueber zu beschweren, vielleicht baut dann ja jemand mal mkgmap entsprechend um
Die access tags, etc. sind alle bestens gelöst. Wer zu blöd ist dies mit ein paar Zeilen Code im Style zu adaptieren, hat halt Pech gehabt. Es ist eher andersrum, es fehlen noch immer Möglichkeiten. Etwa Rules wie "incline>10 & highway=* {set roadclass=-1 set roadspeed=-1}
…
Um mit generellen Regeln darauffolgende Regeln zu beinflussen.
Zum auflösen der Regel sollte dann "incline>10 & highway=* {set roadclass=+1 set roadspeed=+1} gegeben werden. Denn genau roadclass und roadspeed sind zurzeit nur direkt einstellbar, und nicht über Regeln wie dies bei den access Tags geht.
Hier kann man ja einfach
bicycle=no {set bicycle=xxx} setzen, und somit wird etwa bicycle=no nicht mehr beachtet. Das ist superfein gelöst. Will man es dagegen für einzelne Regeln wieder beachten, setzt man entweder highway=abcd & bicycle=xxx {set bicycle=no} […] oder setzt es wieder komplett zurück durch bicycle=xxx {set bicycle=no}
Ja klar geht es, aber es ist unnoetig kompliziert => die styles werden ebenfalls komplizierter und damit fehleranfaelliger.
Und as schlimmste dabei ist: Als style-Ersteller weiss man nicht, welche Automatismen bei mkgmap im Hintergrund lauern. Denn all diese (in meinen Augen gepfuschten) Erweiterungen haben bisher keinen Einzug in die Dokumentation gefunden.
Folge davon ist dann auch noch, dass man je nach verwendeter mkgmap-Version bei gleichem Style und gleichen OSM-Daten ein anderes Routing-Ergebniss bekommt.
Als unter einer ordentlichen Implementierung verstehe ich was anderes.
Mal nebenbei gefragt, wo wir gerade bei nicht verstandenen Automatismen von mkgmap sind:
Was macht eigentlich die ignore-maxspeed-Option?
In meinem Style habe ich ja Anweisungen wie
highway=abc & condition=xyz [0x02 road_class=3 road_speed=6 resolution 16]
Was aendert sich nun, wenn ich oben genannte Option nutze oder nicht?
maxspeed overrides road_speed if set. Ganz einfach. Ignore, ignores maxspeed.
Und seit dem die “style-branch” gemerged ist (ich glaube so um rev 1450), ist das verhalten absolut vorhersebar und easy. Vorher ja, da war es superkompliziert und trial and error was passierte. Und die Dokumentation ist zwar an verschiedenen Plätzen, aber mehr oder weniger komplett.
