Talk:Tag:barrier=bollard
implications
Since its introduction, this tag has been redefined ([1], [2]) to imply foot=yes and bicycle=yes. Is this commonly accepted? If yes, it should not only be in the text, but also in the template. --Tordanik 18:49, 16 May 2009 (UTC)
- It was merely not explicited at the origin, but it would be clearly implied by the commonsensical definition of bollard. Circeus 00:19, 17 May 2009 (UTC)
Ambiguity
The article reads:
- By default access=no foot=yes bicycle=yes is implied. So tag who can pass the node.
The first sentence suggests that if "access=no foot=yes bicycle=yes" is applicable, I shouldn't have to add extra access, foot or bicycle tags. However, the second sentence tells me to add those tags. What's a simple soul like me to do? --Sybren 16:18, 6 July 2009 (UTC)
- When bollars are in a row, notably in the middle of a road to delimit lanes, they imply also bicycle=no. But it's easy to distinguish: the tag will be added to a linear way: no crossing is permitted anywhere along the way. Generally they are fixed on the road along with a continuous line (or zebras) painted, and they are made in plastic (to limit dangerous impacts in case of accidents, because they are found when lanes are narrow, requiring slower speed; you'll also find most often explicit speed limitation trafic signals, and possibly other trafic calming across the road, and sometimes blinking traffic lights to signal a danger).
- In this case however crossing by foot is still dangerous even if it may be tolerated: bollard
rawsrows should have a gap where crossings for pedestrians or bicycles is explictely permitted. Any motorcycle however cannot cross these bollardrawsrows, simply because of the continuous line. - Bollard
rawsrows are built on roads where there's non eough width available to insert a trafic island and metalic barriers would be more dangerous (or would cause access problems for emergency vehicles that can still pass easily between bollards, just like they can, with extreme care, cross a continuous line or use as dead lane with zebras). - In summary: foot=yes and bicyled=yes are implied when this is just tagging a single OSM node on the OSM way for any highway=*. But foot=no & bicyle=yes are implied if this is tagging a OSM way (across the highway or parallel to it, or on the hyshway way itself) or even any surface (any closed way or any relation with way members forming closed rings). — Verdy_p (talk) 22:17, 10 March 2017 (UTC)
- I think you are wrong here. Bollards are usually used orthogonal to the way. Google some images.
- What you call bollard row (actually bollar raw) is not ment to be tagged by this tag. Chrabros (talk) 02:13, 11 March 2017 (UTC)
- no, it's really "row" (i.e. the alignement, like rows and columns in data tables or in checkboards), not "raw" (i.e. rough, irregular, unsurfaced, unaltered, pure, original, natural, unmixed; for example: statues in raw blocks of rock, or tables and chairs made in raw wood) ! — Verdy_p (talk) 02:58, 11 March 2017 (UTC)
- these are barriers exactly identical: they can block a way, or limit it all along. They are absolutely not different. Please Google images yourself, you'll see they are exactly the same (with all the variations possible) and their role is also to block vehicles to enter another way; orthogonal or parallel does not change their nature, just like we don't distinguish walls along a road blocking access on the otherside, from walls barring a road however most bollards between lanes in the center of roads are generally in plastic for flexibility, but plastic bollards are also very commonly found as barriers across ways; they may also be static or raisable with remote control! You can find parallel bollar rows delimiting a narrow lane through a large pedestrian square plus transversal (raisable) bollars on both ends of this lane to control times where the lane will be open or closed, and some raisable bollars along the parallel bollar rows to allow emergency services to enter the pedestrian square. These are not different if they are along lanes or across them. — Verdy_p (talk) 03:15, 11 March 2017 (UTC)
- I am not calling it raw. You are. Read your previous post. Chrabros (talk) 03:05, 11 March 2017 (UTC)
- Reread yourself!!! This is you that wrote "What ... call bollard row (actually bollar raw)", but this is exactly the opposite !!!! — Verdy_p (talk) 03:15, 11 March 2017 (UTC)
- You are really funny. You wrote "bollard raw" three times in your comment above. Chrabros (talk) 03:55, 11 March 2017 (UTC)
- And you wrote "is not ment" [sic] instead of "meant" (for me in French, "ment" actually means like "lie"/"falsehood"/"tale"/"fib"/"fable" in English)... If you think it's useful to reply such bad comments about typos when your comment contains its own new typos but also (worse) new contradictions... — Verdy_p (talk) 04:04, 11 March 2017 (UTC)
- You are really funny. You wrote "bollard raw" three times in your comment above. Chrabros (talk) 03:55, 11 March 2017 (UTC)
- Reread yourself!!! This is you that wrote "What ... call bollard row (actually bollar raw)", but this is exactly the opposite !!!! — Verdy_p (talk) 03:15, 11 March 2017 (UTC)
- I am not calling it raw. You are. Read your previous post. Chrabros (talk) 03:05, 11 March 2017 (UTC)
Automatic, "Rising" Bollards
Some bollards retract into the ground automatically, either in response to a key system or on a timer[1]. A couple of schemes have emerged for representing this, though neither is was in particularly widespread use at the time of writing:
- Tag as above, and add bollard=rising. 44 uses as of 2011-04-26[2].
- Tag as above, and add automatic=yes. 29 probable uses as of 2011-04-26[3].
The bollard=* scheme is more extensible, and is probably the better tag. TODO: suggest some other values, or use a Taginfo box to refer readers to a dynamic list.
- What about bollard=fixed for example the stumps of concrete, and bollard=removable for those that can be manually removed/lowered (usually a key is needed) for authorised access. --User:LastGrape
- Sounds good to me. Let's discuss possible values over at Key:bollard. There was just enough usage in the db to justify a descriptive wiki page (with a taginfo box), and automatic=yes doesn't really seem to have caught on. --achadwick 20:10, 2 March 2012 (UTC)
barrier=bollard_row
like tree_row can we have bollard_row to add way to indicate that in this place ther's lot of bollard? -Yod4z (talk) 09:12, 28 March 2015 (UTC)
- Just draw the barrier=bollard as a way.--Jojo4u (talk) 11:48, 10 May 2016 (UTC)
- I agree. It may even be a closed way (e.g. all around a park or fountain), not implying any surface. Individual bollars are small and this tack is not meant to represent larger obstacles such as blocks or debris.
- For this reason I add another implied value area=no. — Verdy_p (talk) 00:54, 29 March 2017 (UTC)
width of way that passes
bollards are usually found on ways (although they are also used along ways or areas sometimes). How do you tag the width of the way that passes? maxwidth=* is useful for legal limits and - maybe not expected - also maxwidth:physical is about a signposted limit, width=* is the actual width of the feature (i.e. the bollard), maybe we need something like clear_width=* for the clear_width around the feature? An alternative workaround, lacking some elegance, would be splitting the highway around the bollard and add a width tag to the highway pieces. —Dieterdreist (talk) 21:21, 19 March 2018 (UTC)
- I disagree with the statement that maxwidth:physical requires the physical limit to be signposted, and would recommend using that key for this situation. --Tordanik 10:22, 3 April 2018 (UTC)
- even if you disagree that a sign is a requirement, the naming wouldn’t make sense: maxwidth is about a legal limit, hence maxwidth:*=* shouldn’t be about anything completely different. It would be different for physical_maxwidth, but generally clear_width seems a better term to me. —Dieterdreist (talk) 13:51, 3 April 2018 (UTC)
- I can see the argument that the name chosen for the maxheight:physical=* and maxwidth:physical=* keys isn't ideal, but "I want to replace this existing key because it's badly named" is still a rather different situation than "there is no key for this yet". As the documentation of maxwidth:physical explicitly mentions the use case in question (adding the tag to a barrier) in its introduction, it seems relevant here. --Tordanik 16:20, 4 April 2018 (UTC)
- On further thought I agree with you, the tag can be used. --Dieterdreist (talk) 15:16, 10 April 2018 (UTC)
- I can see the argument that the name chosen for the maxheight:physical=* and maxwidth:physical=* keys isn't ideal, but "I want to replace this existing key because it's badly named" is still a rather different situation than "there is no key for this yet". As the documentation of maxwidth:physical explicitly mentions the use case in question (adding the tag to a barrier) in its introduction, it seems relevant here. --Tordanik 16:20, 4 April 2018 (UTC)
- even if you disagree that a sign is a requirement, the naming wouldn’t make sense: maxwidth is about a legal limit, hence maxwidth:*=* shouldn’t be about anything completely different. It would be different for physical_maxwidth, but generally clear_width seems a better term to me. —Dieterdreist (talk) 13:51, 3 April 2018 (UTC)
"foot" and "bicycle", what about others
In the discussion "implications" from 2009, pedestrians and bicycles are seen as obvious exceptions. What about mopeds, mofas, motorcycles, inline_skates, horses, ice_skates and skis? The list of transportation modes that can pass is quite long. —M!dgard [ talk ] 20:26, 5 August 2018 (UTC)
- I agree that the current statement By default access=no, foot=yes, and bicycle=yes is implied seems strange. For example I would not expect horses, scooters or skates to be excluded through the mere presence of a bollard on a way. For motorcycles I am unsure, but would expect that we cannot state a global default which would make sense and be universally shared. The suggestion should be to tag explicit access tags and treat untagged specifics as "unknown". --Dieterdreist (talk) 14:36, 17 November 2020 (UTC)
- I modified to "By default access=no, foot=yes, bicycle=yes and similar are implied. If something usually not blocked by bollards (cyclist, horse etc) would be blocked then tag this explicitly." Mateusz Konieczny (talk) 15:30, 17 November 2020 (UTC)
- Thank you for wanting to help, but is there anything similar to "access=no"? Is a mofa similar to a bicycle? I have the fear that the addition of "and similar" has not led to more clarity but to more uncertainty. --Dieterdreist (talk) 23:38, 17 November 2020 (UTC)
- I modified to "By default access=no, foot=yes, bicycle=yes and similar are implied. If something usually not blocked by bollards (cyclist, horse etc) would be blocked then tag this explicitly." Mateusz Konieczny (talk) 15:30, 17 November 2020 (UTC)
lighting bollards?
what about lighting bollards like these?
- highway=street_lamp + support=pedestal. If you really consider it a barrier=*, then add Proposed_features/Key:light_source. ---- Kovposch (talk) 08:15, 7 December 2020 (UTC)
Pairs
Here are pairs of bollards, every 10 feet.
.. .. .. ..
I wish there was a Key:seats-like number tag I could use. Then I could just tag the pairs, and not all of them. Jidanni (talk) 14:50, 21 November 2022 (UTC)
Harmonizing barrier=bollard default access
I have the plan to harmonize the "default access" by creating a new Wiki template and use it for all language that has “implies” already filled in so that it will be and stay consistent over all languages and created a poll on that.
See Harmonizing barrier=bollard default access on the forum -- Emvee (talk) 18:34, 6 February 2024 (UTC)
- Do you mean the section "Implies" on the right? What template do you mean? You don't need the template, you can just edit the data item. maro21 20:38, 6 February 2024 (UTC)
- Hi, an interesting idea, but then it's better to propose default restrictions for all major types of barriers. —Grass-snake (talk) 15:34, 11 February 2024 (UTC)