Talk:Proposed features/separation

From OpenStreetMap Wiki
Jump to navigation Jump to search

Incorrect claims

"so it is not possible to map e.g. Protected Bike Lanes in OSM."

It was possible to map them and I did it already. See for example equivalent of mapped at Due to physical separation from road - by bollards, and from footway - via high kerb mapping it via a separate way is fine Mateusz Konieczny (talk) 08:44, 2 February 2021 (UTC) are all cases where separate highway=cycleway geometry is preferable in my opinion Mateusz Konieczny (talk) 08:46, 2 February 2021 (UTC)
OK, I am getting confused. I see now "on separate cycleways" so you are aware of that tagging. So what was meant to be expressed by "it is not possible to map e.g. Protected Bike Lanes in OSM."? Mateusz Konieczny (talk) 08:48, 2 February 2021 (UTC)
What was meant by this was that there was no way to differentiate this "protected type" of cycle path from other cycle paths, for example for evaluations of the cycle path network, cycle path quality, etc. For cyclists, cycle maps, cycle navigation, cycle path analyses, etc. it is certainly interesting to be able to specifically query such "protected" paths of different kinds (e.g. protected by bollards, by kerbs, parked cars, no physical protection at all...). First and foremost, this scheme is an indicator for assessing the quality of a path, which is not only determined by width, surface, etc., but also by separation.
We are also not in complete agreement here in Berlin whether a bollard protection on a cycle lane is already sufficient to use a separate highway=cycleway line, as most bicyclists could theoretically change lanes at any time (I think mapping a separate line is absolutly fine in this case and did it for myself, but using lane tagging is fine as well). --Supaplex030 (talk) 14:04, 2 February 2021 (UTC)
@Supaplex030 - could you kindly update the statement in the RFC "Until now there are no documented or common tags for this, so it is not possible to map e.g. Protected Bike Lanes in OSM." to include this much better clarification? I think that would help avoid the confusion. --CycleStreets 20:17, 10 January 2022 (UTC)
See our presentation to SOTM 2019, which discusses in depth the fundamental issue here, which is that OSM understandably abstracts streets (which are spaces) as lines, leading to all kinds of compromises and edge-case issues: --CycleStreets 20:04, 10 January 2022 (UTC)
I changed that to " it was not possible to identify e.g. a protected bike lane by a specific attribute (whether mapped separately or a cycle lane at the highway line)." I hope that is better to avoid confusion. --Supaplex030 (talk) 20:45, 13 January 2022 (UTC)


Hi, nice proposal, I'll try to use it in Paris. About kerbs there is already the key kerb=* how does it conflict with this new scheme ? I'm thinking that key kerb=* could be seen as the specialization of separation=kerb. And we could use the key separation=* for every kind of road. --Florimondable (talk) 09:57, 2 February 2021 (UTC)

I think there is not much conflict between barrier=kerb (which is used as an indicator for a barrier, i.e. should not be used on the path itself, as it is possible to drive barrier-free there) and separation:*=kerb. In fact, strictly speaking, it is a duplication of data: The kerb as a line with barrier=kerb represents the actual kerb line at its actual location at the edge of the carriageway, and separation:*=kerb is an abstraction of that information at the cycle track line. However, as this information could otherwise only be extracted from the data with much difficulty, effort and error, it is a pragmatic approach to simplify this.
We are happy if the scheme will also be used elsewhere, and welcome feedback on whether it can be applied well to other cycle path locations and situations ;) --Supaplex030 (talk) 14:04, 2 February 2021 (UTC)
I'm talking more about the key itself kerb=* not the tag barrier=kerb.--Florimondable (talk) 14:30, 2 February 2021 (UTC)
Ah ok, but then there could be misunderstandings in the interpretation of the data, as the kerb=* key is mostly used at the "transition" of the kerb and as a specification of a barrier=kerb – and usualy refers to a kerb you have to pass on the element. Furthermore, this separation-scheme unites many other forms of separation such as bollards, vehicles, green strips. --Supaplex030 (talk) 14:41, 2 February 2021 (UTC)

Re: Forms of markings and symbolic separation

In Belgium, all cycle lanes have dashed lane markings - both the exclusive ones and the advisory ones. The exclusive ones have additionally to the dashed lane markings a continuos line.

Also, in Belgium, Fietsuggestriestrook have no line markings at all but a color.

Fietsuggestriestrook in Netherland and Belgium are similar to Schutzstreifen in Germany. The local community decided to tag those with cycleway=shared_lane to distinguish to "real" cycle lanes, because the dashed cycle lanes in Netherland and Belgium also exist, albeit have a little higher requirements than in other countries: As far as I understand it, as a car driver, when you encounter an obstacle and you need to avoid onto the dashed cycle lane to continue,

  • in Germany you may do that if you do not endanger a cyclist (f.e. force him to break hard, but it is okay if that means that he has to wait)
  • in Netherlands you may do that if there is no cyclist you may hinder. Just like as a pedestrian, you are allowed to cross a street if you don't hinder (car) traffic.

Also, the continuous line of exclusive cycle lanes becomes dashed at intersections. However, it is a different kind of dash than for advisory cycle lanes, it just demarks the place at intersections where cars will cross the exclusive cycle lane. It does not mean that for these sections, the same rules as for advisory cycle lanes apply. There is the danger that people will tag those sections as dashed with this proposal, which would be wrong.

All in all, this is the reason why the outcome of this forum discussion in 2018 was to not use directly the appearance of the lines that demarcate the lanes.

I'd suggest to drop that section in the proposal, because it aims to solve a problem (details on what type of cycleway) that has already been solved but with slightly different tags. I am not saying that the proposal is bad, just (in my opinion, for the reasons stated) a little worse what has been established now --Westnordost (talk) 14:01, 2 February 2021 (UTC)

Thank you for referring to this discussion, which I was not aware of. I will read through it later. My first thought, however, is that nevertheless, theoretically(!) there is nothing to be said against expressing it only with the type of marking. For other line types like dashed and solid at the same time, one could quickly define a value, tag colour by "surface:colour", etc. Maybee there is a need to take a closer look to junction areas and check the legal implications, but the markings are not interrupted without a reason (because one has to expect other vehicles) – but I'll later read the discussion and the arguments there. --Supaplex030 (talk) 14:16, 2 February 2021 (UTC)
Yes, please do read that topic. I just read it again real quick and realized that the current tagging recommendation regarding cycleway:lane is even much better researched than I remember it to be --Westnordost (talk) 14:26, 2 February 2021 (UTC)


The title of this section is meant as a hyperbole. My point is that the tagging-cycleway-on-roadway schema is creaking. It also becomes more and more difficult for data consumers to evaluate these tags. I speak from my own experience, StreetComplete interprets current cycleway(:left/right/both)=lane/track/... + cycleway:lane=... etc. to display it to its users and it is already now super complex:

With this complexity, and increasing, it is the question whether such detailed information will actually ever be used and interpreted the way it was intended anywhere.

Rather than stuffing even more detail into that, maybe rather establish as a rule that if the cycle track or lane is physically separated from the roadway (by any of the separations mentioned in this proposal, including parking cars), i.e. you cannot cross at any point, use a separate way with highway=cycleway instead. --Westnordost (talk) 14:12, 2 February 2021 (UTC)

I basically agree with you about the separation of the line elements, but have sometimes experienced resistance from other mappers. It would definitely simplify the possibilities of mapping detailed way information...
If you need more scary examples: This street here was mapped as an "extreme example", but it's only a normal cycle lane without physical separation:
I think to avoid mapping in great detail in order to keep the data structure "clear" is not a good approach – then we better have to think about better ways of data structure and view, data editing etc... On main roads with their many destination, turn:lanes, lanes attributes etc. we have the same problems... --Supaplex030 (talk) 14:33, 2 February 2021 (UTC)
Yes, the parsing problem is getting increasingly bad. And in general the use of a single line to represent multiple flows makes this unavoidably hard. See slide 15 of our presentation to SOTM 2019: --CycleStreets 20:04, 10 January 2022 (UTC)

How it interacts with cycleway=track/lane

So I was pleased to find there is a proposal on this topic, as I've spent many hours digging on how to resolve this issue. I'm trying to improve the representation of recent improvements to local cycle infrastructure here in London, much of which has been done with what tends to get called "light segregation" here (usually with what we call wands (flexible 'bollards' in the proposal's vocabulary) or armadillos (separation_kerb in the proposal).

So in general I welcome the proposal but with a few concerns:

  • Interaction with cycleway=track, cycleway=lane: I'm not clear whether the prime example (protected bike lane with bollards) would be tagged as a cycleway=track or a cycleway=lane (or a separate highway=cycleway way) - maybe it doesn't matter with this separation scheme? But some guidance would be useful.
  • Interaction with other cycleway tagging schemes: I think Westnordost's proposed(accepted?) cycleway:lane=exclusive/advisory/pictogram scheme has some crossover here as described above. In theory the two can co-exist but they are effectively redundant (at least, within each country).
  • Complexity: The scheme seems a bit overwhelming when the prime example is cycleway:right:separation:left=bollard. Even on just one main road here in south London, the geometry of the road means that the infrastructure type changes a lot, and it's already pretty exhausting to keep track of everything on lots of tiny road segments (e.g. here, which I'm still not happy I've tagged appropriately). Personally it would be helpful if there were a simplified option also available. Having to tag both sides of the lane seems like it is only necessary by exception, as perhaps if the cycleway isn't mapped as a separate way we can assume it is on the kerbside of the highway unless otherwise specified? In this case we can reduce the complexity to e.g. cycleway:left=lane and cycleway:left:separation=bollards.

TL;DR - I think it's a good idea but it's complicated to tag in full, so some simplified options would be helpful. --Tractiveeffort (talk) 21:19, 2 April 2021 (UTC)

    • Whether a protected cycle lane should be mapped as a separate line or at the highway line is an interesting question of principle on which we have not reached agreement even in our local community. However, this scheme here is independent of that and should work with either option. However, we could indeed discuss this question more broadly in the context of this proposal and come up with a suggestion. At the moment, however, I think there are a few other questions that should be clarified beforehand - you have already mentioned a few.
    • To me, "cycleway:lane" in its current use is a bit vague and focused on legal issues, which - as you mentioned - differ from country to country. This separation-scheme, on the other hand, tries to describe the physical structure of a cycleway without interpretation. With the separation scheme, "cycleway:lane" could theoretically become obsolete, as this value can be derived from the type of line (dotted, solid, symbol...) and the country in which a cycle path is located (maybe as well as some information on signposting: bicycle = designated).
    • What I have also been thinking about for a long time is a simplification of the scheme and I like your suggestion with "cycleway[:left/right]:separation" very much. That's how I had it in mind at the beginning, but after discussion in our local community, it became more complex, because we wanted to explicitly indicate not only the separation from the road/vehicles, but also - on the other side - from pedestrians, etc. In order to map a simple protected bike lane with a separation to the road side, however, there should definitely be a simple possibility. I will take your suggestion into the next discussion and maybe modify the proposal! --Supaplex030 (talk) 20:36, 7 April 2021 (UTC)
Not sure if the explanation on the main page is the correct way round? The simple one works (cycleway:separation=*) but the detailed version currently says: "cycleway:separation:left and cycleway:separation:right on road ways (with cycleway=*) or separation:left and separation:right on separate cycleways (highway=cycleway)" but wouldn't it be "cycleway:left:separation" and "cycleway:right:separation" on road ways?
i.e. there is a hierarchy of complexity whereby:
** if one value is provided then it is assumed to be the separation from traffic / on the side nearest the road centreline (cycleway:separation=bollard);
** if there are different cycleway options on either side of a road way then you get e.g. cycleway:left:separation=bollard;
** if you want to go all out then you can optionally distinguish the separation from the non-traffic side e.g. cycleway:left:separation:[left/right]=*
** for highway=cycleway ways, separation=* would be interpreted to be on the road/traffic side of the way by default
** otherwise you can specify separation:left=* and separation:right=*
Going through this does make me worry a bit that separation:left/right will be ambiguous - it's already hard to get your head around cycleway:left/right in relation to the way, but then doubly so to do it for the separation (particularly on road ways, e.g. in the UK a way with forward as northbound could have a cycleway:right=lane going southbound, but cycleway:right:separation:left would refer to the traffic side (in the direction of the way) but the cyclist would always see it as right.
--Tractiveeffort (talk) 10:37, 17 May 2021 (UTC)
Sorry, I've planned to prepare schematic illustrations for a few weeks, but I haven't got to it yet... Maybe they will make it clearer how "left" and "right" are meant/should be used.
--Supaplex030 (talk) 13:19, 2 August 2021 (UTC)

Other separation values

I'm trying to tag a cycleway that's separated from vehicle traffic by the green part of this bridge: (I don't seem to have permission to upload photos to wiki, sorry.) For the moment, I've called this railing, but that's not a great fit. Any suggestions? bridge_arch? For reference, this can be found at --Dabreegster (talk) 17:05, 27 July 2021 (UTC)

This is a good question, which probably also arises in other places and with other "structures".We should avoid choosing terms that are too specific, as such categories can no longer be meaningfully evaluated. A generic term could help in such cases: How about structure or similar? (could also be used if, for example, street furniture, bicycle stands or other things are by the wayside). Or does anyone have a better generic term for "physical barrier of any other kind"?
--Supaplex030 (talk) 13:19, 2 August 2021 (UTC)
I like structure as a generic term. Not sure I've seen any examples of street furniture separating a cycleway from traffic yet, but I'd prefer if that had a different category. To me, structure implies strong, almost immovable physical separation. Street furniture might have people on foot trying to sit on benches, use rubbish bins, etc and potentially intersecting the path of the cycleway users. -- Dabreegster (talk) 16:23, 2 August 2021 (UTC)
Yes, that's true - street furniture and similar objects are something different and one must always expect crossing pedestrians or users of the objects/street furniture. Maybe a separate value like street_furniture is unnecessary anyway...
But I will look for a photo for structure and document the value when I have time.
--Supaplex030 (talk) 18:53, 2 August 2021 (UTC)
There is also hybrid provision separated by slightly different height:, including the 'Cambridge kerb': as detailed here: --CycleStreets 20:08, 10 January 2022 (UTC)
Isn't that something like a lowered kerb? Similar to what is common in Copenhagen? I think I would simply map it with kerb on both sides (or would an addition like *kerb=lowered make sense?). I'm not sure if a stand-alone value would be useful for this... --Supaplex030 (talk) 20:51, 13 January 2022 (UTC)

Bollard vs flexible panel

Thanks for putting this together. I was wondering about the distinction between bollards and vertical panels. The text describing bollards mentions that this tag can be used for flexible posts as well, and so I wonder what distinguishes the panel from a bollard. I guess it is the shape of the panel (rectangular versus round)? If that is the distinction, I wonder if it'd be better to tag both types as bollards and then specify the difference in bollard=? --Hobbesvsboyle (talk) 17:28, 5 August 2021 (UTC)

The proposal is probably a bit underdeveloped at this point. I think that an important difference between bollards and panels might be the "symbolic massiveness": bollards usually appear as larger, stronger, more difficult to override barriers than panels, which often give a more flexible or temporary impression. This goes hand in hand with a different sense of security, for example. In individual cases, however, this can be different, so it might be worth considering further attributes for flexibility (bollard=flexible for bollards still in use – vertical_panel=flexible might be default) or the height of the barriers (separation:height=*?).
--Supaplex030 (talk) 18:57, 5 August 2021 (UTC)
Right, the "sense of protection" I think is was prompted my comment. Here in the US, plastic "flex posts" are commonly used, and because they often only survive a short period of time until they're run over by motor vehicles, some people refer to them as "vertical paint" and few people would refer to them as bollards. I looked at NACTO design guidance for bike facilities, and they distinguish between "bollards" and "flexible delineators". The distance between the bollards/delineators may be another piece of information to capture. --Hobbesvsboyle (talk) 19:17, 5 August 2021 (UTC)
Do you think it makes sense to introduce an additional value for these flexible posts/delineators to distinguish them from bollards? Then it would be easy to distinguish directly between bollards as a massive variant and flex posts/delineators as a flexible variant. I would prefer the value flex_post, as it is already used a few times and delineator is American English (but OSM actually prefers British English :)
--Supaplex030 (talk) 19:32, 5 August 2021 (UTC)
flex_post certainly would be well understood and commonly used in the US context. We need a better word for "massive" for the bollards (German "massiv" as the opposite of "flexibel" or "hohl" doesn't quite work the same way in English. "Massive" refers to size, and so people could be confused about a slender, but very sturdy steel bollard). But maybe the inflexible version of the bollard is the default assumption (with the additional tags you suggested such as height) and then we just have the specific value for bollard=flex_post. Are you thinking then we'd still have a separate value for the vertical panels? I guess the proper German term is "Bake," but I don't know how widespread these are outside of Germany and maybe France (balises routières). So maybe Baken would be tagged as flex_post --Hobbesvsboyle (talk) 19:57, 5 August 2021 (UTC)
Ah, no, I actually meant flex_post as a new value directly for *separation*=*. Then you don't have to use sub-attributes (which are certainly rarely, if ever, evaluated) and "bollard" could be used only for the fixed (DE: "massiven") kinds of bollards...
According to my experience and the pictures I have seen from other cities, I would still think of bollards, flex_posts and vertical_panels as typical, but different forms of separation (as well as planter or parking_lane etc.) and therefore keep all values separate. Maybe it's just a European thing...
--Supaplex030 (talk) 20:21, 5 August 2021 (UTC)
I disagree with this. barrier=bollard + ~800 bollard=flexible / ~46.7k bollard=fixed are used around the world, showing they are both considered a barrier=bollard. --- Kovposch (talk) 10:14, 3 August 2022 (UTC)
These armadillos close one lane of the road, which has no bike lanes.

The flexible plastic posts are sometimes called bollards if they're tubular. [1] It's one of several nontraditional kinds of plastic barriers that are increasingly showing up in U.S. cities. That article also mentions "armadillos", which you're calling "separation kerbs" but can accompany any crosshatch markings on the road, not necessarily to serve as a curb. Another one that's common in the San Francisco area is plastic bollards that look more substantial but aren't. [2] – Minh Nguyễn 💬 07:17, 16 May 2022 (UTC)

We have recently been in contact with a group that does a lot of work on Protected Bike Lanes, with contacts around the world who want to use OpenData for cycling analysis (the Institute for Transportation & Development Policy/ITDP from New York). Through this exchange, we could lightly rework the categories again in a practice-oriented way where it seems necessary. They have also suggested to distinguish easily traversable "Armadillos" from the more difficult traversable forms of "separation_kerbs". (separation_kerb is so far rather a generic term for a wide range of types of different "small" separation objects that can be found all over the world). --Supaplex030 (talk) 11:02, 21 May 2022 (UTC)

small metal panels on the ground

Quantiasstaße bike lane.jpg

I have found the following type of lane separation and I don't believe any of the proposed values currently cover it. It consists of small metal panels mounted to the ground.
--Popball (talk) 20:21, 2 August 2022 (UTC)

This is included in the broader sense of vertical_panel so far. We have already thought about how to specify this further, for example, by specifying a height for the elements (separation:height would be a proposed key for this). However, we try to keep the list of separation values rather simple, so that not every special type of construction has to be given a new term, but rather describe "classes" of elements that can differ in shape and size (and thus possibly also in their "passability"/protection quality, so that data like height should be taken into account for quality evaluation.). -- Supaplex030 (talk) 20:32, 2 August 2022 (UTC)

--Popball (talk) 20:48, 2 August 2022 (UTC)

Consistency with other features

Although it is said there is a desire to avoid sub-tagging, main thing I don't like about this is the insufficient uniformity with barrier=* and other tags. Aside from *=bollard above:

From my typo, I realized you use plural *=dots but singular marking=*. They should be standardized. --- Kovposch (talk) 10:50, 3 August 2022 (UTC)

Thank you for your detailed feedback! The values are currently under revision and I think your suggestions are very helpful. In detail, the following was discussed recently:
  • bollard/flex_post/vertical_panel: These might be merged into one category (bollard), but this comes with the disadvantage that additional attributes such as separation:<side>:bollard=fixed/flexible and separation:height would then be necessary to meaningfully evaluate the "grade"/quality of the separation. So far, these three values seem to cover "typical" separations worldwide without having to use additional attributes. I think we need to discuss and test further here.
  • dots: We are planning to rename it studs (as you said: It could otherwise be confused with markings).
  • lane_separator: This is a different category that is not in use in either barrier=* or traffic_calming=*, I think. They are more than a common bump, and something other than a kerb. They should get their own term, even if we are still unsure which one is the most appropriate. "lane_separator" seems to be a common technical/professional term - but might be misleading. The term ...kerb should also be avoided, to not be confused with regular kerbs... Maybee something with "...bump" is ok, but needs an addition. (traffic_calming=* knows mini_bumps, but nothing like heavy_bump...)
  • parking_lane and railing: Rename it parking and fence makes sense. I think we should do that, for simplification and generalisation.
  • grass_verge: We should use greenery (as used in landcover=* or landuse=*).
  • tree_row: We should distinguish rows of trees from greenery (=continuous green areas), and they have a different "symbolic" separating effect. The tag should of course only be used when trees are regularly spaced, not too far apart (so that they have a kind of symbolic, traffic-directing effect/create a space that can not used for flowing traffic). hedge, flowerbeds etc. are greenery (see above).
  • psv_lane: Not sure here either - need to discuss/test further. Maybee something like lane is a good idea - or we better avoid a value of this kind and use the traffic_mode scheme instead.
-- Supaplex030 (talk) 12:15, 3 August 2022 (UTC)

Markings, surfacing, and mixing

  • *=pictogram: Doubt this is a "separation" as it is painted in the middle of the traveled space. Something else should be used. Especially as illustrated, pictograms are commonly found together with other markings.
  • *=surface: It looks more separated by parking on the left, and flush kerb on the right. What about colored lanes? Not necessarily different material, can be different paint. This is more cycleway:surface=*.
  • *=barred_area: *=hatching or hatched_area=* would be more standard terminology. However, this can actually be tagged under cycleway:buffer=* as eg cycleway:buffer:markings=*, as this is commonly found along other physical obstacles, seen in your example photos. By the same logic, other markings can fall under a cycleway:markings=*. This avoids cluttering separation=*. The information of *=markings is already enough to convey the message of no physical separation. They can then be tagged together with other obstacles.

In general, I find that suggestions to mix eg *=kerb;parking_lane and *=grass_verge;tree_row is counterproductive to the goal of identifying the most relevant separation, and against the want to avoid sub-tagging (you are basically working around by multivalue). Those examples can be kerb=* + *=parking:lane and verge=* + *=tree_row respectively, relying on other tags. There is no need or benefit to squeeze every attribute in this tag.
--- Kovposch (talk) 11:03, 3 August 2022 (UTC)

The marking scheme can be seen as a completely separate scheme/proposal from separation. It is listed here mainly for historical reasons, as the markings were values of separation until recently. If the proposal reaches a more advanced status, it should be split up.
And the mixing of tags with semicolons.... Do you want to leave it to the subjective feeling of the mappers what is the "most relevant", e.g. when there is a kerb + greenery + tree_row? On the other hand, uses with semicolons are comparatively rare so far (see e.g. here)...
-- Supaplex030 (talk) 12:28, 3 August 2022 (UTC)
For *=greenery, grass and flowers can be easier to discard, but hedge would be more difficult to choose. Although less massive, it is more continuous and reliable than trees.
Independent of *=kerb and *=tree_row in separation=*, there is kerb=* and tree_lined=*. Both of them are commonly found along any street. 7 example photos have trees on the right. That's why I feel they are less high priority than *=greenery to tag here. These individual tags may be expected for users and applications to handle.
Another issue for *=kerb is whether kerb=flush qualifies as at least some symbolic demarcation. kerb=raised vs kerb=lowered is quite different too. So I won't avoid these standalone tags.
Besides, kerb=* or cycleway:kerb=* is as easy if not easier to enter than cycleway:separation=kerb, while allowing the kerb to be specified. If there is no cycleway:separation=* tagged, cycleway:separation:right=kerb (RHT) may somehow be assumed with kerb=*. This further allows users focusing on kerbing on the roadway to contribute to bikeways at the same time. The same may be assumed for tree_lined=* without cycleway:separation=* as cycleway:separation:right=tree_row, drawing in landscaping-focused users.
For your question, I would choose *=greenery if hedge, and *=tree_row if grass or flowers here. Moreover, grass verge is commonly found on trees planting belts, when they are not individual tree pits. --- --- Kovposch (talk) 05:36, 5 August 2022 (UTC)