[mkgmap-dev] mergeroads branch

Fri Oct 4 02:47:44 BST 2013

On 03.10.2013 20:50, WanMil wrote:
>> 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.
>
> Hi Felix,
>
> first start with the easiest thing:
> I think the setdifferent action is superfluous.
> You could easily change your rules to
> > 2.1
> > bicycle=no {set mkgmap:bicycle='no' }
> > foot=no {set mkgmap:foot='no' }
> >
> > -- 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=no {add mkgmap:bicycle='no' }
> > foot=no {add mkgmap:foot='no' }
> >
> > -- result: mkgmap:foot=no; mkgmap:bicycle=UNSET
>
> Regarding that in the branch only the value 'no' matters:
> Would it help if I add an option "nonaccessvalues" where you can 
> define which values are read as "no access"?
> So to have the same behaviour as the trunk you would set the option 
> --nonaccessvalues=no,private
yes - that would help and simplify a lot.
>
> Anyhow I haven't fully understood why you couldn't add rules to the 
> start of your style:
> access=private { set mkgmap:access='no' }
> bicycle=private { set mkgmap:bike='no' }
> ...
> So you still have access to the original values and you have set the 
> access flag to 'no'.
the problem is that other rules "further down the lines" file check on 
whether mgmap:access=no is set or not set. Currently with private not 
being no, I would need to check on both private and no, which makes the 
style-file longer/more complicated. The main problem arises due to 
access=private being set wrong in OSM in at least 50% of its use cases 
(my guess).

Signs like the German "Privatstraße - Zufahrt verboten" (Private Road, 
Drive in no allowed) are tagged as access=private, while they should 
actually be vehicle or motor_vehicle=private. Also people interprete the 
simple sign "Privatstraße (Private Road)" as access=private - even if 
access is allowed, because they confuse ownership with access rights.

In other cases there might actually be bicycle=no signs, but in reality 
no-one cares because they are not executed, and so on... So just 
translating what is in OSM to mkgmap:access doesn't work. On the other 
hand we also need to make sure that physical hinderance (e.g. tracktype, 
sac_scale, mtb:scale, and so on) are translated into mkgmap:access.

So yes - having a table which keys are read as no, would be great. Then 
one could also set mkgmap:access=impossible (in order to separate it 
from "not allowed") for checks, and in the end end up with both being 
unroutable.
>
>
> WanMil