access=no on a cycleway doesn't work?
Hi, 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;" ? If so, can I do anything about it? I can't figure out a way to handle this, but maybe I'm missing something. If the style file is the problem, I could imagine the following tags to be overwritten: access=no all by itself (would become access=no, bicycle=yes) access=no; bicycle=no (silly?) (becomes bicycle=yes) bicycle=no; (a bit odd, for a cycleway) (becomes bicycle=yes) (BTW, if the styles are the problem here, I think that more road types show this behaviour, there are lots of places where an existing "access=no" gets extended by "something=yes"). Best regards, Valentijn
On Thu, Oct 29, 2009 at 02:41:25PM +0100, Valentijn Sessink wrote:
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;" ?
I have understood that "add" does nothing if a tag is already set, while "set" would overwrite it. Have you tried defining bicycle=no, foot=no for the cycleway?
If so, can I do anything about it? I can't figure out a way to handle this, but maybe I'm missing something.
If the style file is the problem, I could imagine the following tags to be overwritten: access=no all by itself (would become access=no, bicycle=yes) access=no; bicycle=no (silly?) (becomes bicycle=yes) bicycle=no; (a bit odd, for a cycleway) (becomes bicycle=yes)
(BTW, if the styles are the problem here, I think that more road types show this behaviour, there are lots of places where an existing "access=no" gets extended by "something=yes").
Should we perhaps introduce a mkgmap:access: family of tags and map the "native" tags to those? e.g., access=no { add mkgmap:access:foot=no; add mkgmap:access:bicycle=no; ... } access=yes { add mkgmap:access:foot=yes; add mkgmap:access:bicycle=yes; ... } access=destination { similar... } bicycle=no { set mkgmap:access:bicycle=no } bicycle=yes { set mkgmap:access:bicycle=yes } bicycle=destination { set mkgmap:access: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; ... } Best regards, Marko
Should we perhaps introduce a mkgmap:access: family of tags and map the "native" tags to those? e.g.,
access=no { add mkgmap:access:foot=no; add mkgmap:access:bicycle=no; ... } access=yes { add mkgmap:access:foot=yes; add mkgmap:access:bicycle=yes; ... } access=destination { similar... } bicycle=no { set mkgmap:access:bicycle=no } bicycle=yes { set mkgmap:access:bicycle=yes } bicycle=destination { set mkgmap:access:bicycle=yes }
Yes, I like this idea. This would mean that everyone who need it could define its own mapping of the access tags in the style file. And it would be IMO a cleanly defined interface without uncertainities in the meanings of the tags. Furthermore it is extensible, if in future new tags are introduced in the osm data, e.g access=private or rollerblades=yes or whatever. But I would expect some perfomance drop if each tag needs to be translated into the internal one. Regards, Johann
Johann Gail wrote:
Should we perhaps introduce a mkgmap:access: family of tags and map the "native" tags to those? e.g.,
access=no { add mkgmap:access:foot=no; add mkgmap:access:bicycle=no; ... } access=yes { add mkgmap:access:foot=yes; add mkgmap:access:bicycle=yes; ... } access=destination { similar... } bicycle=no { set mkgmap:access:bicycle=no } bicycle=yes { set mkgmap:access:bicycle=yes } bicycle=destination { set mkgmap:access:bicycle=yes }
Yes, I like this idea. This would mean that everyone who need it could define its own mapping of the access tags in the style file. And it would be IMO a cleanly defined interface without uncertainities in the meanings of the tags. Furthermore it is extensible, if in future new tags are introduced in the osm data, e.g access=private or rollerblades=yes or whatever.
But I would expect some perfomance drop if each tag needs to be translated into the internal one.
I rather see the problem if you use such rules in the style-file now that you don't know whether they will be used or not (maybe another rule is already matching on the same street), or do you want to use these rules to precede all others? access=no is generally a problematic case, very often it is in places where motorcar=no is correct, but people choose the wrong value.
Regards, Johann _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
2009/10/30 Felix Hartmann <extremecarver@googlemail.com>
I rather see the problem if you use such rules in the style-file now that you don't know whether they will be used or not (maybe another rule is already matching on the same street), or do you want to use these rules to precede all others?
access=no is generally a problematic case, very often it is in places where motorcar=no is correct, but people choose the wrong value.
Hi! motorcar=no or motor_vehicle=no? The latter affects all motorised vehicles and is what most real-world street signs are actually saying, at least here in Germany. It would be cool if mkgmap supported motor_vehicle=* and vehicle=*, which includes also bicycles (if it doesn't already - last time I checked, it didn't). -Martin
participants (5)
-
Felix Hartmann -
Johann Gail -
Marko Mäkelä -
Martin Simon -
Valentijn Sessink