Well to make styles easier, maybe we could have a third command which
works like a in between add and set.
That command would only set mkgmap: tags, in case they are not default,
therefore you could later on in the style run rules with differentiation
between set explicitely by set, and other set implicitely...
Example 2. (to keep in order with the previous email).
highway=track, bicycle=yes, foot=no
2.1
bicycle=* {setdifferent mkgmap:bicycle='${bicycle}' }
foot=* {setdifferent mkgmap:foot='${foot}' }
-- result: mkgmap:foot=no; mkgmap:bicycle=UNSET
2.2.
bicycle=* {set mkgmap:bicycle='${bicycle}' }
foot=* {set mkgmap:foot='${foot}' }
-- result: mkgmap:foot=no; mkgmap:bicycle=yes
2.3
bicycle=* {adddifferent mkgmap:bicycle='${bicycle}' }
foot=* {adddifferent mkgmap:foot='${foot}' }
-- result: mkgmap:foot=no; mkgmap:bicycle=UNSET
However I'm not so sure this is really needed. My main problem when
rewriting the style was that I have different road_class or road_speed
if an access type like bicycle or motorcar or foot is private /
designated / ....
Therefore I couldn't just simply replace my old set / add commands, as
in the branch only NO matters. Everything else is effectively trashed.
Previously I knew that private would mean no, So I could write different
rules for it somewhere in the style, while still having the outcome of
private meaning no is set. Now I have to make sure that I look in rules
at the original bicycle or foot values, but write all {] content for
both bicycle and mkgmap:bicycle as example, because otherwise the result
is different than before. As private is not NO anymore, getting old
behavior meant rewriting quite a lot of lines manually instead of simple
CRTL-H exchanging. The setdiffferent idea is not really related to the
mergeroads branch it's rather something that I already in past had to
write a bit more complex rules and replicate tags to achieve the wanted
result of knowing original value of a tag, while setting it to something
new.
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
