[Tagging] sub key for cycle ways

[Hubert]

Sure, but I think it is best to do that in addition and not instead of
“cycleway=*“ tagging. For one it takes more effort, 2. the cases where the
bike lane is in the middle of the road is limited. (not counting parking
lanes). 3. “cycleway=track” would look funny using that scheme. Also adding
more data about the lane is imo easier with a namespace based tagging scheme
of “cycleway:*=*.

On Sa, Nov 1, 2014 at 3:30 AM, Paul Johnson <baloo at ursamundi.org> wrote:

Can we move towards using the lanes tagging used for every other mode
already?  It's much more precise and can deal with situations like where the
bike lane is not the extreme left/right lane.

On Fri, Oct 31, 2014 at 7:43 PM, Hubert <sg.forum at gmx.de> wrote:
Hallo,
since a new main value for UK:advisary cyclelane, DE:Schutzstreifen,
A:Mehrzweckstreifen, NL:fietsstrook met onderbroken streep, F:bande cyclable
conseillée et réservée, CZ:cyklistický jízdní pruh didn’t get approved, I’m
thinking of introducing a sub key for that. (Like many of you already
suggested.)
As a start I’m thinking of “cycleway=lane + lane=soft_lane” for that
purpose.
However just a key for that one occasion doesn’t seem logical, so a set of
keys defining different types of “on lane”/”on road surface” cycle
infrastructure should be developed, to keep the tagging consistent or to
create a structured concept.
In order to do that, I’m thinking of introducing “lane=strict_lane,
soft_lane, suggestive_lane” for lane like cycle ways where bicycles are
‘encouraged’ to stay on one side of the road and “shared_lane=sharrows,
pictogram, busway” for roads/lanes where bicyclists are not separated from
other traffic.
The in my opinion the main problems in that idea are the use of
“lane=suggestive_lane” and “shared_lane= busway.
“lane=suggestive_lane” because it is in contrast of the current tagging as
“cycleway=shared_lane” in the Netherlands. At least as far as I can
remember. I’m also not sure whether “smurf lanes” in the UK are tagged as
“cycleway=shared_lane”. 
 “shared_lane= busway” since this is currently tagged as “cycleway=share_
busway”. I think that in favor of structure, “shared_lane= busway” should be
allowed. However, I haven’t made up my mind about that yet, or whether
“cycleway=share_ busway” should be deprecated or just be discouraged.
This would leave “cycleway=track, lane, shared_lane, opposite_track,
opposite_lane, opposite” as the main values, “lane=strict_lane, soft_lane,
suggestive_lane” and “shared_lane=sharrows, pictogram, busway”.
Not part of the sub key discussion:
As an addition one could say that a “cycleway=track” is also a lane like
cycle infrastructure, which would make it a “lane=track” sub key. 
Also any “cycleway=opposite(_*)” could be represented by, for example, 
“highway=* + 
oneway=yes + 
oneway:bicycle=no +
cycleway=right/left/both
cycleway:right/left =lane + 
cycleway:right/left:oneway= yes/-1”
(assuming right hand traffic)
What are your thoughts on this tagging scheme? 
I’m sorry, if this is a bit confusing. It’s late but I just couldn’t wait
writing. 
Best regard
Hubert

_______________________________________________
Tagging mailing list
Tagging at openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20141101/5bfbfde3/attachment.html>