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

Mon Oct 7 10:55:02 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). 
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?

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

> 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