Proposed features/Advanced cycle barrier tagging
|Advanced cycle barrier tagging|
|Status:||Proposed (under way)|
|Tagging:||cycle_barrier=*, cycle_barrier:installation=*, corners=*, deflection=*, spacing=*, opening=* and overlap=*=*|
|Definition:||Type, design, size and width specifications for cycle barriers – i.e. barriers along a path that slows or prevents access for bicycle users.|
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=*).
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.
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 deviation is 0, otherwise 90.
|cycle_barrier=*||Picture||Schematic illustration||corners=* default value||Dimensions necessary to determine passability|
opening=* (only the smallest of the two)
|triple||4||spacing=* (only the smallest of the two)|
opening=* (only the smallest of the three)
|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=*.|
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 and openable models – removable or foldable installations, like we know from bollard=*, probably also exist.
|fixed||Barrier with fixed bars (often set in concrete) that can't be removed or opened.|
|openable||Barrier can be opened (with a key) – a common mechanism are hinged bars that can be folded upwards.|
|openable||Barrier can be opened (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.
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.
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.
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).
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.
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).
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.
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.
Please comment on the discussion page.
- 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).