Requesting buffered bike lanes option for "Bike paths" quest

[Coehill]

Use case
In Canada, many cities publish bike maps which distinguish between standard bike lanes and "buffered bike lanes". Buffered bike lanes are important information on busy, fast-moving streets since they offer more safety than a single painted line. They are defined as a dedicated bicycle lane with double lines of white paint to separate the cyclist from traffic. They may also have diagonal striping or rumble strips between the double lines. This is different than the existing "sidepath or protected bicycle lane" because buffered bicycle lanes are level with the road and are unprotected by bollards/concrete/etc.

Proposed Solution

bicycle=dedicated
cycleway=lane 
cycleway:buffer=*

The cycleway:buffer=* should be tagged in conjunction with cycleway=lane. Use cycleway:right:buffer=* and/or cycleway:left:buffer=* to tag different buffers on either side of the road. The buffer value may be yes, no, or a number indicating the width of the buffer. I propose that we use yes or no for simplicity. The width of the buffer could potentially be a separate quest.

It could be drawn in OpenStreetMap as the same as a bicycle lane, but with two lines.

Example:
source

[matkoniecz]

Buffer like one on this photo is basically not changing anything...

[Coehill]

Buffer like one on this photo is basically not changing anything...

Can you please clarify whether you're referring to changing anything safety-wise or in StreetComplete?

Regarding safety, fully protected bike lanes with a physical barrier would be far superior to these painted lines. However, driver behaviour somewhat improves when there are two lines so it's clearer that it's not a shoulder, as well as rumble strips. Unfortunately, in much of my country there are only standard or buffered lanes with very few safe, protected lanes.

Regardless, the distinction between the two is meaningful and well-documented in city planning.

[matkoniecz]

Can you please clarify whether you're referring to changing anything safety-wise or in StreetComplete?

first one - I have serious doubt about usefulness of collecting data how wide this painted line is (as a cyclist)

[Coehill]

Can you please clarify whether you're referring to changing anything safety-wise or in StreetComplete?

first one - I have serious doubt about usefulness of collecting data how wide this painted line is (as a cyclist)

That is fine, because this proposal is to include yes/no. I agree that it's questionable to go so far as to specify the width. :)

[westnordost]

Hm, this tag is not really in use yet. After no, the most used value for cycleway:buffer is 2. The wiki doesn't explain what unit should be used. So it's 2 meters buffer? Huh?

Other than that I tentatively agree with @matkoniecz that this road looks really unsafe for cyclists (with or without double-stripe), I think it would be more meaningful to ask for both the left side and the right side of a cycle lane (for each side), because within cities, you have cycle lanes sometimes that are close to the parking lane without buffer. The UI would be difficult for that, though. On the other hand, most traffic regulations I know define certain minimum requirements for cycle lanes and having a sufficient distance to the doorzone of parking cars is usually part of these requirements. Thus, it would be spammy to ask about the buffer in such countries.

Also, might be difficult to ask users to "buffer, yes or no?" because at least according to the values tagged so far, a buffer is not a buffer - the widths and thus the perceived safety seem to differ widely.

[matkoniecz]

Also, might be difficult to ask users to "buffer, yes or no?"

more specifically: I would not really guess that this specific one is supposed to be counted as having a buffer

[Coehill]

Hm, this tag is not really in use yet. After no, the most used value for cycleway:buffer is 2. The wiki doesn't explain what unit should be used. So it's 2 meters buffer? Huh?

The wiki states "If no unit is given, the default is meters."

Other than that I tentatively agree with @matkoniecz that this road looks really unsafe for cyclists (with or without double-stripe),

I definitely agree that this is unsafe too. The paint does not protect you from a motor vehicle on a fast-moving road. In much of Canada and the USA outside of major cities, the bicycle infrastructure is significantly worse than in Europe, so the distinctions between a standard and buffered lane become more important. Unfortunately, in most of Canada outside of a couple major cities, this is the best we get.

Standard Bike Lane:
source

Buffered Bike Lane:
source

I think it would be more meaningful to ask for both the left side and the right side of a cycle lane (for each side), because within cities, you have cycle lanes sometimes that are close to the parking lane without buffer. The UI would be difficult for that, though. On the other hand, most traffic regulations I know define certain minimum requirements for cycle lanes and having a sufficient distance to the doorzone of parking cars is usually part of these requirements. Thus, it would be spammy to ask about the buffer in such countries.

I really like the current, existing functionality where it asks if there's a bike lane on each side. I am suggesting that we add an additional option for buffered bike lanes. Without this option, the closest choice is either standard "bicycle lane" (inaccurate) or "sidepath or protected bicycle lane" (even more inaccurate).

Here is a mock-up I made for clarity 🙂 (I just added it to the original issue description)

Also, might be difficult to ask users to "buffer, yes or no?" because at least according to the values tagged so far, a buffer is not a buffer - the widths and thus the perceived safety seem to differ widely.

IMO it is best to stick with yes/no to indicate that a buffer exists. A buffer is simply a standard bike lane with a second line. By definition, it is a wider bike lane which marginally increases safety and makes it clearer to avoid card parking in bike lanes (a chronic and unenforced problem here).

I'd also like to add that buffered bicycle lanes are used by both advocacy groups in Canada and officially recognized by governments and municipalities in Canada and USA. It is a standard term in city planning where I live. As a result, it's useful to have this information in OSM and to avoid it being overwritten by less accurate bike lane types.

Examples of buffered bike lane usage across Canada and the USA:

• National Association of City Transportation Officials Bikeway Urban Design Guide
• Included in Edmonton, Alberta's Transportation Master Plan
• Seattle, Washington
• Kansas City, Missouri
• Long Beach, California
• Eugene, Oregon
• OSM Bike Ottawa Tagging Guide includes buffered bike lanes.

[Coehill]

Also, please note that I would be happy to make this change myself with permission from the devs. 🙂

[matkoniecz]

I still have problem about increasing form complexity. In terms of other dubious improvements I have seen for example:

• bicycle lane painted red (or orange or blue)
• additional vertical signs reminding that bicycle lane is for cyclists
• additional horizontal signs reminding that bicycle lane is for cyclists
• crossed over car symbols on bicycle lane
• crossed over parking symbols on bicycle lane
• soft bollards on lane between bicycle lane and car lanes
• additional markings on a car lane

All this seems in the same category of marginally improving safety, but being no substantial improvements - like that wide painted lane.

[matkoniecz]

Would we want listing of all of them? Almost certainly no.

Would we want specifically "40 cm wide painted lane" specifically? Why that and no other?

What if someone will arrive next and start to ask to provide option to tag also other similar things?

[mnalis]

I'm on the edge about including that option in StreetComplete.

On the one hand, it has some use and seems deterministic; but on the other hand, it might confuse users (especially non-cyclist ones, or the ones whose country does not have those) as introducing another option between "protected bicycle lane" and "(unprotected) bicycle lane" leading to analysis paralysis.

So perhaps such additional answer option might be better fit for SCEE (StreetComplete "Expert edition" fork) which is open for quests requiring domain expert knowledge (and which might also be open to followup quests on e.g. cycleway:right:buffer=yes and asking for actual width, provided the people are interested to write it and find the data useful)

Another option is only showing that option in StreetComplete only in countries where it is popular, but that requires complexity and research to update https://github.com/streetcomplete/countrymetadata (akin to e.g. hasAdvisoryCycleLane.yml)

[westnordost]

As others have written, whether or not a cycle lane has a double line to other lanes is just one of many separation features that might be recorded.

The following is just a proposal - https://wiki.openstreetmap.org/wiki/Proposal:Separation - but it contains a lot of examples and photos by which things or markings a cycle lane or cycle track can be separated from other lanes. And to record this seems to be more relevant to me than just the buffer width via the markings. It for example makes a big difference if the buffer is filled with jersey barriers or not.

Now, that proposal looks kind of incomplete, e.g. the separation seen in your first photo - a rumble strip - is missing from that proposal.

Also, given the complexity of all this, I do wonder whether it wouldn't be simpler to just map every cycle lane that is protected in some proper way (jersey barrier, kerb, greenery, guard rail, .... but not rumble strips or studs) as a separate way in OSM or at least map it as cycleway=track rather than to go into that much detail how exactly a lane is separated or not-really separated from the rest of the traffic.

[RubenKelevra]

Given the amount of usage of them in the US and Canada it's worth adding this as an option for those countries, as its a significant improvement in visibility and thus safety and usually comes with a better overall planning for the infrastructure itself.

So if two parallel roads are an option from point A to B I would always choose the buffered bike lane.

That's reason enough to tag it and also ask for support in routers for favoring this.

The term itself seems to be well established, so I don't see an issue with the tag in use for yes/no, even if it's low in use right now.

However I wonder if it would make sense to break the quest up into three questions:

• Capture if the cycle infrastructure is on the sidewalk, street, not existed, or seperately mapped first
• Ask for details about subtypes second
• Ask if they are oneway or not

The list is now, as several have pointed out, already pretty long right now and it's getting pretty hard to answer in a oneshot, as stuff like "which type of line seperate the lane painted on the road? ", "is this for one or two directions?", and "is there a cycleway at all?" are mixed together.

This would considerably reduce the options a user has to scroll through for each step, while the effort should stay pretty much the same.

[westnordost]

Alright, I read this thread again.

First, I understand that there are places where there is no hard (or reasonable) minimum width for bike lanes set in traffic legislation, which means that cycleway:<side>=lane + cycleway:<side>:lane=* becomes insufficient to classify the quality of a bike lane. I.e. if the bike lane is really narrow (< 1.5 meters / < 5 feet), a small buffer can make a big difference in perceived safety.

But, then, to record the buffer alone is useless. The much more important information in that case is the width of the lane in the first place. Only if it is in itself already too narrow, it is worthwhile to ask whether there is (at least) a buffer to parking cars and a buffer to moving cars.

So, first there would need to be a quest that asks for the width of the bike lane(s) on each side of a road. Then, downstream, there could (conditionally) be a quest that asks about buffer widths, as just recording the existence of a buffer would add very little value. The buffer to the right may also be relevant (due to parking cars) and most of all, the width of these buffers will be relevant.
Asking about buffers could be done conditionally, e.g. if cars may go faster than 50 km/h / 30 mph (higher chance of there being a left buffer) or if there is a parking lane to the right (higher chance of there being a buffer to the right).

(So, this quest suggestion is at least blocked by a hypothetical implementation of a "cycle lane width" quest. Otherwise, it is conceivable, although the UI will be challenging to design clearly)

[RubenKelevra]

While mapping width of cycle lanes would be pretty awesome in regards of determining the quality of routing, it also takes a lot more effort than mapping simple binary/trinary etc status.

This is due to changes in the infrastructure over the span of the road, which makes multiple measurements necessary. While cycle lanes are usually created according to a standard, those standards have changed a lot in the recent decade, making it quite a patchwork what's actually out there.

So yes, those data would be pretty valuable, but I also think it's not necessary for answering the question, as outlined before. I mean we already got options like "cycling on the shoulder", "cycling on the bus lane", "cycling on a advisory bike lane", "cycling on a bike lane"...

Thats a lot of options already for pretty similar things. But I agree that we can't go forward and add another special case, which will be followed by another special case.

That's why it's important to break this up into multiple questions. I know that's not the standard in Street Complete, but not without precedent - we do this for the max speed quest as well.

First we need to ask where cycling is allowed, which gives 4 possible answers:

• on the sidewalk
• on the street
• not allowed
• mapped on a sidewalk mapped separately

Depending on this multiple choice answers we would need to ask how cycling on street level looks like and how on the sidewalk, like we do if the user taps on the separately mapped sidewalk.

On street level we would then add options like:

• cyclist got a seperate lane
• cyclists need to share lane(s) with regular traffic
• cyclists need to share lane(s) with busses

And if the user chooses seperate lane we would present the options about protected and unprotected bike lanes, including advisory bike lanes.

This allows to go into more details here and show the differences more clearly to understand for users, as confusing options like bus/bike lanes and "sidepath or protected bicycle lane" are no longer needed.

[RubenKelevra]

@westnordost Maybe to go forward here, and become actionable:

I think I've got an idea how to structure this. If you're open for splitting the currently pretty overloaded selection for bicycle infrastructure into multiple quests, I would invest time and plan this, including the tags we should set.

How does this sound? 🤔

[westnordost]

Well, I did give a way forward. A redesign of the bike paths overlay and quest is quite orthogonal to what is being discussed here, in my opinion, because certainly, regardless of how you envision the UI could be redesigned, recording the width is going to be a separate quest in any case.

Just a few words on the suggestion itself: I reckon that (by now) there are really a lot of options available, thankfully, the (vastly) most-used ones are displayed at the top, so actually for most usages, your suggestion will result in more taps necessary to solve the quest/overlay. Remember, the surface-quest used to have the surfaces grouped, too, until it was dropped in favor of a plain thumbnail grid.

So, the best place for presenting a new UI concept would be the discussions forum. If you want to follow up on this further, please do so over there (the topic can be linked from here).