access=no on a cycleway doesn't work?
Hello, I am not subscribed to the list but I read an interesting message by Marko Mäkelä in the archive which I quote here: --------------------
In my neighbourhood there's a highway=cycleway that is currently blocked due to construction works. As the cycleway is still there (the cycleway itself is not under construction), I tagged it access=no. However, mkgmap still tries to route me over it. Is that because styles file saying: "highway=cycleway {add access = no; add bicycle = yes;" ? Or just use the "native" tags, but explicitly translate "access" to the vehicle-class tags and do not treat "access" specially in the core, e.g., access=no { add bicycle=no; add foot=no; add motorcar=no; add taxi=no; ... }
I do not know how mkgmap internally works, but I think that "access" should not even belong to the core! As far as I know Garmin maps only handle a fixed number of vehicle classes (e.g. motorcar, taxi, bicycle, etc.), not a general purpose catch-all vehicle class. Therefore the style file should say: access = no {add motorcar = no; add taxi = no; add bicycle = no; ...} highway = cycleway {add motorcar=no; add taxi=no; add bicycle = yes; ...} This way, a standard highway=cycleway with no additional tags would get bicycle=yes (and everything else = no); a highway=cycleway with access=no would get bicycle = no (and also everything else = no) Bye, Federico
0> In article <7b06bd660910301407g284eeea4ibe39f3b60b26835b@mail.gmail.com>, 0> Federico Cozzi <URL:mailto:f.cozzi@gmail.com> ("Federico") wrote: Federico> access = no {add motorcar = no; add taxi = no; add bicycle = Federico> no; ...} Or possibly /-------- | access=* { add vehicle='${access}'; add foot='${access}' } | vehicle=* { add motor_vehicle='${access}'; add bicycle='${access}' } \-------- and so on?
0> In article <7b06bd660910301407g284eeea4ibe39f3b60b26835b@mail.gmail.com>, 0> Federico Cozzi <URL:mailto:f.cozzi@gmail.com> ("Federico") wrote: Federico> access = no {add motorcar = no; add taxi = no; add bicycle = Federico> no; ...} 0> In article <87iqdfqwpx.fsf@balti.ashgrove>, 0> Toby Speight <URL:mailto:T.M.Speight.90@cantab.net> ("Toby") wrote: Toby> Or possibly Toby> Toby> /-------- Toby> | access=* { add vehicle='${access}'; add foot='${access}' } Toby> | vehicle=* { add motor_vehicle='${access}'; add bicycle='${access}' } Toby> \-------- Toby> Toby> and so on? Oops; that should read /-------- | access=* { add vehicle='${access}'; add foot='${access}' } | vehicle=* { add motor_vehicle='${vehicle}'; add bicycle='${vehicle}' } \--------
2009/11/13 Toby Speight <T.M.Speight.90@cantab.net>
Oops; that should read
/-------- | access=* { add vehicle='${access}'; add foot='${access}' } | vehicle=* { add motor_vehicle='${vehicle}'; add bicycle='${vehicle}' } \--------
Looks good, this would enable us to correctly map general access restrictions (access=*) and vehicle-group access restrictions (vehicle=*, motor_vehicle=*) to the access categories garmin uses. :-) -Martin
I've had a look at assigning access values and now have the following at the head of my lines file: /-------- | # Don't route over unsuitable roads | smoothness=horrible | smoothness=very_horrible | smoothness=impassable | { set motorcar=no; set hgv=no; set bicycle=no; } | smoothness=very_bad | { set motorcar=no; set hgv=no; } | | # Highway access rules | highway=bridleway {add access = no; add bicycle = yes; add horse=yes; add foot = yes} | highway=cycleway {add access = no; add bicycle = yes; add foot = yes} | highway=footway {add access = no; add foot = yes} | highway=motorway {add oneway = yes; add bicycle = no; add horse=no; add foot = no } | highway=motorway_link {add bicycle = no; add horse=no; add foot = no } | highway=path {add access = no; add bicycle = yes; add foot = yes} | highway=track {add access = no; add bicycle = yes; add horse=yes; add foot = yes} | highway=pedestrian & area!=yes {add access = no; add foot = yes} | highway=steps {add access = no; add foot = yes} | | bicycle=dismount { set bicycle = 'yes'; set maxspeed = '5' } | | # General access rules | access=* { add foot='${access}'; add horse='${access}'; add vehicle='${access}'; } | vehicle=* { add bicycle='${vehicle}'; add motor_vehicle='${vehicle}'; } | motor_vehicle=* { add motorcycle='${motor_vehicle}'; add motorcar='${motor_vehicle}'; | add psv='${motor_vehicle}'; add hgv='${motor_vehicle}'; add goods='${motor_vehicle}'; | add taxi='${motor_vehicle}'; } \-------- Should this be added to the default style? If so, could a volunteer please commit it? Thanks.
Toby Speight wrote:
I've had a look at assigning access values and now have the following at the head of my lines file:
/-------- | # Don't route over unsuitable roads | smoothness=horrible | smoothness=very_horrible | smoothness=impassable | { set motorcar=no; set hgv=no; set bicycle=no; } | smoothness=very_bad | { set motorcar=no; set hgv=no; } | | # Highway access rules | highway=bridleway {add access = no; add bicycle = yes; add horse=yes; add foot = yes} | highway=cycleway {add access = no; add bicycle = yes; add foot = yes} | highway=footway {add access = no; add foot = yes} | highway=motorway {add oneway = yes; add bicycle = no; add horse=no; add foot = no } | highway=motorway_link {add bicycle = no; add horse=no; add foot = no } | highway=path {add access = no; add bicycle = yes; add foot = yes} | highway=track {add access = no; add bicycle = yes; add horse=yes; add foot = yes} | highway=pedestrian & area!=yes {add access = no; add foot = yes} | highway=steps {add access = no; add foot = yes} | | bicycle=dismount { set bicycle = 'yes'; set maxspeed = '5' } | | # General access rules | access=* { add foot='${access}'; add horse='${access}'; add vehicle='${access}'; } | vehicle=* { add bicycle='${vehicle}'; add motor_vehicle='${vehicle}'; } | motor_vehicle=* { add motorcycle='${motor_vehicle}'; add motorcar='${motor_vehicle}'; | add psv='${motor_vehicle}'; add hgv='${motor_vehicle}'; add goods='${motor_vehicle}'; | add taxi='${motor_vehicle}'; } \--------
Should this be added to the default style? If so, could a volunteer please commit it? Thanks. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
No IMHO it shouldn't. Why? Because unconditional rules will not work as you expect! If one rule matches, all other unconditional are dropped for the line. So forget about it - or make so many combinations that it has to match. You will then however quickly arrive at over 1000 rules, just for a few tags.
0> In article <4B0AD385.8030305@gmail.com>, 0> Felix Hartmann <URL:mailto:extremecarver@googlemail.com> ("Felix") wrote: Felix> Toby Speight wrote:
I've had a look at assigning access values and now have the following at the head of my lines file:
/-------- | # Don't route over unsuitable roads | smoothness=horrible | smoothness=very_horrible | smoothness=impassable | { set motorcar=no; set hgv=no; set bicycle=no; } | smoothness=very_bad | { set motorcar=no; set hgv=no; } | | # Highway access rules | highway=bridleway {add access = no; add bicycle = yes; add horse=yes; add foot = yes} | highway=cycleway {add access = no; add bicycle = yes; add foot = yes} | highway=footway {add access = no; add foot = yes} | highway=motorway {add oneway = yes; add bicycle = no; add horse=no; add foot = no } | highway=motorway_link {add bicycle = no; add horse=no; add foot = no } | highway=path {add access = no; add bicycle = yes; add foot = yes} | highway=track {add access = no; add bicycle = yes; add horse=yes; add foot = yes} | highway=pedestrian & area!=yes {add access = no; add foot = yes} | highway=steps {add access = no; add foot = yes} | | bicycle=dismount { set bicycle = 'yes'; set maxspeed = '5' } | | # General access rules | access=* { add foot='${access}'; add horse='${access}'; add vehicle='${access}'; } | vehicle=* { add bicycle='${vehicle}'; add motor_vehicle='${vehicle}'; } | motor_vehicle=* { add motorcycle='${motor_vehicle}'; add motorcar='${motor_vehicle}'; | add psv='${motor_vehicle}'; add hgv='${motor_vehicle}'; add goods='${motor_vehicle}'; | add taxi='${motor_vehicle}'; } \--------
Should this be added to the default style?
Felix> No IMHO it shouldn't. Why? Because unconditional rules will not Felix> work as you expect! Felix> Felix> If one rule matches, all other unconditional are dropped for the Felix> line. So forget about it - or make so many combinations that it Felix> has to match. You will then however quickly arrive at over 1000 Felix> rules, just for a few tags. I'm sorry - I don't understand what you mean by this. What do you mean by "If one rule matches, all other unconditional are dropped for the line"? Can you give an example of a situation where the rules don't have the desired effect? Maybe there's something I can do to improve them, or to improve mkgmap - or even to create a separate preprocessor, if necessary.
Toby Speight wrote:
0> In article <4B0AD385.8030305@gmail.com>, 0> Felix Hartmann <URL:mailto:extremecarver@googlemail.com> ("Felix") wrote:
Felix> Toby Speight wrote:
I've had a look at assigning access values and now have the following at the head of my lines file:
/-------- | # Don't route over unsuitable roads | smoothness=horrible | smoothness=very_horrible | smoothness=impassable | { set motorcar=no; set hgv=no; set bicycle=no; } | smoothness=very_bad | { set motorcar=no; set hgv=no; } | | # Highway access rules | highway=bridleway {add access = no; add bicycle = yes; add horse=yes; add foot = yes} | highway=cycleway {add access = no; add bicycle = yes; add foot = yes} | highway=footway {add access = no; add foot = yes} | highway=motorway {add oneway = yes; add bicycle = no; add horse=no; add foot = no } | highway=motorway_link {add bicycle = no; add horse=no; add foot = no } | highway=path {add access = no; add bicycle = yes; add foot = yes} | highway=track {add access = no; add bicycle = yes; add horse=yes; add foot = yes} | highway=pedestrian & area!=yes {add access = no; add foot = yes} | highway=steps {add access = no; add foot = yes} | | bicycle=dismount { set bicycle = 'yes'; set maxspeed = '5' } | | # General access rules | access=* { add foot='${access}'; add horse='${access}'; add vehicle='${access}'; } | vehicle=* { add bicycle='${vehicle}'; add motor_vehicle='${vehicle}'; } | motor_vehicle=* { add motorcycle='${motor_vehicle}'; add motorcar='${motor_vehicle}'; | add psv='${motor_vehicle}'; add hgv='${motor_vehicle}'; add goods='${motor_vehicle}'; | add taxi='${motor_vehicle}'; } \--------
Should this be added to the default style?
Felix> No IMHO it shouldn't. Why? Because unconditional rules will not Felix> work as you expect! Felix> Felix> If one rule matches, all other unconditional are dropped for the Felix> line. So forget about it - or make so many combinations that it Felix> has to match. You will then however quickly arrive at over 1000 Felix> rules, just for a few tags.
I'm sorry - I don't understand what you mean by this. What do you mean by "If one rule matches, all other unconditional are dropped for the line"? Can you give an example of a situation where the rules don't have the desired effect? Maybe there's something I can do to improve them, or to improve mkgmap - or even to create a separate preprocessor, if necessary.
If there is a footway with smoothness=very_bad Only one of the above rules will be enacted. If you want that both happens, you have to put a rule: smoothness=very_bad & highway=footway {add access = no; add foot = yes,......} As the first rule matches, no other unconditional rule will be enacted on a way/line. Only a condition [0x*...] rule will match again. Rules with more conditions prevail however over rules with fewer conditions. so smoothness=very_bad & highway=footway smoothness=very_bad highway=footway no matter in which order they are placed, the rule including both will be chosen
________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
0> In article <4B0B98CF.9070208@gmail.com>, 0> Felix Hartmann <URL:mailto:extremecarver@googlemail.com> ("Felix") wrote: Felix> If there is a footway with smoothness=very_bad Felix> Felix> Only one of the above rules will be enacted. Felix> Felix> If you want that both happens, you have to put a rule: Felix> Felix> smoothness=very_bad & highway=footway {add access = no; add foot = yes,......} Felix> Felix> Felix> As the first rule matches, no other unconditional rule will be enacted Felix> on a way/line. Only a condition [0x*...] rule will match again. Ah, I understand now. Thanks for explaining it for me. That's a bit of a nuisance, really. ;-( 0> In article <4B0BF8F4.20307@gmx.de>, 0> Torsten Leistikow <URL:mailto:de_muur@gmx.de> ("Torsten") wrote: Torsten> You could take a look at the style-branch, which deals with Torsten> this problem. Unfortunatly this branch does not solve the Torsten> problem completely and there isn't much work in progress on Torsten> this topic at the moment. That's certainly interesting to me. I don't suppose there's a wiki page that documents what problems it's trying to solve, and what approach is taken? If not, I'm willing to start one, with my own ideas, and ask for corrections.
Toby Speight wrote:
0> In article <4B0B98CF.9070208@gmail.com>, 0> Felix Hartmann <URL:mailto:extremecarver@googlemail.com> ("Felix") wrote:
Felix> If there is a footway with smoothness=very_bad Felix> Felix> Only one of the above rules will be enacted. Felix> Felix> If you want that both happens, you have to put a rule: Felix> Felix> smoothness=very_bad & highway=footway {add access = no; add foot = yes,......} Felix> Felix> Felix> As the first rule matches, no other unconditional rule will be enacted Felix> on a way/line. Only a condition [0x*...] rule will match again.
Ah, I understand now. Thanks for explaining it for me.
That's a bit of a nuisance, really. ;-(
0> In article <4B0BF8F4.20307@gmx.de>, 0> Torsten Leistikow <URL:mailto:de_muur@gmx.de> ("Torsten") wrote:
Torsten> You could take a look at the style-branch, which deals with Torsten> this problem. Unfortunatly this branch does not solve the Torsten> problem completely and there isn't much work in progress on Torsten> this topic at the moment.
That's certainly interesting to me. I don't suppose there's a wiki page that documents what problems it's trying to solve, and what approach is taken? If not, I'm willing to start one, with my own ideas, and ask for corrections.
Besides having bugs, the style branch has the approach that only the first rule is matched. So you could write rules from more restrictive to less restrictive. Ideas about how it (from the principle, not the code) had been inside the discussions about the style-branch. Look into the e-mail archives for it. I must say that I prefer the current approach over the style-branch approach, though both will not help you to create millions of lines if you want to have several keys matched. But at least can leave your rules in thematically correct orders, instead of needing to split the rules for order (making it very very hard to copy/paste/create_with_spreadsheet the rules. Ideal in my eyes would be several passes. So you classify run 1, run 2, run x and each subsequent run will match all lines as if no rule had matched yet - but also prefer to have no need for ordering but inside on run go from specific to unspecific.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Felix Hartmann schrieb am 24.11.2009 19:36:
Besides having bugs, the style branch has the approach that only the first rule is matched. So you could write rules from more restrictive to less restrictive.
No, that's not true. The style branch does perfom all matching rules, with the first rule aplied first. But sadly it is not working 100%, when the first rule does change some tags, that the second rule will be matched against the changed values. E.g. you have an element with the tag highway=example and the two rules A) highway=example {add second_tag=set} B) highway=example & second_tag=set {...} than both rules will be applied to the element (first rule A and afterwards rule B). In another example you have again an element with the tag highway=example and the two rules A) highway=example {set highway=deleted} B) highway=example {...} than again both rules will be applied to the element. Based on my experience this is the way the style branch is working right now. I woul welcome any improvement, that in the second case only rule A will be applied. Gruss Torsten
Toby Speight schrieb am 24.11.2009 04:15:
Maybe there's something I can do to improve them, or to improve mkgmap - or even to create a separate preprocessor, if necessary.
You could take a look at the style-branch, which deals with this problem. Unfortunatly this branch does not solve the problem completely and there isn't much work in progress on this topic at the moment. Gruss Torsten
participants (5)
-
Federico Cozzi -
Felix Hartmann -
Martin Simon -
Toby Speight -
Torsten Leistikow