[mkgmap-dev] Simplify setting access tags in the mergeroads branch

Mon Oct 7 12:10:12 BST 2013

On 07.10.2013 12:50, WanMil wrote:
>>
>> On 06.10.2013 20:06, WanMil wrote:
>>> Hi all,
>>>
>>> I am still thinking about how to simplify setting the access tags in 
>>> the
>>> mergeroads branch.
>>>
>>> Felix posted his concerns that the new handling requires much more 
>>> style
>>> coding.
>>>
>>> At the moment my favourite changes are to add two more actions:
>>> 1. addaccess:
>>> This adds the given value to all access fields (only if they are not
>>> already set)
>>> 2. setaccess:
>>> This sets the given value to all access fields (only if they are not
>>> already set)
>> what is the difference between 1 and 2???
>> I suppose you mean 2. .... ( no matter if they are already set or not).
>
> Uuups, c&p error. You are right.
>
>> I definitely need a set even if they are already set command. That's the
>> way it has always been working. If you don't want this, then maybe we
>> need a setifnotyetsetaccess and setinanycaseaccess action.
>>
>> Actually what you propose is just a change in notation, but not a change
>> in how mkgmap is working. 1. would be identical to add mkgmap:access and
>> 2 (according to my interpretation) is identical to set mkgmap:access....
>>
>>
>> I would still favour a separate list into which one can add which values
>> of mkgmap:access (or whatever it's called) to be treated as no (for me
>> private, no and a third set via style-file would be useful). Besides the
>> examples are in line what they were supposed to do. I don't really mind
>> what notation is used. so addaccess and setaccess vs add mkgmap:access
>> and set mkgmap:access doesn't matter to me.
>>>
>>> The mkgmap:access tag will no longer be evaluated.
>>> @Felix: I don't want to add an option so that you can set which values
>>> are evaluated as no. I am not convinced that it is required. If you are
>>> unhappy please post a reasonable example where it is really required 
>>> and
>>> feel free to add a patch yourself.
>>>
>>> =====================
>>>
>>> Examples:
>>> highway=track, tracktype=grade2, access=no, bicycle=yes, foot=private
>>>
>>> highway=track & tracktype ~ 'grade[2-5]' { setaccess no; set
>>> mkgmap:bike=yes; set mkgmap:foot=yes; }
>>> => Result: access only for bike and foot
>> Two questions/clarification cases...
>>
>> highway=track & tracktype ~ 'grade[2-5]' { set
>> mkgmap:bike=yes; set mkgmap:foot=yes; setaccess no }
>> => Result: access only for bike and foot
>>
>> Will this be the result as well, or will bike and foot be overruled 
>> because setaccess no is stated later in the same command?
>
> bike and foot will be overruled.
okay, I think this should be mentioned somewhere. So far I think there 
is no note anywhere about order importance of conflicting commands 
within one set of {} brackets. It's perfectly fine, just should be 
documented I think.

I will write an example why I think other values than no are needed 
later (probably in two days)...
>
>>
>> highway=track & tracktype ~ 'grade[2-5]' { set
>> mkgmap:bike=yes; set mkgmap:foot=yes }
>> highway=track & tracktype ~ 'grade[2-5]' { setaccess no}
>>
>>    I hope for => Result: no access, setaccess no overwrites earlier 
>> given commands (earlier line in the style-file).
>
> Result: no access, setaccess overwrites (otherwise you have to use 
> addaccess)
>
>>
>>> highway=* & foot=private { set mkgmap:foot=yes }
>>> highway=* & tracktype=grade2 { addaccess no }
>>> => Result: access for foot only (addaccess sets the mkgmap:foot value
>>> only if not already set)
>>>
>>> (bicycle=yes| bicycle=private ) { set mkgmap:bike=yes }
>>> (foot=yes | foot=private) { set mkgmap:foot=yes }
>>> access=* ( addaccess '${access}' }
>>> => Result: no access for all types except bike and foot
>>>
>>> I think its clear now, how it works.
>>>
>>> =====================
>>>
>>> The following flags will be set by addaccess and setaccess.
>>> mkgmap:bike
>>> mkgmap:foot
>>> mkgmap:truck
>>> mkgmap:car
>>> mkgmap:bus
>>> mkgmap:taxi
>>> mkgmap:emergency
>>> mkgmap:delivery
>>> mkgmap:throughroute
>>>
>>> I am not sure if it also makes sense to set the mkgmap:carpool flag.
>>> mkgmap:carpool is handled special: if it is set to 'yes' all access 
>>> tags
>>> are set to no except carpool, emergency and bus. This copies the
>>> behaviour from trunk but I don't know if we should keept this?
>>>
>>> What is your opinion about the two new actions? Do they help? Are they
>>> sufficient? Are any other actions required?
>>>
>>> WanMil
>>> _______________________________________________
>>> mkgmap-dev mailing list
>>> mkgmap-dev at lists.mkgmap.org.uk
>>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>> _______________________________________________
>> mkgmap-dev mailing list
>> mkgmap-dev at lists.mkgmap.org.uk
>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>