Proposal:Advanced cycle barrier tagging
| Advanced cycle barrier tagging | |
|---|---|
| Proposal status: | Approved (active) |
| Proposed by: | Supaplex030 |
| Tagging: | cycle_barrier=*, cycle_barrier:installation=*, corners=*, deflection=*, spacing=*, opening=* and overlap=*=* |
| Applies to: | 
|
| Definition: | Type, design, size and width specifications for cycle barriers – i.e. barriers along a path that slows or prevents access for bicycle users. |
| Draft started: | 2021-06-11 |
| RFC start: | 2021-07-12 |
| Vote start: | 2021-08-02 |
| Vote end: | 2021-08-16 |
Proposal
This proposal aims to extend the tagging for cycle barriers in order to determine the passability of this kind of barriers for different vehicle types, especially cargo bikes, bikes with trailers or wheelchairs. Necessary for this are:
- a classification of different types / designs of cycle barriers:
- for the structural design of the barriers (cycle_barrier=*, in special cases additionally corners=* and deflection=*), and
- for information on whether a barrier can be removed, folded or similar for emergency or service vehicles (cycle_barrier:installation=*),
- as well as a tagging for the dimensions of cycle barriers (see illustration on the right) – for
- the distance between the grids (spacing=*),
- the opening width (opening=*) and
- the overlapping of the grids (overlap=*).
Rationale
Cycle barriers (also known as pedestrian chicanes) can be a significant obstacle for cyclists, especially with trailers or cargo bikes, but also for people in wheelchairs – or even make a path completely impassable for such user groups, even if e.g. cycling on a path is actually permitted. Whether such barriers are passable by a vehicle with certain dimensions (width, length) depends on the distances and passage widths of the grids/bars of the barrier. Because of the wide variety of different cargo bikes, bicycles, trailers or even wheelchairs, access tags such as cargo_bike=*, bicycle=* or wheelchair=* are not sufficient.
However, determining the passability of such barriers for a vehicle is much more complicated than for other barriers such as bollards or gates, since – depending on the type or design of a cycle barrier – specifying a maximum width is usually not sufficient. Rather, several geometric types, distances and dimensions have to be taken into account.
Tagging
Types / designs of cycle barriers
The key cycle_barrier=* can be used to distinguish the basic construction forms of cycle barriers – each with certain effects on their passability or the dimensions and distances necessary to determine the passability. It's a textual expression for typical, commonly found construction designs.
It corresponds to a value for the corners=* that – geometrically speaking – must be driven when passing through the barrier. These can be specified additionally, although this key is mainly intended to describe special shapes geometrically in more detail and normally doesn't have to be mapped. corners=* counts hard, right-angled turns with effects on passability (~ 90°, see the numbers in the schematic figures below), but not soft ones like you may drive on diagonal barriers with little or no effects on passability.
Use deflection=* on diagonal barriers to indicate the angle (in degrees) you have to deflect from the direction of travel/line of the path to pass through the barrier. This key is also possible at barriers with other designs, but usually results from the design type values: For "corner-free" designs, the deflection is 0, otherwise 90.
| cycle_barrier=* | Picture | Schematic illustration | corners=* default value | Dimensions necessary to determine passability |
|---|---|---|---|---|
| single |  |
 |
0 | maxwidth:physical=* |
| double |  |
 |
2 | spacing=* opening=* (only the smallest of the two) overlap=* |
| triple |  |
 |
4 | spacing=* (only the smallest of the two) opening=* (only the smallest of the three) overlap=* |
| diagonal |  |
 |
0 | maxwidth:physical=* is usually sufficient. Use deflection=* to indicate the angle (in degrees) you have to deflect from the direction of travel/line of the path to pass through the barrier. |
| squeeze |  |
 |
0 | maxwidth:physical=*, measured at about the height of a bicycle handlebar. Consider indicating the tilting angle of the barrier elements with tilt=*. |
Installation
Similar to bollards, cycle barriers can in some cases also be removable (or in case of cycle barriers more common: openable) to allow the passage of e.g. emergency services or winter road maintenance. Such installation forms can be specified with cycle_barrier:installation=*. The pictures below show examples for fixed, removable and openable models – foldable installations, like we know from bollard=*, might also exist.
| cycle_barrier:installation=* | Picture | Description |
|---|---|---|
| fixed |  |
Barrier with bars/poles fixed to the ground (often set in concrete) so that the barrier can't be removed or opened. |
| removable |  |
Barrier can be removed (usually with a key). In the case shown in the photo, the barrier can be lifted out of its mounting (as known from bollards). |
| openable |  |
Barrier can be opened (usually with a key) – a common mechanism are hinged bars that can be folded upwards. |
| openable |  |
Barrier can be opened (usually with a key) – in this case, it can be opened like a common swing gate. |
Dimensions / distances
The dimensions of cycle barriers can be tagged with...
- spacing=* for the distance between the grids,
- opening=* for the (smallest) opening or passage width of the grid elements,
- overlap=* for the overlap of adjacent grid elements.
These three values should be specified in metres (e.g. spacing=1.4) following the existing specification on tagging metric values like width values. If the opening/passage widths of individual grid elements or the distances between the grids are different, only the smallest of these distances should be tagged since the smallest distance will determine the general passability (Example: If the "entrance" is 3 m wide and the "exit" only 2 m, use opening=2).
If the grid elements do not overlap, use a negative value for the "open" space between the grids (see the examples below). If you want to keep it simple, just use overlap=no; however, this value is not very accurate in case of doubt.
For simple types / designs of cycle barriers, simply specifying a maximum width with the existing maxwidth:physical=* may be sufficient (see the designs above and examples below).
If there is a possibility to bypass the cycle barrier – e.g. via an informal path at the side – consider mapping this path separately with its properties and access information.
Grades on level of detail
Few mappers can be expected to have the motivation or ability to take exact measurements on cycle barriers. Many can or want to capture "on the fly" only the most important information that they can recognise at first glance.
Perhaps the most important information is the design of the barrier (cycle_barrier=*), from which some information can already be derived – for example, whether sharp turning manoeuvres are necessary at all when passing.
On simple designs, the maximum passage width (maxwidth:physical=*) is also the most useful information. On more complex designs, a significant part of the information can be derived from the spacing=* of the grid elements.
If a cycle barrier is obviously too narrow for bicycles, cargo bikes or wheelchairs, bicycle=no, cargo_bike=no or wheelchair=no can also be used – but in general, access tags on barriers should be avoided if they can be derived more accurately from other attributes.
Examples
Note: Sometimes, you can "count" width values if you know the exact size of typical paving stones that are used in your local area. The paving stones in the first and last picture, for example, are 10x20 cm in size – with this knowledge you can easily "measure" the distances.
(OSM) |
(OSM) |
(OSM) |
Note: As this type of barrier only differs in the angle of entry from "normal" cycle barriers of the type "triple", it is not necessary to define a special type – simply "triple" can be used. corners=* provides more detailed information on the geometry of the driving line. |
Similar tags that are already in use
Currently, there are already rare, undocumented uses of the keys cycle_barrier=* and cycle_barrier:type=*, especially cycle_barrier=chicane (which probably corresponds to the new proposed cycle_barrier=double and cycle_barrier=triple), cycle_barrier=squeeze (that will be kept) or cycle_barrier=removable (now cycle_barrier:installation=removable).
cycle_barrier:
cycle_barrier:type:
The key width:separation=* was proposed in 2016 on the cycle barrier talk page for mapping the spacing/distance between the grids of cycle barriers. It corresponds to spacing=* proposed here. Since width:separation=* has rarely been used so far, the prefix width: is used in a not completely clean way and to sematically adjust the term to the other three dimensions, it is named differently in this proposal.
width:separation:
Determine passability
The proposed dimensions and distances can be used by routing software to estimate the passability of the barrier for a specific vehicle, depending on its width and length or shape. An exact calculation is complex, as it would require the calculation of tractrix curves, but it can be assumed that the dimensions can at least be used for a rough calculation or as a comparison for minimum dimensions to provide a warning in case of close distances. Another approach could be to use "passability dictionaries" for routing calculation, in which the passability for different barrier dimensions, types and vehicle profiles are stored in detail (see figure).
Features/Pages affected
The extensions proposed here could simply be added to the cycle barriers page once this proposal has been approved. The problems addressed by this proposal are already mentioned there as open issues and could be resolved.
External discussions
This proposal was discussed in the Berlin "Verkehrswendegruppe", a local group within the Berlin OSM community that focuses on the topics of transport and mobility. The key width:separation=* was proposed in 2016 on the cycle barrier talk page – it is currently used 54 times (as of 2021-06-22). Otherwise, I am not aware of any external discussions.
Call for help
Help with tractrix curves
We would like to add examples of some vehicle types for some cycle barrier constellations that show the tractrix curves in a graphic to better show the issue at hand. Are you able to help with creating such graphics, than please contact the author of this proposal.
Meeting about Routing
We plan to hold a meeting with routing professionals to discuss this proposal as well as other routing topics (pedestrian, bike routing with separately mapped path...). If you are knowledgeable in this field, please reach out to User:tordans; we plan set a date in a few weeks.
Comments
Please comment on the discussion page.
Notes
- ↑ Because the left part of the barrier can be easily overlooked (particularly in the dark) and there is therefore a risk of collision for cyclists. hazard:bicycle=* is an undocumented but used tagging for dangerous points for cyclists – see here for some proposed values (german language).
Voting
Voting on this proposal has been closed.
It was approved with 31 votes for, 2 votes against and 0 abstentions.
I approve this proposal. Looks well thought-out and useful. There is a cycleway near me that actually (and unusually for the Netherlands) has several cycle barriers not to prevent cycling there but to make the crossings with roads safer. Annoying, but useful to have some tags that can clarify their nature for routers to use. --JeroenHoek (talk) 18:37, 2 August 2021 (UTC)
I oppose this proposal. This proposal needs much more discussion, especially regarding countries where these barriers are very frequent (example: Italy). Backwards compatibility is an issue in this context. Routing is critical - you acknowledge this yourself by calling for a meeting, but after the voting. Another issue is the need for faster (approximate) mapping: around here we have so many of these barriers that it is completely unrealistic to think that we find the manpower to take dimensions. Another unsolved aspect is that this micromapping proposal is not compatible with the, admittedly variegated, approaches, that are already in use. Another aspect: I would leave out the tractrix part. It is not well defined and something which is anyway not part of the proposal --voschix (talk) 16:31, 3 August 2021 (UTC)
- Hey voschix, nobody is forcing you to measure the barriers :) But everyone who wants to map cycle barriers in more detail should have a documented way to do so. There is no need for retagging – it's just an add-on. The section Grades on level of detail shows some options if you want to limit yourself "on the fly" to a few/simple attributes. But it's in the nature of these barriers that they are not easy to describe sufficiently.
- The "admittedly variegated approaches" you mention are rare and – as far as I can see – compatible with this proposal. The chapter Similar tags that are already in use already deals with this. We can discuss this further on the discussion page if you have different thoughts and examples. I have also been looking at some cycle barriers in your city after your notice on the tagging mailing list and I don't know of any cases where this proposal would not be usable.
- At the moment no meaningful routing is possible through these barriers for the mentioned user groups – with this proposal there are several possibilities as I have pointed out. Which of these are useful or whether there are further possibilities, routing providers have to decide for themselves, that's not our job (even if I/we are happy to help and have well considered this aspect). The tractrix chapter is part of this considerations and is therefore only an "appendix" to the actual proposal.
- --Supaplex030 (talk) 17:30, 3 August 2021 (UTC) (long comment, long answer, sorry)
- I approve this proposal. Although I have two minor comments, I see no major limitations that would make me vote against this proposal. The comments though: 1) cyclebarrier=squeeze + "maxwidth at about the height of..." is a bit vague; if it was measured at ground level (or max extension level), then the combination with tilt could allow true calculation of the practical width for any type of bike. 2) the example for the swing gate cycle barrier (https://wiki.openstreetmap.org/wiki/File:Cycle_barrier_openable2.jpg) looks like a swing gate with bicycle=yes to me, not a cycle barrier :) --Famlam (talk) 18:54, 3 August 2021 (UTC)
- I approve this proposal. Extensive and well thought-out tagging scheme, which introduces a standardised way for very accurately mapping while not excluding simplified mapping of cycle barriers. Also, I don't see any problems with backwards compatibility nor with routing since this proposal only introduces more variables for routers which can optionally be considered in pathfinding. --Nw520 (talk) 12:36, 4 August 2021 (UTC)
- I approve this proposal. --Shaun das Schaf (talk) 08:36, 5 August 2021 (UTC)
- I approve this proposal. --Eginhard (talk) 16:34, 6 August 2021 (UTC)
- I approve this proposal. - but I am strictly opposed to hazard:bicycle=yes sneaking through (subjective tag that is likely more often used in "caution: cyclists" context like https://commons.wikimedia.org/wiki/File:Znak_A-24.svg ) @Voschix: - what exactly is incompatible? How backwards compatibility is broken? Why more discussion is needed? Mateusz Konieczny (talk) 08:12, 8 August 2021 (UTC)
- Yeah, hazard:bicycle=* is not intended as part of the proposal but rather to show that there are further tagging options at such barriers. hazard:bicycle=* will later not appear in the wiki documentation of the tags if the proposal is approved. --Supaplex030 (talk) 15:24, 8 August 2021 (UTC)
- I approve this proposal. The new keys should be documented in a way that don't restrict their use to cycle barriers, they can be used equally well on other barrier types. --Mueschel (talk) 09:45, 8 August 2021 (UTC)
- Good point. For barrier=motorcycle_barrier (rarely used) or maybe barrier=kissing_gate, some of the keys could also be used. Or are there other cases you have in mind? Usually maxwidth:physical=* is sufficient... --Supaplex030 (talk) 15:33, 8 August 2021 (UTC)
- I approve this proposal. --Timmy_Tesseract (talk) 10:05, 8 August 2021 (UTC)
- I approve this proposal. --Whatismoss (talk) 11:28, 8 August 2021 (UTC)
- I approve this proposal. but two comments: The list shouldn't be seen as exhaustive yet, for example round here we have some that are like a squeeze barrier but only up to pedal height (an alternative route is usually provided allowing small wheelchairs but cargo bikes/trikes/trailers are blocked; We should be able to tag who can unlock openable barriers. A very few gates in the UK can be unlocked with a RADAR key for example. This may be possible in combination with existing tags. ChrisHodgesUK (talk) 14:15, 8 August 2021 (UTC)
- I approve this proposal. --Gileri (talk) 14:48, 8 August 2021 (UTC)
- I approve this proposal. --Reino Baptista (talk) 15:14, 8 August 2021 (UTC)
- I approve this proposal. Thank you for such a well-written and thoroughly described proposal, with plenty of photos and examples. It's perfectly clear to me how these cycle barriers could be tagged. --ZeLonewolf (talk) 17:10, 8 August 2021 (UTC)
- I approve this proposal. Well written and very very exhaustive. Nothing to add, all seems clear --Westnordost (talk) 22:12, 8 August 2021 (UTC)
- I approve this proposal. Very clear and well written, excellent illustrations appreciated --Ralley (talk) 01:10, 9 August 2021 (UTC)
- I approve this proposal. Let's make cycling great again! --scai (talk) 06:57, 9 August 2021 (UTC)
- I approve this proposal. --Ibanez (talk) 13:46, 9 August 2021 (UTC)
- I approve this proposal. --Aetiusjp (talk) 15:49, 9 August 2021 (UTC)
- I approve this proposal. --Strubbl (talk) 19:47, 9 August 2021 (UTC)
- I approve this proposal. --Woazboat (talk) 21:43, 9 August 2021 (UTC)
- I approve this proposal. Well written, with clear examples and illustrations. --kartonage (talk) 08:14, 11 August 2021 (UTC)
- I approve this proposal. --Hike39 (talk) 09:35, 11 August 2021 (UTC)
- I approve this proposal. As mentioned, the type list should not be seen as exhaustive, but I feel this improves things. --MJ Ray (talk) 17:02, 11 August 2021 (UTC)
- I approve this proposal. However, measuring the geometry of a cycle barrier is time-consuming and i suspect that most routing software won't support the proposed tags. Therefore i would have wished for a simpler attribute that indicates whether a cycle barrier is passable for ordinary bicycles or not (e.g.
passable:bicycle=yes/no/pushing_only). --Dafadllyn (talk) 20:00, 11 August 2021 (UTC)
- Feel free to use bicycle=yes/no/dismount :) This proposal primarily aims for better routing for vehicles that go beyond, such as bicycles with trailers or cargo bikes (with very different vehicle sizes). Also, I can' t remember ever seeing "wheelchair" at such a barrier, but that's also a user group that can benefit from this general tagging. --Supaplex030 (talk) 20:28, 11 August 2021 (UTC)
- bicycle=yes/no/dismount is for legal acces, not for possible (physical) access. Unfortunately, there's no tagging scheme for physical access yet. --Dafadllyn (talk) 20:00, 12 August 2021 (UTC)
- Note that bicycle=no and bicycle=dismount have the same meaning (bicycle=dismount was started to be used when bicycle=no was already widely used for "cyclist must dismount and push bicycle here", and bicycle=no was never redefined to mean something else - neither in practice or in a proposal) Mateusz Konieczny (talk)
- Feel free to use bicycle=yes/no/dismount :) This proposal primarily aims for better routing for vehicles that go beyond, such as bicycles with trailers or cargo bikes (with very different vehicle sizes). Also, I can' t remember ever seeing "wheelchair" at such a barrier, but that's also a user group that can benefit from this general tagging. --Supaplex030 (talk) 20:28, 11 August 2021 (UTC)
- I approve this proposal. OSMRogerWilco (talk) 20:18, 11 August 2021 (UTC)
- I oppose this proposal. I approve this well-written proposal in general, but (for the time being) oppose
cycle_barrier:installation=*for the reasons given in https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Advanced_cycle_barrier_tagging#Constructive_critique_on_cycle_barrier:installation.3D.2A --Skorbut (talk) 20:34, 11 August 2021 (UTC) - I approve this proposal. --EneaSuper (talk) 11:00, 12 August 2021 (UTC)
- I approve this proposal. --Riemer17 (talk) 22:08, 16 August 2021 (UTC)