[mkgmap-dev] mergeroads branch

Mon Sep 16 07:07:00 BST 2013

well only implement if you see it really needed. I don't think it's that 
important and the same result can be achieved with little more code.
More important is the rule to treat any rule by order, and if two rules 
are given in the same command, go from unspecific to specific 
(mkgmap:foot overrules mkgmap:access in same command).

It is however important that the rule order - if given in several 
commands is executed in order, or directly. E.g.
based on some tags one might disallow a certain kind of transport - 
let's say:
tracktype=grade5 {add mkgmap:bicycle=no}
however later on you check for
highway=* & route=bicycle {mkgmap:access=yes}

if your map only addresses cyclist, you clearly want that the routing 
uses this way, even though it could be in very bad condition - because 
it is part of a route, and probably there is no better alternative 
nearby - or the actual more common problem - some tags are simply plain 
wrong - and you therefore want to change it. Later rules should always 
overwrite earlier rules - no matter what. (that's also the only 
possibility to make two oneway ways which have each direction different 
class/speed - out of a single way).
On 15.09.2013 19:44, WanMil wrote:
> 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
>>
>