On Sun, 3 May 2020 at 18:56, Jan Michel <j...@mueschelsoft.de> wrote:
> Hi, > I oppose adding this officially to the top-level cycleway:lane tag. > I see this information as one more property of the cycleway, like > surface, smoothness, width and so on. > > We already have a documented key 'cycleway:buffer' that is described > as the width of the buffer space between car lanes and the bicycle lane. > The 'cycleway:buffer' tag is also used combined with :left and :right to > denote the buffer on left-hand and right-hand side of the cycleway. > > Mappers in Berlin worked on a more detailed tagging of buffer and > protection of bicycle lanes, see (unfortunately in German only) > https://wiki.openstreetmap.org/wiki/Berlin/Verkehrswende/Radwege > > I'd suggest to get in contact with them and discuss this. I imagine that > this information could fit very well into the cycleway:buffer tag - A > door zone is a non-existent buffer, so instead of 'no' one could use > 'doorzone' as one of the non-numeric values. I didn't know about cycleway:buffer, it sounds good but I don't think alone it is enough because: - It doesn't indicate if cars can be parked next to the cyclelane (as a doorzone only occurs when there are parked cars). I know we can marked a parking lane with parking:lane:parallel but I think it's better to have an explict way to say the cyclelane is in a doorzone. - Can be hard to measure distances and hence hard to say at what distance is considered in the door zone or not. In all the examples I know of there is no buffer so cycleway:buffer:left=no (for left hand side driving) but a half meter buffer might still be considered within the doorzone. The current wiki page for cycleway:buffer implies cycleway:buffer is between the cyclelane and traffic lane, it feels safer to never use cycleway:buffer and instead always explicitly state cycleway:buffer:left and cycleway:buffer:right, but it does get complicated with counterflow cyclelanes. On Sun, 3 May 2020 at 19:05, Florimond Berthoux < florimond.berth...@gmail.com> wrote: > I think sub properties of a feature should go with this scheme > mainfeature:subpropertie=values(yes/no/enumeration/absolute values/...) > This help to respect orthogonality : values of a key should not conflict > Agreed > So yes for : > cycleway:lane:doorzone=yes/no/buffered > buffered for the case there is a buffer marked between car park lane and > cycle lane like this : > https://cyclingsavvy.org/wp-content/uploads/2018/08/BikeLaneBuffer.jpg > no means that the cyclelane is wide enough to not be doored (no buffer > though). > That sounds good, except I think cycleway:lane:doorzone=no should mean that no part of the cyclelane is within the doorzone or there is no car parking and hence safe from doorzoning. cycleway:lane:doorzone=yes means that any part of the cyclelane is prone to doorzoning and cycleway:lane:doorzone=buffered means that there is a buffer to protect from doorzoning, so while mostly you'll be safe from doorzoning you might still want to exercise some caution. I think this then can work in combination with cycleway:buffer:left and cycleway:buffer:right. > > And I'd say yes also for : > cycleway:lane:exclusive > cycleway:lane:width > cycleway:lane:color > etc. > >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
