Talk:Tag:barrier=cycle barrier

Please sign comments with with "--~~~~". Thanks!

either slow cycle access or prevent it entirely

well this makes a difference. There is little point in having a tag this vaguely defined - Please either clarify or remove this tag. -- User:Frief August 11, 2009

We can clarify it more within the wiki writeup, I suppose. It's a little too widespread in use to remove from the OSM db. For barriers which prevent cycle access, I would suggest either bicycle=no or access=no (with no bicycle override). For those that merely hinder, use either bicycle=yes or access=yes (with no bicycle override). Hope that's acceptable; IMO it is not the job of a tag defining the rough class of a barrier to say exactly what does or does not have access. With this in mind, can you suggest where changes need to be made in your opinion? --achadwick 12:40, 12 August 2009 (UTC)

I guess it's mostly used in the sense of bicycle=yes (and in this case it would rather have (for bicycles) the character of traffic_calming instead of barrier). Perhaps it could be specified that per default bicycle=yes is implied. It sounds awkward to have a barrier that is not a barrier though. (I'm not a native English speaker, so maybe my connotations of a barrier are incorrect) --Frief 20:42, 12 August 2009 (UTC)

• If you look at them from the perspective of a motorist, then they're always a barrier. It's just shorter to say "cycle barrier" then "barrier to motor vehicles designed to let pedestrians and sometimes bicycles through" :) I guess the distinction is that a traffic_calming=* stops no mode of transport from passing through, whereas a barrier=* is something designed to stop at least one mode of transport from passing through. Hope that makes sense! --achadwick 10:42, 13 August 2009 (UTC)
• Sure, the tag name is a little strange; it could just as well be named several other things ("foot barrier" is just as good, and "path barrier" makes more intuitive sense to me at the moment!), but that's what people were using back when it was discussed. --achadwick 10:42, 13 August 2009 (UTC)

Any more clarification needed on the main page? --achadwick 10:42, 13 August 2009 (UTC)

Barrier: prevents. Traffic calming: slows down. A cycle barrier cannot be passed by a cycle - I'm not sure if these exist. Motorcycle barriers do. As it is, 'cycle barrier' has no useful purpose as it doesn't state whether cycles can pass or not.-- pmailkeey 2016:6:22

liftable_by_maintainer

Could cycle barrier get an option liftable_by_maintainer (yes/no)? Some cycle barriers can be lifted with a special key for special sporting events by local government or maintainer of that barrier. This information would be usefull to add for planning sports events. --Pander (talk) 11:11, 6 October 2013 (UTC)

Perhaps liftable is too specific as there are also barriers that can be turned out of the way, dissappear under ground or be detached. I think "removeable" (yes/no with unspecified implies no) is a better characteristic for cycle_barrier and other barriers. --Pander (talk) 11:47, 6 October 2013 (UTC)

I've used (albeit surprisingly) the tag motorcar=private - the operator of the gate can drive his car (usually the snow plow) through it by unlocking the mechanism. I guess that won't be true for all of these that can be "opened". Alv (talk) 13:59, 6 October 2013 (UTC)

Instead of generalizing it to "removeable", I would suggest to use "locked". I know two gates ([1] [2]) which are normally closed, but can be opened by anyone who needs to pass.

But I think tagging the area (road/path) behind the barrier is even better, the barrier is just a way to enforce an access restriction. A sign would have the same effect, but some people ignore signs. Saying bicycle=private implies a road is suitable for bicycles, but you can cycle there only if you have permission. In this case the permission is given by lifting the barrier. --Wimmel (talk) 17:58, 6 October 2013 (UTC)

Specific width for bicycle barriers

This type of barrier is very common on the cycle paths, and often pose problems for non-regular cycles: trike, cargo bike, bike trailer with ... Can also create difficulties for disabled and horses. It may be interesting to give two different values of width as shown below:

In this example, the passage width available is different depending on the barrier: it is the smallest which is retained. tag:

barrier=cycle_barrier

width=1

width:separation=2

--Axelos (talk) 16:49, 19 January 2016 (UTC)

For a reliable evaluation of passability, the overlap also has to be taken into account. Furthermore, the use of key "width" without a prefix is misleading, as it could be associated with an unspecific width or rather the width of the object or path. I have documented an adapted proposal here: Advanced cycle barrier tagging.--Supaplex030 (talk) 22:18, 11 June 2021 (UTC)

Thank you for suggesting these improvements. I have migrated my contributions under this new scheme. --Axelos (talk) 18:34, 28 March 2023 (UTC)

Distinguishing barrier types

At the moment, it seems the only way to distinguish slaloms from the much more hazardous A-barriers popular with anti-cycling local governments in England is whether the cycle_barrier has a width:separation tag set (which confirms that it is a slalom). As a result, A-barriers are rendered the same as slaloms by most maps, which is misleading.

Should we encourage reverting to barrier=chicane for the less obstructive ones? Does anyone have a suggestion of a better way to note the type of cycle barrier? barrier=a_frame does not seem like a great tag and there would be a delay while renderers catch up. I think I read barrier=hoop for "pedal-catchers" has been suggested in questions/23310

MJ Ray (talk) 17:49, 8 April 2021 (UTC)

Proposed some values for typical cycle barrier types here: Advanced cycle barrier tagging. --Supaplex030 (talk) 22:19, 11 June 2021 (UTC)

Cycle barrier with 2 passages

How would you tag a cycle barrier that has 2 passages side-by-side? It is similar to a cycle_barrier=single, however there is another passage and there is no overlap or deflection needed. The barriers are side-by-side to form 2 passages for cyclists and pedestrians and block motor vehicles Here is a small mockup that I have created based

See an example on Bing Streetview: https://www.bing.com/maps?FORM=Z9LH2&cp=46.882977%7E-71.520183&lvl=15.9&pi=-25.7&style=x&dir=275.1

--Wolfy1339 (talk) 21:40, 28 August 2024 (UTC)

I think, it is actually the cycle_barrier=single case, only with 2 openings specified with maxwidth:physical=* (and hopefully equal in size). I think the values single/double/triple represent the number of rows of barriers there are – so here it’s single. But it could be made clearer in the wording of the wiki page what, for example, the value single stands for (like “a single row”). You could also note in note=* that there are 2 openings ... perhaps the simplest solution. Or invent a new tag like opening_count=* – similar to step_count=* (ATYL) Or it could perhaps be considered a special case of triple with cycle_barrier=triple, corners=0, spacing=0, overlap=0, opening=XY, but that could perhaps be confusing, and it probably does not match the intended definition of the value triple. --Goodidea (talk) 14:13, 29 August 2024 (UTC)