Simplify setting access tags in the mergeroads branch
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) 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 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 06.10.2013 20:06, schrieb WanMil:
What is your opinion about the two new actions? Do they help? Are they sufficient? Are any other actions required?
Hi, what about the following behavior: all access-values are by default unset. You can set a specific value with set and add to yes or no. Additional you can use mkgmap:access to set all values to yes or no. If you use add mkgmap:access=no, every value, which is unset (default) will changed to no. All values which where set ones before will stay untouched. At the very end all unset values should be handled as no. It's quite the same as your proposal, but without new special options. Henning -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (MingW32) iQEcBAEBAgAGBQJSUcPHAAoJEPFgsWC7jOeTcJAIAJGFRynOArPantO2D+1gVCr7 sFzfR9/HjnzcD57SLyrEK36jl9Bgrvm9XxJ9dClxTgbfCKbKKvCUrAIp7Zdnm5E5 jXjwKdrAxRK5EcSU0Lo9Qeb+3kIUF9eSPcGes/8z5Xw92h8juaxQrh1kbM/uzjhB RlUnI/cATHCSElNooWnTdwefyS0XC4LyLExvggFpJzJ7q2aizkh+yM552CXtC4AI +7OTcV8MbznOmBv+wjlI/+d3cqCBmHH/4s+845GPWM07A3cdkWaYv46uyvsTpEUl iMCQf8kpswJN8QGv0+9j15QP+O/ZTKodcp90+6KtEF4gYo8DGoMbzSQgNwEfhEs= =mfAn -----END PGP SIGNATURE-----
It's quite the same as your proposal, but without new special options.
Hi Henning, you're right, but that's exactly what I don't like. You propose to have a special handling for set mkgmap:access='xxx' and add mkgmap:access='xxx' I think special handlings are better documented and more intuitive by using special commands: setaccess 'xxx' and addaccess 'xxx' Of course the names setaccess and addaccess could be changed to something else if someone has a better name for it. @All other: what do you think/prefer? I don't mind implementing the set/add mkgmap:access behaviour if the list favours that variant. I am just thinking about what is the most intuitive and best explainable solution. WanMil
On Sun, Oct 06, WanMil wrote:
It's quite the same as your proposal, but without new special options.
@All other: what do you think/prefer? I don't mind implementing the set/add mkgmap:access behaviour if the list favours that variant. I am just thinking about what is the most intuitive and best explainable solution.
I don't like the add/set mkgmap:access, too, because suddenly the result is a bit operation and no longer an assigning of values. I think from the command it should be clear what will happen. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
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@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Thanks for all feedback. As described I have commited two new actions: addaccess 'value' setaccess 'value' The actions operate in the same way like the add/set operator but work on all mkgmap access tags at once. When using addaccess only those access tags are set that are uninitialized. It is possible to use the common variable references in the value part: setaccess '${access}' Have fun! WanMil
participants (4)
-
Felix Hartmann -
Henning Scholland -
Thorsten Kukuk -
WanMil