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

Mon Oct 7 11:50:11 BST 2013

>
> 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.

>
> 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
>