Talk:Tag:barrier=cycle barrier

From OpenStreetMap Wiki
Jump to navigation Jump to search

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: Cycle barrier width.png

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)

Cycle barrier double distances.png
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)