[mkgmap-dev] mergeroads branch

Sun Sep 15 18:44:34 BST 2013

Thanks Felix,

I have to think about your proposals.

WanMil

> 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
> mkgmap-dev at lists.mkgmap.org.uk
> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>