Talk:Bicycle

Proposal for complete reworking of the 'Bicycle' page (July 2024)

See: https://community.openstreetmap.org/t/reworking-the-wiki-bicycle-page/116087 . Comments welcome.

oneway:bicycle

Good work on the new tables! One thing comes to mind though, in L2 you have "Oneway cycle lane on right side of the road only. Way A : highway=residential[1] + cycleway:right=lane + oneway:bicycle=yes ". But a bicycle can go in either direction (down the road or up on a choice of road or lane), so I'm not sure that oneway:bicycle=yes is the right tag? Gravitystorm 22:06, 29 December 2009 (UTC)

Fixed, see above. --Pieren 14:19, 30 December 2009 (UTC)

I think we have to go for a more complex scheme.

I would put:

• L1a: highway=* & cycleway=lane
• L1b: highway=* & cycleway:left=lane
• L1c: highway=* & cycleway:left=onewaylane--Extremecarver 12:05, 30 December 2009 (UTC)

-- Why don't we use bicycle=opposite? There is a proposal coming that will try to solve the problems regarding left/right, oneway restrictions, different lane issues and even the track/lane or different usages of the way. See for now Advanced Tagging scheme

Because it is less clear. Ideal is to have seperate keys. bicycle=opposite alone does not tell anything about the kind of restriction. It is good for cycleways on the opposite side of the street, but does not tell anything about which direction it may be used. It could be for both directions, or only for one. Just because you have bicycle=opposite, would not mean you are allowed to ride against the direction of traffic flow. It could simply mean the cycleway is on the left hand of the street, for right hand driving countries.... --Extremecarver 17:17, 15 December 2010 (UTC)

-- The current schemes are quite odd and buggy. I propose

L1b: highway=* & cycleway:left=lane & cycleway:oneway=no

M2d: highway=* & cycleway:left=lane & cycleway:oneway=no & oneway:bicycle=no & oneway=yes

The usage of cycleway:oneway=no states the situation very clear. Why should anybody care for oneway:bicycle=* if there is no oneway-Tag set. Logically the current scheme is not saying anything at L1b, because oneway:bicycle=no is the default. So you do not put any new information to the cycleway.--U715371 (talk) 14:59, 9 July 2014 (UTC)

New key order:?=*

I think we need a new key to describe the order of ways from left to right (or middle to outside). with the middle defaulting to highway=*. Using order:-1=*; order:-2=*; order:-3=*;... to classify the order to the left and order:1=*; order:2=*; order:3=*;... to classifiy the order to the right. I prefer this more complex scheme because of machine readability over using ";" (e.g order=footway;cycleway;carparking;highway;carparking;cycleway;footway) As an example tagging I would propose:

• Example T1:
• highway=*
• cycleway=track
• segregated=yes
• pavement=yes
• (key for cars parked alongside the road with specification if the cars are simply parked alongside, or if the cars are parked at an angle alongside (~45°), or 90° to the traffic direction - dunno if someone has been working on this already)
• order:-3=pavement oder:-2=cycleway order:-1=carparking order:1=carparking & order:2=cycleway & order:3=pavement.--Extremecarver 12:36, 30 December 2009 (UTC)

For parking alongside the road, someone wrote a Proposed_features/parking_lane, and the little discussion resulted in some using parking:both=inline/diagonal/orthogonal; or parking:left=* / parking:right=*, where needed.

I personally think that at that point, when one is adding roadside parkings and possible green patches, it becomes more sensible to just draw the cycleways and sidewalks as separate ways; only things that are between the curb stones are left as tags on the way with the main highway tag. Alv 14:26, 30 December 2009 (UTC)

Even though it will be easier to map. I as a cyclist really want to avoid using any cycleway that goes between parked cars and the sidewalk. According to studies your danger to get involved in an accident on such ways is 4 times higher than when riding on a normal road, if it is against the traffic flow on the side even 12x higher. Cardrivers tend to not notice things besides the street. Therefore having it tagged alltogether is the only solution to have autorouting avoid such ways that are real crap if you cycle a bit faster than average. The only other solution would be to replace highway=cycleway with somehting like highway=cycletrack so I know to avoid this way. The only other possibility is to resort to keys like "cyclability" or using keys like bicycle:trafficflow bicycle:dangerous -- the problem is that those keys will likely not get accepted soon. Currently we simply have no tags to allow an autorouting software to get decent routing for commuters on bicycle (meaning a possibility to avoid very crowded roads but also avoid residential roads or cycleway=track or any other ways were you often have to stop or pedestrians getting in your way. Favorising cycleway=lane is not a real solution, because they are usually built alongside big roads which one would like to avoid if there are faster possibilities to reach the destination).--Extremecarver 15:16, 30 December 2009 (UTC)

Case M3b

The case M3b seem strange for me !

This :

highway=* + oneway=yes + cycleway:right=lane + oneway:bicycle=no

mean for me that the cycleway is in the opposite direction that it's in real ?
Shouldn't not be like this :

highway=* + oneway=yes + cycleway:right=opposite_lane + oneway:bicycle=no

CU and thanks in advance Sarge 18:31, 29 July 2010 (UTC)

Tagging L1b

As it currently stands, L1b unfortunately can't be distinguished from L1a (when using the recommended tagging) or from L2 (when using the alternative tagging). However, for one-way roads we can actually distinguish them - see M2b vs. M2d. To solve this I'd simply suggest to tag L1b as highway=* + cycleway:right=lane + oneway:bicycle=no instead, so that the cycleway is explicitly stated as dual-way (since cycleway:right=lane actually implies oneway:bicycle:right=yes, see L2). --Emkey08 (talk) 22:03, 10 August 2013 (UTC)

Why is L1b not tagged as highway=* + cycleway:right=lane;opposite_lane? --Sanderd17 09:48, 6 September 2010 (BST)

Because 'opposite' and 'opposite_lane' are only refering to the oneway traffic in the main highway (cars) which is not the case in L1b. --Pieren 16:34, 6 September 2010 (BST)

recommended usage

It is totally unclear who recommends what on this page! I.e. for L1a "cycleway=lane" is recommended while for M1 "cycleway:left=lane + cycleway:right=lane" is recommended. I also know no one who recommends the usage of cycleway=opposite_* after thinking about mixing driving directions with way types. --phobie m d 15:05, 15 September 2011 (BST)

I agree that the recommended way to tag M1 should be highway=* + oneway=yes + cycleway=lane + oneway:bicycle=no, since this needs less tags and is semantically equivalent. I'd further say that the alternate way to tag M1 should be, in accordance with M3a, highway=* + oneway=yes + cycleway:left=opposite_lane + cycleway:right=lane --Emkey08 (talk) 22:25, 10 August 2013 (UTC)

How to tag a shuttle provided across a bridge?

The Chesapeake Bay Bridge-Tunnel does not allow bikes, but will shuttle you and your bike across for the same price as the car toll. Is there a way to tag this? --NE2 09:22, 29 July 2012 (BST)

I would suggest adding, as a minimum, bicycle=dismount, at least to the ways (bridge, tunnel). This is a valuable indication that cyclist have SOME possible way to cross, but much less convenient that a simple bicycle=yes. Perhaps you would also add toll:bicycle=yes (on the ways) and/or description=Cyclists must call ahead on (757) 331-2960, then ride provided shuttle van. (or something like that, at the toll booth node say).

By the way, as this bridge-tunnel is itself connected to other ways tagged as highway=motorway there is perhaps no valid routing for a cyclist to get to it in the first place! Perhaps there are some missing side paths that are available for only cyclists and/or pedestrians. Or perhaps US 13 also needs bicycle=yes + cycleway=* added to its tags (if that is in fact the case, which I do not know about)?--Neil Dewhurst, Lyon France (talk) 09:26, 22 May 2014 (UTC)

M2d vs. M3a

highway=* + oneway=yes + cycleway:left=lane + oneway:bicycle=no is listed as a possibility for both of these (M2d is missing the oneway=yes that's obviously necessary). So which is it? Does cycleway:left=lane mean that it's a one-way or two-way lane? --NE2 21:17, 1 October 2012 (BST)

I guess, the concept is so : the "oneway=yes" is a general restriction applying to all vehicles on the OSM way, including bikes, until it is specificaly excluded by a "oneway:bicycle=no". --Pieren 10:06, 2 October 2012 (BST)

I understand that. My point is that M2d and M3a, two separate situations, are both modeled by highway=* + oneway=yes + cycleway:left=lane + oneway:bicycle=no. --NE2 15:27, 2 October 2012 (BST)

In M3a it should read oneway:bicycle=reverse (or -1 if you insist on completely unreadable values). --Imagic 15:44, 2 October 2012 (BST)

Huh? Bikes are generally allowed to use the car lane if there's no bike lane. The only difference between M2d and M3a is physical: there's no northbound bike lane in M2d. --NE2 18:15, 3 October 2012 (BST)

Sorry, I misinterpreted the picture. I think the main problem is that cycleway=lane doesn't really tell us in which direction the cycle-lane runs (and how many lanes there are). Using the :lanes-suffix it's no problem to tag this, but Pieren still insists that this tagging scheme is not accepted. ;-) --Imagic 11:46, 4 October 2012 (BST)

I don't know why you say that. I enhanced the wiki with the table and all examples. Then the scheme evolved and is still evolving. I'm not following it daily or monthly. --Pieren 15:26, 4 October 2012 (BST)

I say that because after I added a solution to B1 based on the :lanes-extension you added a "Proposal (no consensus)" to it, although the proposal was already approved and the tagging scheme was used over 1.000 times. And I told you by that time that the proposal was already approved but you insisted that it is no consensus. That's why. Just to be sure that we understand each other: the :lanes-extension should be used as rarely as possible and whenever it is possible to tag a feature with other established tags, those tags should be used. This extension is for cases that can not be tagged at all otherwise. Like non-standard lane layout: and that is what we are talking here about. --Imagic 07:37, 5 October 2012 (BST)

For other readers, lanes tagging has different proposals, see Lane tagging comparison. And Imagic is supporting one of them. --Pieren 11:45, 5 October 2012 (BST)

For other readers: there is one approved tagging scheme for lanes tagging and it is documented here. --Imagic 12:03, 5 October 2012 (BST)

I agree that we have a problem between M2d and M3a. It's not a big problem because it is not altering routing. But we cannot distinguish the M2d case where a dedicated lane exists from south to north where you have to take the car lane in M3a. Any suggestion welcome. --Pieren 12:24, 4 October 2012 (BST)

photos for L1b and T2 swapped?

I would say that the example photo for L1b shows a situation that I would have tagged as T2 and vice versa --voschix (talk) 11:07, 4 July 2013 (UTC)

Proposed: page revamp

This page provides extremely useful information regarding the tagging of cycle lanes and cycle tracks. However, as this primarily concerns the tagging of cycleway=*, I think those tables should be actually listed on the Key:cycleway page instead of here.

From my understanding, this page should be more an overview page of all bicycle and cycleway related features of OSM (like an overview of the concept of cycle lanes, tracks, ways, roads, routes, and other cycling facilities), with links to the corresponding Wiki pages which describe those features and their tags in greater detail.

Objections and suggestions? --Emkey08 (talk) 10:34, 13 August 2013 (UTC)

It lists also (nowadays) also tagging using many other tags. 19:37, 25 July 2020 (UTC)

Which makes it not better as Map Features is not even using the Template:Map_Features:cycleway and the keys pages and the tags pages about bicycle=* and cycleway=* all have their own content, these pages get out of sync quite often and maintenance is a pain. Would prefer a link page similar to the German version of this page, as overview. Additionally, harmonizing the Map Features templates and using them in all place would help. --Skyper (talk) 11:57, 18 September 2020 (UTC)

Picto lanes

How to map non separated "lanes" with bicycle pistograms? See https://www.youtube.com/watch?v=HbTY0YES8n8 (it is in czech, but just look at video)

Easy question, simple answer: cycleway=shared_lane - no matter if there are pictograms, arrows, sharrows (cyclist pictogram "sheltered" by an arrow head that looks like a roof over his head).

Even no road-surface markings at all, but with traffic signs warning specifically of the probable presence of cyclists (equivalence of horizontal/vertical markings). All these cases are equivalent: there is no cycling lane reserved exclusively for cyclist as such, and so banned to other road users, only indication to warning of the probable presence of cyclists. This is frequent for designated bike routes (local, national, international) following normal shared roads that are too narrow for a seperate bike lane. Can also occur simply when bicycle traffic is known to be high, which of the course the locals already know but could be unexpected to strangers just passing through. Sharrows are great in that their actual position on the roadway and their width provides a shared reference framework for the cyclist and overtaking drivers: given that the cyclist is seen to be riding straight down the road width marked by sharrows then a faster vehicle can reasonable overtake by simply avoiding to encroach on that part of the road (this reduces the effort needed to anticipate the cyclists evolution when no longer in plain sight out in front, and so too can also be a cause of accidents for beginner cyclist who cannot in fact ride in a straight line, but this is very rare since beginners usually avoid busy streets and rightfully so).--Neil Dewhurst, Lyon France (talk) 08:40, 22 May 2014 (UTC)

case M2b (and M3a)

Shouldn't case M2b be labeled as:

highway=* + oneway=yes + cycleway:left=opposite_lane

and case M3a as:

highway=* + oneway=yes + cycleway:left=lane

? As it is currently labeled the definition of cycleway:left/right=lane changes definition for one- and two-way roads. In the case of two-way roads cycleway:left=lane means that a left lane always travels with the direction of trafic on the left lane. i.e. downward in the L cases. However, in the M cases cycleway:left=lane switches to traveling in upward direction in the left lane, against the typical direction on a left lane. --Boeleman81 (talk) 17:44, 21 May 2014 (UTC)

Good question. Pertinent comment. Thank you very much, for both. I think now that I understand better why I have been having so much trouble assimilating the correct technique, the technique used elsewhere so far, which does seem illogical as now pointed out by Boeleman81.

M2b - My suggestion would be: highway=* + oneway=yes + cycleway:forward:left=lane

In other terms (Continental Europe or North America): "cycleway:right=*" is presumed to really mean "cycleway:forward:right=*" and so applies to bicycles on the normal side of the road whilst moving in the same direction as the way itself. So too is "cycleway:left=*" presumed to mean "cycleway:backward:left=*" and applies to bicycles on the normal side of the road when going in the opposing direction. If that be accepted as correct, then "cycleway:forward:left=*" and "cycleway:backward:right=*" would be used for non-normal sided travel. There will be no more need for "cycleway:left=opposite_lane" (use instead "cycleway:backward:left=lane") or for "busway:left=opposite_busway + cycleway:left=opposite_share_busway" (use instead "busway:backward:left=lane + cycleway:backward:left=shared_busway").

The advantage of this scheme, perhaps slightly more laborious in the simplest of cases, is that it eliminates hazardous assumptions and so too wrongful interpretations. And, perhaps more importantly as pointed out by Boeleman81, applies identically for one-way and two-way streets with identical interpretation in each case (please also use "oneway:bicycle=no" and/or "oneway:psv=no" when appropriate - see after).

Also, the tag example given for M3a seems incomplete to me (already, using the current tagging scheme). In so far that the non-oneway characteristic for cycles should be explicitely stated, but is not. The "oneway=*" tags are specific information used in routing algorithms to correctly find permissable connections - regardless of lane choices, which could be also be done, later. They also provides a useful brain-check for other OSM contributors.

M3a - With the current schema (as of May 2014), should probably read:

highway=* + oneway=yes + oneway:bicycle=no + cycleway:left=opposite_lane

M3a - My suggestion would be:

highway=* + oneway=yes + oneway:bicycle=no + cycleway:backward:left=lane --Neil Dewhurst, Lyon France (talk) 08:13, 22 May 2014 (UTC)

bicycle=use_sidepath

A new proposal, Proposed_features/use_sidepath (tl;dr: use bicycle=use_sidepath on highways which have a parallel cycle track), has been approved on 16 May 2014. I updated the examples in this article accordingly. Have I done this right? --M!dgard (talk) 21:59, 28 May 2014 (UTC)

Nice update. Thanks. However, the explanation now suggests that the use of the adjacent mandatory/compulsory cycleway is optional under certain circumstances (example given: if the road has been cleared of snow, but the cycleway has not). This may not apply in all jurisdictions (e.g. as far as we currently know, there is no such provision in Dutch law; you must use the cycleway, or perhaps walk your bicycle instead). See extensive discussions on the relevant Talk pages for this proposal. Frankl2009 (talk) 13:10, 5 June 2014 (UTC)

I see ... In Belgium, I believe we are allowed to leave it: KB 01.12.1975, 9.1.2.1° When the public way contains a ridable cycleway, cyclists must follow (...) this cycleway (...). I'll update the article stating that this might not apply in all countries. But to be honest, I don't see the purpose of the tag if you are never allowed to leave the cycleway, bicycle=no seems good enough in those cases ...

Oneway designations in roads with modal segregation

In roads with modal segregation, each element has its own oneway designation.

• On a road with two cycletracks, one on each side, each cycletrack is unidirectional for cycling right hand of the carriageway, unless bidirectional designation is signposted. The carriageway is bidirectional, unless there are oneway signs. If the cycletracks are facultative, you may cycle in both directions on the carriageway, but only in one direction on one cycleway, and only in the opposite direction on the other one.
• In a street that is unidirectional for motor traffic, there can be
  • a cycletrack for the same direction,
  • or a cycletrack for the opposite direction,
  • or a bidirectional cycletrack,
  • or one consensual and one opposite cycletrack.
• All cycletracks can be tagged simply with oneway=(yes/no).
• Only on the carriageway, oneway=yes and the subkey oneway:bicycle=no are afforded, if unidirectional motor traffic and bidirectional cycle traffic run in the same space. For this only only indication left ((here from "to leave")), the guideline Key:access#One-way restrictions provides the alternative tagging bicycle:backward=yes.

--Ulamm (talk) 18:03, 15 November 2014 (UTC)+Ulamm (talk) 09:53, 21 November 2014 (UTC)

Is there somewhere a question hidden? This is the discussion page. If you simply state your opinion and expect everybody else to accept it, this might not be the right place. If you want to discuss something, you are very welcome to start a discussion here for example by asking a question or proposing something. I do not share your opinion as stated above, but as you don't ask or propose anything, I guess I'm not even wanted to elaborate why. --Imagic (talk) 10:26, 21 November 2014 (UTC)

I had revised the text of this article in a way that does not add new ideas but simply follows logical rules. Two other mappers did not understand my revision. Therefore I've explained it here.

Sometimes, I enter exlpanations into an article itself, but here this would have inflated the article.--Ulamm (talk) 11:19, 21 November 2014 (UTC)

In streets consisting of several traffic spaces, oneway:bicycle=* has to be used only for a carriageway. For the other spaces, the concerning element of the street is the only appropriate specification of oneway=*, as cycling may be allowed in more than one element, with different regulations of direction.

If a road or street with a carriageway and adjacent cycletracks is recorded with one wayline, all tags without [[Key:|]]:cycleway=* describe the carriageway itself. See the table below.--Ulamm (talk) 09:22, 23 November 2014 (UTC)

Table of street layouts

The following gallery of street layouts does not even show all possible variations, and it is the short version, only.

• Long version see here ((addition --Ulamm (talk) 17:43, 14 December 2014 (UTC)))

Mainly it shows German signposting, which is more complicated than the French and the Austrian one. And it is focussed on roadline tagging, which is more difficult than using separately drawn cycleways. The feature of obligatory = compulsory vs. facultative =advisory cycletracks and the alternatives of recording them are only considered completely in some of the examples.

Innovative suggestions are written in purple.

General problem: Many combined tags, especialy on side-specific informations, and even some "well established" values like cycleway=opposite_track are either neglected or misunderstood by almost all renderers, even those that have been designed for cyclists.

• 

  oneway=yes
  cycleway=opposite_track
  cycleway=left

• 

  oneway=yes
  cycleway:left=track
  oneway:cycleway(:left)=no

• 

  oneway=yes
  cycleway:right=track
  oneway:cycleway(:right)=no

• 

  oneway=yes
  cycleway:right=track
  oneway:cycleway:right=yes
  cycleway:left=opposite_track

• 

  oneway=yes
  cycleway:right=track
  oneway:cycleway(:right)=yes
  bicycle=use_sidepath
  OR
  oneway=yes
  cycleway:right=track
  cycleway(:right)=obligatory
  oneway:cycleway(:right)=yes

• 

  French signs: advisory cycleway, oneway
  oneway=yes
  bicycle=yes
  cycleway:left=track
  oneway:forward:cycleway(:left)=yes
  OR
  oneway=yes
  cycleway:left:track=facultative
  oneway:forward:cycleway(:left)=yes

• 

  oneway=yes
  bicycle:backward=yes
  OR
  oneway=yes
  oneway:bicycle=no
  cycleway:opposite

• 

  bicycle:forward=no
  bicycle:backward=yes

• 

  cycleway:right=track
  oneway:cycleway:yes
  bicycle:both=yes
  OR
  cycleway:right=track
  oneway:cycleway:yes
  cycleway=facultative

• 

  cycleway:right=track
  bicycle:forward=use_cycleway*
  bicycle:backward=yes
  OR
  cycleway:right:track=obligatory**
  oneway:cycleway(:right)=yes

• 

  cycleway:both=track
  oneway:cycleway:both=yes
  bicycle:forward=use_cycleway*
  bicycle:backward=yes
  OR
  cycleway:right:track
  cycleway:right=obligatory**
  cycleway:left=facultative***
  oneway:cycleway:both=yes

• 

  cycleway:both=track
  oneway:cycleway:both=yes
  bicycle:both=yes
  OR
  cycleway:both:track=facultative***
  oneway:cycleway:both=yes

• 

  right carriageway:
  cycleway:right=track
  oneway:cycleway(:right)=no
  bicycle=yes
  opposite carriageway:
  cycleway:right=track
  oneway:cycleway(:right)=yes
  bicycle=yes

• 

  right carriageway:
  cycleway:right=track
  oneway:cycleway(:right)=no
  bicycle=use_sidepath*
  opposite carriageway:
  cycleway:right=track
  oneway:cycleway(:right)=yes
  bicycle=yes

Notes:

• *The application of this tag for roads with cycletracks not separately drawn is disliked by its initiator.
• **The tag bicyle=obligatory (or perhaps bicyle=oblig) is a new suggestion instead of bicyle=designated, which is equivocal.
• ***The tag bicyle=facultative (or perhaps bicyle=free) is a new suggestion instead of bicyle=yes, if uesd on cycletracks as a couterpart of "obligatory".
• "(:right)" and "(:left)": If only on one side of a carriageway there is a cycletrack, it seems to be questionable whether it is better or unnecessary to repeat its localisation in the "oneway"-tag.

--Ulamm (talk) 01:15, 22 November 2014 (UTC) … Ulamm (talk) 08:53, 23 November 2014 (UTC)

"bicyle=oblig", "bicyle=desginated" - you may want to fix misspellings. And - introducing multiple new poorly defined access values is a terrible and thoroughly bad idea (after making it well defined it still would be a thoroughly bad idea). Mateusz Konieczny (talk) 21:35, 15 December 2014 (UTC)

"bicyle=oblig" is a real suggestion, a moderate abbreviation of "obligatory" (which is a derivation of the Latin verb "obligare"; "obligatio" means duty).

"desginated" was my legasthenic finger:)

We ought to come to a serious discussion. There are so many features of road layout. They are worth to be tagged, but up to now the tolls are insufficient. Meanwhile I have added some more examples and the tags for separately drawn cycletracks, see User:Ulamm/Tables of street layouts.--Ulamm (talk) 00:49, 16 December 2014 (UTC)

M3a – wrong illustration

The illustration for oneway=yes + cycleway=opposite_lane has a mistake: In this setting, the car lane normally is shared (mostly without shared lane markings (en.wikipedia)) by bicycles running in the same direction as the cars. That bicycle is missing in the drawing. (see the similar setting with a cycletrack in the 1st picture in my own table above)--Ulamm (talk) 19:09, 30 November 2014 (UTC)

M3a - S1 - Inconsistencies with other pages

If you look at[1], tag oneway:bicycle=no should be avoided as in S1

Also why would M3a should be tagged with oneway:bicycle=no and not S1?

[2] gives an example without oneway:bicycle=no.

My suggestion would be S1: highway=*[1] + oneway=yes + cycleway:left=opposite M3a: highway=*[1] + oneway=yes + cycleway:left=opposite_lane

Or same as above with oneway:bicycle=no added for both cases -- jean-alexis 17:26 26 December 2016

It's not really "should be avoided", but somebody has created a wiki template for listing possibly synonymous tags (and the text on the template doesn't match the subheading on the cycleway=opposite page). In this case, oneway:bicycle=no is a perfectly valid tag, but it most likely in some cases means exactly the same as cycleway=opposite ; the keys oneway:biycle= and cycleway= describe different attributes (or, one is an attribute and one is the "thing" called cycleway) so they are sometimes used together. Alv (talk) 07:20, 28 December 2016 (UTC)

I edited it, now skipping oneway:bicycle=no is no longer considered as one of two recommended taggings Mateusz Konieczny (talk) 19:39, 25 July 2020 (UTC)

Not tagging sidewalks?

"If sidewalks are considered as implied:" - AFAIK not tagging sidewalk at all is not something recommended, I would skip it from proposed tagging Mateusz Konieczny (talk) 19:34, 25 July 2020 (UTC)

Deprecate cycleway=opposite*

See Talk:Key:cycleway#Deprecate cycleway=opposite* --Skyper (talk) 12:24, 18 September 2020 (UTC)

Is explicit oneway=no something that should be recommended?

I would remove recommendation for explicit =no tagging or mark it as an optional.

It would affect

• L1b ("cycleway:right:oneway=no")
• T2 "oneway=no"
• T2 "cycleway:right:oneway=no"
• T3 "oneway=no" on cycleway ("oneway:bicycle=no" in alternative tagging variant is actually needed and would remain unchanged)

Mateusz Konieczny (talk) 17:23, 10 November 2020 (UTC)

I think it should definitely stay as recommended, as there would be no way to differentiate L1b from L2 (if you remove "cycleway:right:oneway=no"), etc. Also it is always better to be explicit, as missing "*oneway" could mean "no", but it could also mean "not mapped, could be yes or no" --mnalis (talk) 20:07, 10 November 2020 (UTC)

Sidewalk separated by kerb

I live in a place where the cycle track and side walk are separated from each other by a kerb: car lanes _| cycle track _| side walk Is it ok in this case to map cycle track and side walk separately? Why does it matter: This often has the consequence that ways joining from elsewhere are separated from the cycle track by the kerb while the side walk is connected without a such barrier. This has different implications for cyclists and wheelchair users. While wheelchair users can turn into/from the joining way without a kerb, cyclists do have to cross it. I can't think of a way to reflect this physical reality on the map by using only one way for both cyclists & pedestrians. Martianfreeloader (talk) 16:19, 16 November 2020 (UTC)

Well, it is always possible to tag them separately, but have you considered using segregated=yes ? --mnalis (talk) 21:30, 17 November 2020 (UTC)

Thanks for the answer, mnalis. When turning into another way, cyclists have to cross the kerb, while wheelchair users don't. I believe that this detail is not captured by using segregated=yes. I'm talking about a kerb that is so high that it is inconvenient for cyclists to cross. This is obviously poor street design, but not an unusual situation in my city. I'd like to give routing software a chance to take the kerb into account for cyclists, while avoiding to map wheelchair barriers where there aren't any. Martianfreeloader (talk) 08:57, 18 November 2020 (UTC)

Unfortunately, I do not know of more precise tag which carries more information. You may want to talk with prospective router software developers about ideas regarding this problem. Note, however, that even your idea as drawing them as two separate ways would not solve your problem, as two ways would be disconnected (unless you connect them every now and then with fake ways with access restrictions, which is not good idea). --mnalis (talk) 18:38, 7 December 2020 (UTC)

Overlaps between cycleway lanes and :lanes tagging

The deeper the tagging of real bicycle lanes grows the more it creates overlaps with Lanes tagging. I wonder how long we want to develop a duplicate tagging system for bicycle lanes? --Skyper (talk) 16:00, 21 March 2021 (UTC)

Cycleway directions in oneway streets

Example M1 - cycle lanes on left and right sides of a oneway road:
oneway=yes +
oneway:bicycle=no +
cycleway:both=lane

I'm a bit confused right now, because for years I assumed that a cycleway:left in a oneway street (with right hand traffic) would be interpreted as a cycleway running in the opposite direction to the street's direction by default. I have therefore always tagged them with cycleway:left=lane only, without cycleway:left:oneway=-1. Now I realised, that this is the opposite of what is documented in the wiki. According to the wiki, it is always assumed that the cycleways of a oneway street - no matter on which side - point in the same direction as the street line. Apparently, there is an exception if cycleways are indicated on both sides at the same time (cycleway=lane or better cycleway:both=lane).

I can live with that, but I don't find this consistent and intuitive. I would prefer if either all cycleways on both sides are assumed to run in the same direction, or the cycleways on each side are assumed to run in the respective default direction of traffic (which is what I have assumed, but which is apparently not the practice).

But currently the interpretation apparently depends on a mix of 1) is there a cycleway on just one side or both sides? and 2) what is the value of oneway:bicycle=*? Because otherwise we would have to add a cycleway:left:oneway=-1 in the example M1 (oneway=yes + oneway:bicycle=no + cycleway:both=lane = cycleways on both sides of a oneway road, but assumed running in different directions only in this case). If oneway:bicycle=no would be missing in this example, one would assume the same direction for both cycleways, isn't it?

I'm aware that this can hardly be changed, but should we highlight this logic more clearly? --Supaplex030 (talk) 22:19, 27 November 2022 (UTC)