Proposal talk: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 https://wiki.openstreetmap.org/wiki/File:PBL_Hasenheide.jpg mapped at https://www.openstreetmap.org/?mlat=50.05815&mlon=19.94369#map=19/50.05815/19.94369 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)

https://wiki.openstreetmap.org/wiki/File:Hornby_Separated_Bike_Lane.jpg https://wiki.openstreetmap.org/wiki/File:Cycleway_separation_kerb_Berlin_Neuk%C3%B6lln_Eschersheimer_Stra%C3%9Fe.jpg https://wiki.openstreetmap.org/wiki/File:Seichamps_-_Route_de_Pulnoy.JPG https://wiki.openstreetmap.org/wiki/File:Vleutensebaan_Utrecht_2019.jpg https://wiki.openstreetmap.org/wiki/File:Cycleway_grass_verge_separation_Berlin_Neuk%C3%B6lln.jpg https://wiki.openstreetmap.org/wiki/File:PapendrechtWitteBrug12.jpg 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: https://www.cyclestreets.org/news/2019/09/22/sotm2019/ --CycleStreets 20:04, 10 January 2022 (UTC)
I changed that to "...so 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)

Kerbs

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 https://forum.openstreetmap.org/viewtopic.php?id=61427 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)

cycleway:left:lane:separation:width

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: https://www.openstreetmap.org/way/782822228
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: https://www.cyclestreets.org/wp-content/uploads/sotm2019cyclestreets.pdf --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: https://imgur.com/a/hhq0e4k (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 https://www.openstreetmap.org/way/835195089. --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: https://www.camcycle.org.uk/images/magazine/newsletter74/images/hybrid_lanes_03.jpg, including the 'Cambridge kerb': https://www.cyclestreets.net/location/82798/ as detailed here: https://www.camcycle.org.uk/magazine/newsletter123/article14/ --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)
Resolved

--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)

Relation with segregated=*

Isn’t that proposal about choosing standard values for segregated=*? What’s the difference between the two keys? --Lejun (talk) 10:52, 20 October 2022 (UTC)

segregated=* is used on shared paths for pedestrians and cyclists to describe whether or not they can each use a separate area or share the space. This is a very narrowly defined scope. segregated=yes almost never means a physical barrier, but usually only symbolic delimitations such as line markings.
separation=*, on the other hand, describes physical barriers, e.g. bollards between traffic areas. It is primarily intended for cycle paths but can be used on every way/path/road/lane. The example pictures in the proposal should give you an idea of what it is useful for. --Supaplex030 (talk) 18:47, 20 October 2022 (UTC)

Maximum spacing between separators?

For separators that are discrete objects (flex-posts, bollards, certain types of bumps, etc), there must be at least a certain maximum spacing between these separators for them to be effective at providing protection to people riding bicycles. For example, a 'protected' lane with a bollard only once every 10 meters is effectively only a painted lane.

I can imagine two ways of specifying the spacing of separation features in this schema: 1. separation:spacing=x for the spacing between features measured in meters, leaving the data consumer to decide what is a 'safe' level of separation 2. Setting a maximum standard of separation as part of the schema. I'm not sure exactly what that standard should be yet - we should discuss with other subject-matter experts. If there is a cycleway with separation features that are more widely spaced than that maximum standard, it could either be tagged as separation=no or it could be split into multiple consecutive ways with different separation values.

I tend to prefer option 2. I think it will be easier for both tagging and for data consumption. Thoughts? --Taylor-itdp (talk) 16:25, 16 November 2022 (UTC)

  1. There is already opening=* and spacing=* in the transverse barrier=cycle_barrier. Longitudinally, the length would be the "opening"; the width the "spacing". This matches the terminology for median openings. "Spacing" here can be interpreted as the separation between the 2 parallel ways provided by the obstacle, rather than the gaps on the line of obstacle.
  2. separation=no shouldn't be used, when it already means there is no obstacle at all. Proposed_features/separation#Proposal has "level of protection". separation=* was protection=* before. If acceptable, we may suggest to redefine protection=* to specify the functionality qualitatively, when it is not sufficiently described by separation=*. Furthermore, a "no" for what? As touched upon in recent discussion of shoulder=*, I find it would be more useful to define it by vehicles. Vague adjectives aren't descriptive words. Different lengths work differently for bikes, motorcycles, cars or vans, and heavy vehicles. Which direction does it mean? In vehicle restraint systems or ramming attack protections, you have to consider the vehicle. Bollards or non-continuous blocks may not obstruct bikes and motorcycles.
--- Kovposch (talk) 07:24, 17 November 2022 (UTC)
Micromapping dimensions of separation elements.
I prefer to tag "physical dimensions", as everything else requires a rather subjective interpretation and, as Kovposch already argued, this also depends on factors such as speed or vehicle types.
I just made an illustration with tagging suggestions that I consider intuitive. The use of spacing=* ("distance between elements") can be adapted well, in my opinion. I also proposed separation:margin to distinguish the width of the buffer (marked with white stripe markings in the example) and the distance between the cycleway and the separation elements. height=*, length=* and width=* can be used to specify the elements dimensions if necessary (or diameter=*, e.g. for bollards).
I know situations where there are some separation elements at the beginning and at the end of a street segment, and in between, e.g. for 100 metres, there is no separation at all. In this case, I would indeed argue that there is no separation (and you could map the start and end points separately with a separation if you want to micromap them).
@Taylor-itdp:, are you aware of any edge cases where we could test/discuss such tagging? --Supaplex030 (talk) 15:04, 17 November 2022 (UTC)

Feedback based on a real world application

I took the suggested tagging and mapped it on the most convoluted quarter mile of bike infrastructure I've seen which I documented on my personal Talk page as I worked through the process here are my thoughts and one related item. --- JPinAR (talk)

cycleway=lane is broken within OSM in it's present state

First, I will say that I went in a bit skeptical as the tagging on cycleway=lane is becoming overly verbose. So before I get into this my review of :separation I wanted to call out that cycleway=lane is somewhat busted namely because lane=* placing cycle lanes and parking into and excluded category. This motor vehicles are the only ones that get lanes approach has two major caveats with respect to bicycle mapping which break things.

I'd like to use third example under the Tagging on roads, lanes and other ways section to explain the issue that excluding any lane of traffic causes. First lets setup the problem them break down possible solutions. The problem here is that we have a bike lane between two lanes of traffic that we want to tag in the example though lanes=3 is specified but then a matrix of five lanes is provided. From a routing implementation perspective I would see lanes=3 and simply expect a three wide matrix and potentially ignore the rest which would yield some 'interesting' results.

To make the matrix method more consumable I've turned the values in the example into a table with this we can see the advantages of a matrix with the ability to consolidate all the various values by lane.

Radfahrstreifen in Mittellage Holzmarktstraße Mitte Example
Tag Lane 1 Lane 2 Lane 3 Lane 4 Lane 5
cycleway:lanes none none lane none lane
bicycle:lanes no no designated no designated
vehicle:lanes yes yes no yes no
turn:lanes left;through through through right right
cycleway:separation:left:lanes studs no
cycleway:separation:right:lanes no kerb
cycleway:marking:left:lanes solid_line solid_line
cycleway:marking:right:lanes solid_line

Solutions?

  1. We need a way to gracefully move cycleway and parking lanes out of the lanes excluded category so that the above matrix layout can makes sense
  • A possible way of doing this is introducing a total_lanes=* tag that implies there are more lanes than just vehicle lanes so rendering and routing know to look for more columns in a matrix
  • Using the example about you could have total_lanes=5 + lanes:cycleway=2 then you have: lanes:cycleway=2 + lanes=3 = total_lanes=5
  • I'm also wandering it if there might be a need for something between yes and no to indicate that crossing/merging across a lane typically reserved is permitted?
  1. If the above it to much to handle then we need to address turn lanes crossing over cycle lanes

--- JPinAR (talk)

1. It was simply intended to preserve backward compatibility in lanes=*. Not sure if there is a need to have a sum.
From lanes=* "the following lanes should be excluded... Bicycle lanes. Use the tag cycleway=lane for those." From my reading of this cycleway at present can not be counted as a "lane" with respect to the matrix style notation --- JPinAR (talk)
1.1. Could simply use eg lanes:vehicle=*. total_lanes=* would be a completely new format.
I realize that, "total_lanes=* would be a completely new format," but but to your point about "preserv[ing] backward compatibility," the only other way I would know to address this would be to challenge the exclusion of cycleway=* and probably parking:lane=* as well in order to make a matrix style notation like provided in the example add up properly. Which is definitely not the most 'backwards compatible' approach but might be the one that provides the correct amount of consistency that addresses cycleway=lane as an equal lane to a vehicle lane. This would address a lot of the issues that the addition of cycleway=* to a way as an after though doesn't address like cycle lanes between traffic lanes without the tagging becoming overly bloated like cycleway:right:separation:left:width=* what are we now 4 suffixes deep now where a matrix with a cycleway as a lane removes two of these? --- JPinAR (talk)
1.2. What's the difference with lanes:bicycle=*? Although it is true the meaning of lanes:*=* in terms of reserved vs shared lanes, usability from other modes, and how it sums up to the total lanes=* for lanes:bus=*.
I see your point since lanes can serve dual purposes the found of lanes:*=* can exceed the number of lanes=* but this doesn't remove that cycleway and cycleway=* and parking:lane=* don't get included in the lanes=* count and therefore you end up with more matrix-lane columns than you have lanes which causes problems with both rendering and routing expectations. --- JPinAR (talk)
1.3. Difference with change:lanes=* ?
I don't think change:lanes=* addresses this fully let me use a different better example from the lanes page, which also ironically has more lanes listed in the matrix than the listed lanes=3 implies...
Kreuzung mit Radspur.jpg
 lanes=3
 turn:lanes=left|through|through|right
 vehicle:lanes=yes|yes|no|yes
 bicycle:lanes=yes|no|designated|yes
 cycleway:lanes=no|no|lane|no
If I'm a routing software and I'm wanting the driver in the second from the left through lane to get over into the right turn lane I'd be moving from a vehicle:lanes=yes lane across a vehicle:lanes=no lane which I'm not supposed to be able to do because, well... vehicle:lanes=no! As a human it is intuitive that this is permitted but as a computer this is a binary and there isn't a way to reach the right turn lane because I'm not allowed as a vehicle in the third from the left hand lane as it is clearly marked vehicle:lanes=no to my knowledge there isn't an "only passing through or when traversing" indicator as an alternative. --- JPinAR (talk)
2. This is more unworkable. What's the problem with turn:lanes=* again?
The issue here is that presuming a cycleway=lane remains excluded as a traffic lane and therefore matrix styles lane management is not considered a viable option then you are left with cycleway=lane this implies a lane on the :left and :right edges of the road. Both cycleway:right=lane and cycleway:left=lane have the same issue they only are on the edge of the road. The issue here is that always being defined on an outside edge means a cycleway=* can never exist anywhere not on the edge of a road. Like for instance in the examples above between a through and right/left turn lane (which ever side lines up with driving_side=*). The only use cases, for now, that I'm aware of where a cycleway=lane can exist not on the edge of a road are when turn:lanes=* cross over the cycleway. This is largely done for safety as you typically don't want through cycle traffic along side a turn lane as motorist tend to only look toward oncoming traffic and not for a through route to the opposite side of on coming traffic. These instances where the turn lanes cross over the cycleway typically have two phases a dashed yield-cross section followed by a solid crossing no longer permitted section, hence cycleway=turn_lane_crossing and cycleway=turn_lane_crossed respectively. --- JPinAR (talk)
Not totally on point: have you looked into placement=transition and type=connectivity?
--- Kovposch (talk) 10:05, 30 November 2022 (UTC)
I don't think placement=transition captures the two-phase approach for turn lanes crossing it could maybe work for cycleway=turn_lane:transition but not the other which seems clunky I like the idea though. type=connectivity would address the opportunity listed in the #A_parallel_example_from_my_real_world_tagging section below, except not entirely. I'll explain under that section.

A parallel example from my real world tagging

From way 1065994301 to way 1065994305 with only a node between them the ways transition from:

cycleway:right=lane
cycleway:right:bicycle=yes
cycleway:right:oneway=no
cycleway:right:separation=bump

to...

cycleway=lane
cycleway:bicycle=yes
cycleway:left:separation=bump
cycleway:right:marking=solid_line

Before clicking the Mapillary link here try and figure out what the intersection looks like and see if you or a OSM router can figure out the transition. This works well for ways but not as much for describing intersections. (Heading one direction you have bumps to your left then they disappear, but from the other direction you have bump separation to your left and then suddenly they are on your right, right?) --- JPinAR (talk)

What's the problem with this? --- Kovposch (talk) 10:05, 30 November 2022 (UTC)
You made an interesting point above with type=connectivity which kind of setups up the issue here well. If cycleways were counted as lanes and cycleway=lanes of different directions and treated as distinct lanes like vehicle lanes are, then way 1065994301 would have:
1) lane:backward 2) lane:forward 3) cycleway:lane:backward 4) cycleway:lane:forward
and way 1065994305 would have:
1) cycleway:lane:backward 2) lane:backward 3) lane:forward 4) cycleway:lane:forward
Then a type=connectivity from way 1065994301 to way 1065994305 would read connectivity=1:2|2:3|3:1
"The problem" is that this solution only works given two starting assumptions: that cycleway=lane is treated lanes=*, which as discussed above is not the case; and that one cycleway=lane is identified per direction like is done with lanes=* which is likewise not done because cycleway:oneway=no is uses to indicate two bi-directional lanes that get counted as one lane attached to the edges of roads but not even equal treatment as lanes of traffic as part of the road which is why so many of the tools like type=connectivity that would be perfect solutions for problems like this simply are not possibilities because bicycles are not afforded equal treatment as a form of traffic or transportation. --- JPinAR (talk)

Seasonable separation

This is matter than came up during a recent local discussion about the handling of separation during snow events it turns out the further north you go the greater the likelihood that separation might be removed for the snow season. See and article here on how to remove and winterize your retractable bollards. It's possible that seasonal=* or intermittent=* might need to be included to address separation that is not always present. (It sounds like the cost of replacement of damaged separation adds up enough to justifies removable.) --- JPinAR (talk)

Existing is separation:*:conditional=* @ (snow). seasonal=* and intermittent=* haven't been used within widely yet. --- Kovposch (talk) 10:05, 30 November 2022 (UTC)
I think this is a better and to your point more widely adopted solution! --- JPinAR (talk)

Simplification

I really like this idea of being able to add this information for cycleways. The main thing I believe determines the quality of cycle infrastructure is:

  1. its separation from motor traffic
  2. its separation from pedestrians

I think a lot of the complication of this proposal comes from using direction for separation instead of modes for separation. For example: 

 highway=cycleway
 foot=designated
 traffic_mode:left=motor_vehicle
 separation:left=kerb
 traffic_mode:right=foot
 marking:right=solid_line

Is more complicated to read, understand and parse than: 

 highway=cycleway
 foot=designated
 separation:carriageway=kerb
 separation:modes=solid_line or separation:bicycle:foot=solid_line

(key names are just examples, not my actual proposal)

But it conveys they same important information to cyclists and pedestrians.

I also think there is no need to differentiate between "markings" and "separation". They are both intended to keep modes apart, it should be up to data consumers to determine which are preferred.

I think this proposal should be targeted at only foot and bicycle modes, and not worry about other modes. My feeling is that users of other modes don't care about the separation as much as cyclists and pedestrians do, and keeping it complicates the proposal.

  • separation:*=* : Something needs to be clearly reserved for raised physical separations. Applications can't be expected to understand every separation:*=* to tell whether they are markings forever. The existence of separation:*=yes allowed by this definition enables users to specify something useful exists there first.
  • marking:*=* : It can be important to consider delineators and markings togethers. If you look at the example photos, widely spaced discontinuous delineators or other street furniture can placed on a line, or inside a buffer. Then a wider buffer arguably provides more comfort than the few narrow point-size obstacles.
  • traffic_mode:*=* : The significance is on bordering bus, parking, and no motorized traffic. Furthermore, *:carriageway=* is unclear on whether it refers to travel lanes, or the entirely paved roadway paving including edges and parking (bays), cf same problem with width:carriageway=* . separation:modes=* doesn't work with multiple modes. separation:bicycle:foot=* is more disorganized and confusing.
—— Kovposch (talk) 10:36, 24 July 2023 (UTC)

Area relation

The Proposal:Area relation can do this as well. —Dieterdreist (talk) 11:51, 1 December 2023 (UTC)

Intersection with separately mapped sidewalks and a cycle track turning into a lane and back into a track

A question about a separately mapped mixed mode cycle track which turns into a cycle way plus separate sidewalk in front of the intersection and merges again after intersections was asked at the forum ([3]). One answer [4] suggests to simply use separation=* instead of short links between the side path and the main road. Is this usage covered and intended by the proposal? Can we have an detailed tagging example for those common intersections, please. Thanks --Skyper (talk) 19:27, 27 May 2024 (UTC)

rumble strip

I think a value is missing for rumble strip as separation

https://panoramax.openstreetmap.fr/#background=streets&focus=pic&map=18.36/43.54682/-80.216713&pic=c5fcd68a-f37d-46dc-b2dd-d182ca15a340&speed=250&xyz=305.00/0.00/30

--Westnordost (talk) 14:17, 17 September 2024 (UTC)

Good point. Just like with “studs”, I'm not sure whether this form of separation is already “physical” enough. Maybee it's more a form of "marking"? This proposal page also describes a tagging variant for this, i.e. marking:*=studs/rumple_strip. Or would you rather see such forms in the separation namespace? Supaplex030 (talk) 18:20, 17 September 2024 (UTC)
FWIW, I think it would make sense to rather have some general categories of separation types rather than many (many) specific values because otherwise we will keep on finding new kinds of separation and this would be bad for data users (and data editors). E.g. fence and jersey barriers would go into one category (solid barrier), bollards and planters into another (uh... permeable-by-cyclists-barrier), any kind of bump, slope, dots ... in another, etc. --Westnordost (talk) 18:32, 17 September 2024 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Separation&oldid=2757081"