Talk:Key:barrier

From OpenStreetMap Wiki

Jump to: navigation, search

Gates at junctions

It seems that this schema doesn't cover the most common use of gates that I encounter: when there is a gated side street or path.

Suppose the road layout is a T shape and there is a junction node in the middle. The bottom road is gated but traffic flows freely east-west. You cannot tag the junction node with barrier=gate because that would imply that nobody can cross it. Yet it is not correct to tag the whole bottom way as barrier=gate because the barrier exists only at the top of it, where it joins the other two roads.

You could add a barrier=gate node some way down the bottom way but that would falsely imply that you can turn off and travel some distance down that way before reaching the gate. In fact, the gate is located at the junction and you cannot turn onto the lower road without crossing the gate first.

What is the right way to tag this layout? -- Ed Avis <eda@waniasset.com>

Add the node some short way down the bottom way; were you cycling east/west on the center line, you indeed could turn against the gate and only hit it after deviating some meters from the center line. You can estimate the correct distance from the center line of the east-west street and at least in JOSM you can check that the distance is thereabouts. Visual estimation aids include car widths (1.5 to 2 meters), lane width (commonly 2.2 to 3.5), "Mondeo length" just under 5 meters etc. Alv 16:51, 27 February 2009 (UTC)

What Alv said. I'd think this is the obvious way to deal with this to begin with. We have to remember that OSM data is a schematic of what is "there on the ground". There will always be a limit that cannot quite be represented with absolute accuracy in the data (and people will always disagree up to which point the data ought to mimick real life anyway). Circeus 05:51, 28 February 2009 (UTC)

Thanks, I guess I'll do that. It seems a bit kludgy to me to add a 2 metre 'stump' of the side road to express the fact that the gate is at the very end of that road (and not two metres along it), but I suppose if you consider distance from the centre line then it can be justified.

boom barrier - 2008

What about boom barriers? I'm guessing that barrier=boom or barrier=boom_barrier will be appropriate tag.

it has been called barrier=lift_gate as said in Approved_features/barriers#Node --Sergionaranja 14:58, 4 November 2008 (UTC)

Movable bollards

What about Movable Bollards http://en.wikipedia.org/wiki/Bollard#Movable_bollards, or remote controllable ones?

barrier=bollard|bollard=moveable, maybe. Or barrier=bollard|bollard=rising, like these. --achadwick 01:50, 15 March 2009 (UTC)

barrier=block?

I love the suggested renderings as they are parsimonious and descriptive, but I still would like to see a description of barrier=block as the icon looks a bit like traffic_calming=chicane. Ipofanes 08:08, 5 December 2008 (UTC)

Done --achadwick 17:14, 17 March 2009 (UTC)

no name

I added three pictures of which I think are new types. I don't have a word for them, your input is appreciated. --tmeller 18:10, 12 November 2008 (UTC)

The V-gate is a type of kissing gate AFAICT. Circeus 01:49, 13 November 2008 (UTC)

See Approved_features/barriers for types not mentioned at barrier=* --Sergionaranja 13:05, 13 November 2008 (UTC)

OK, better idea: a page of it's own, to find the correct barrier-tag by looking at pictures: Barrier_examples --tmeller 22:10, 17 November 2008 (UTC)

barrier_type

What really differentiates one node barrier from other is the access definition. In abstract a node barrier such as gate is the same as block, and inside gate there is no difference between types other than physical differences. Routing software wont care if is a bump_gate or a lift_gate, what is useful is just who can pass, how, when and so on.
This makes me think that also for humans it might be better to classify node barriers by real operational means, and use gate_type=* for physical differences that can either pop up by infosoft and can be rendered attending to the type tag if someone wants to.. eg:

  barrier=gate
  gate_type=hampshire
  foot=yes
  motorcar=no
  opening_hours=7:00-20:00

  barrier=bollard
  bollard_type=rise
  psv=yes

--Sergionaranja 07:14, 25 November 2008 (UTC)

I'd be in favour of using the iterative specialisation pattern used elsewhere for this:

barrier=gate

gate=hampshire

barrier=bollard

bollard=rising

Suffixing _type is a little strange to me if all you're doing is further refining the definition. But it's just a stylistic thing. --achadwick 01:46, 15 March 2009 (UTC)

I like the way types of recycable materials are stored along amenity=recycling tags. Easy to tag, easy to query. For example:

 amenity=recycling
 recycling:batteries=yes
 
 >>>
 
 barrier=fence
 fence:wire=yes
 
 barrier=retaining_wall
 retaining_wall:haha=yes

How about adopting this tagging style? lazzko 17:35, 25 November 2009 (UTC)

This tagging style is useful if and only if there are multiple features that each can or cannot be present, with no hierarchy between the features. For the examples before your comment (such as gate -> hampshire gate), this wouldn't make much sense, as there is a hierarchy (all hampshire gates are gates, for example). Your example might be different - however, until you can actually provide an example where there are multiple fence: attributes that are independent of each other, I cannot say for sure whether recycling style tagging is appropriate. --Tordanik 19:19, 26 November 2009 (UTC)

Few Queries

Just been converting all the border= tags to barrier, and some arn't represented. (I think I have photos for all of these..will take some time to find them...)

fence - many variations. I have metal_fence (solid rather than wire), wire_fence (including barb), and wood_fence.
retaining_wall - should this be used for hahas also? Slightly different, but rather similar.
v_stile - isn't here. Quite common, you step up and through a V shape in the wooden fence, dogs find it tricky, likewise livestock.
ditch - pretty obvious what that means, can that be added?
field_border - There are some fields split by merly a strip of grass, or just end. quite rare, but it needs some tag as it defines the boundary between two areas.
step_over - like a stile with no steps. Usually a wooden section built along a barb wire fence. Different because elderly would commonly wish to avoid these.
horse_jump - very common just between fields.
Variations in gates, e.g, footgate or pengate (small metal gates that are movable by hand, used for making pens

Also, hedges that are easily walked through. serve no purpose for most livestock, but are a visual marker on the landscape. Currently I just have these tagged as barrier:hedge permeable:yes (no assumed default) maybe a separate issue.

- In general i would use "barrier=* ; *_type=*". eg "barrier=fence ; fence_type=wire" "barrier=retaining_wall ; retaining_wall_type=haha" "barrier=style ; style_type=v" and so on.
- "barrier=ditch" can be a new one.
- I would not consider field_border a barrier, is a boundary o maybe a change of landuse..
- permeable=yes sounds ok to me --Sergionaranja 13:08, 10 December 2008 (UTC)

Making a new key to be more specific seems very messy, and harder to manage. Yes fence_type is more specific, but wire_fences, wooden_fences etc. are all so common there a value in themselves. I think additional (sub)keys are only required for specifics of the same thing...e.g. I tag stiles with steps=1/2/3 etc. There still stiles. wire/metal/wood fences are noticeable different, not just materially different. If I grouped them, I'd say there all barriers/boundaries/borders.

A field_border is a divide between 2 areas, same as hedgerows. It's not a 'barrier' but that's being a little fussy about word choice. It's a boundary or border, which have been 2 other suggested keys to deal with the same issue. Sometimes hedges come and go..there is a scrub/strip which continues between hedge elements. Ben 14:04, 10 December 2008 (UTC)

Finally, why is barriers second down after highways? I think it should be way further down, since barriers are hardly the second thing the average mapper is going to be adding. Their high detail, low importance compared to some keys. Ben 11:45, 10 December 2008 (UTC)

As a side note, I don't think classifying types of stiles is useful. For the most part, access tags should be sufficient without a need to classify the 10+ different types of stiles, all of which are fundamentally the same thing: a way for people on foot, occasionally also on bicycle, to cross a fence. From a mapping or even a functional point of view, specifying further than that provides no advantage and complicates renderer and router's jobs. Circeus 18:17, 18 December 2008 (UTC)

i think is the opposite, if you add *_type then you leave the tag clean. (barrier=gate, access=foot) that's what render and navigation software is looking for. then you add more info if you what (gate_type=kissing) witch is just a physical description wich is good to know, and even the renderer can render that type if its used enough. even I personally would just render gate, that includes all types. If you have barrier=kissing_gate, barrier=sally_gate barrier=*_gate then you are saying that there are many types of barriers. and that is not true, you just have many types of gates.(my opinion) --Sergionaranja 19:26, 18 December 2008 (UTC)

I meant that I don't think having such values as lift_gate or hampshire_gate for barrier (as opposed to moving them to an additional gate_type tag) is useful. Unfortunately, this is what the page currently recommend, even though all these new values would have been summarily shot down in the proposal. Circeus 01:19, 19 December 2008 (UTC)

ok sorry, we agree on this then. is just a matter of what solution. you propose to put just style and that covers all style types and same for gate...and so on, right? what i add to that is if someone what's to describe further then use *_type. But the best is just one general style or gate. shall types in barrier= then be removed in the key page, and explain that one general style covers all? --Sergionaranja 09:32, 19 December 2008 (UTC)

yes, I think moving these to the talk page and giving a functional definition of "stile" (an access that does not actually interrupt the barrier: it cannot be "opened") and "gate" (an access that causes an opening to appear in the barrier when used). Maybe separate entrance tags from barrier "nodes" too? I'm going to give it a shot. Circeus 19:27, 19 December 2008 (UTC)

Okay, template updated. Also listed barrier=entrance formally, added bollards as way and barrier=ditch, which I think makes a whole lot of sense. Circeus 19:49, 19 December 2008 (UTC)

I can see the concern with having infinite values for different variations of 'the same thing'. But..3 points against lack of specifics. Different stiles/gates greatly vary accessibility. If you are the average pensioner, looking for a route and excluding step_over and stiles with many many steps is a good bet. Also as soon as something is particularly common it's best to be more specific, otherwise it becomes way less valued on the map. So when 3 or 4 gates/stiles etc. appear together, it's good to know that you are following the route through the 'kissing_gate'. This situation is rather common where I map, and I presume in most of England and Wales. No idea about other countries. For the process of making a map, being more specific doesn't take any more time. If I walk a route and note there's a 'gate(generic)' then it would be no harder for me to note there is a 'kissing_gate' instead. This isn't an assumption, I can say this as the result of doing it for some time.
If we are to break it down into subcategories, it would involve multiple tags to serve the purpose of one. Main concern..More time taken mapping it. I think split all barriers into 4 then we don't need to state access= at all, which cuts down work time. The perimeter markers such as hedges/fences, the gates for vehicles, footgates for horses/bikes or less and 'stiles' for foot only (including step_over/v_styles etc.) Kissing gate would need to be a stile I suppose. barrier_type= could then be the sub tag for all 4 barrier variants. I personally would then use steps= and/or note= as sub tags to that also.
This method should allow route planners to skip the irrelevant, People who wish not to map the specifics could avoid it, and vice versa, and ensure not too much additional time wasting is required tagging wise. Ben 12:57, 22 December 2008 (UTC)
As for me, I do not care for reality. I'd prefer usability instead. A handicapped could never jump over a stream or climb a stile, the rider of a mountainbike could use a step or a small ladder, a car or quad will never be able to pass a narrow gate, whereas an enduro will, but never pass steps or jumps. So why not tag it as barrier=gate|stream|step|stile|fence, passing=jump|climb|ride|stepover|drive. IMO, access= is for permission, not capability. --Tmeller 19:00, 12 January 2009 (UTC)

barrier=chain?

I was converting a highway=gate tag to a barrier=* tag and realized that it wasn't a lift_gate but a chain preventing cars from entering a private street. But I noticed that there was no chain value described, so I'm proposing here that we add chain to the list of valid tags. pov 21:42, 9 March 2009 (UTC)

The way I see it, it it's not meant to open, and disallow some vehicles, but not pedestrians, that's functionally a bollard and could be tagged as such. If the chain CAN open, then it's still a gate even if the name is mildly misleading. In any case, indicating who can access is more important anyway. Circeus 22:52, 9 March 2009 (UTC)

Cycle barriers (a.k.a. chicane/wiggle/drängelgitter/zigzag types)

Lets come up with a good name for these things and add them to the main page. They seem to have been missed off the list, though they were discussed in the original proposal. My vote is for either barrier=chicane or barrier=zigzag. --achadwick 01:36, 15 March 2009 (UTC)

Why not barrier=cycle_barrier? It's actually used 439 times in Europe and supported by JOSM and Osmarender. Normative power of fact. --nkbre 10:23, 15 March 2009 (UTC)

Doesn't barrier=block cover this? --Dwi Secundus 19:18, 16 March 2009 (UTC)

I think, after reading Approved_features/barriers#Node you would say: No, it doesn't.--nkbre 20:08, 16 March 2009 (UTC)

Documented, and linked where it occurs. ---achadwick 17:13, 17 March 2009 (UTC)

Suits me; in fact I'll treat that as a vote, fix the instances in my area, and document it here. If we need to say more about individual types, we can say it under cycle_barrier=*. --achadwick 17:13, 17 March 2009 (UTC)

Okay, done. Check out barrier=cycle_barrier, and feel free to edit it or integrate it into the main barrier=* page. --achadwick 18:00, 17 March 2009 (UTC)

Explain

What originally happened is that a chicane was already a part of traffic_calming=*, and that simply applying the appropriate access tags in conjunction with traffic_calming=chicane would have been sufficient. Ultimately, maybe a split is more intuitive as barrier=* always has an implication that some mode of transportation are prevented from passing. Circeus 19:44, 18 March 2009 (UTC)

Missing barrier type: turnstile

I think barrier=turnstile is missing. It's a quite common kind of barrier. --Dwi Secundus 19:19, 16 March 2009 (UTC)

In the open? I mean, inside buildings and all, yes, but as a permanent outdoor fixture? Circeus 19:44, 18 March 2009 (UTC)

Yes, I know a cemetery that has a turnstile to block cyclists from entering. --Dwi Secundus 14:36, 22 March 2009 (UTC)

I've added the turnstile to the node barriers. --Dwi Secundus 20:13, 4 April 2009 (UTC)

I've been thinking about it, and I'm now thinking that a turnstile is not a barrier, but a type of entrance. To be precise, it's is a one-way entrance. Circeus 21:02, 25 April 2009 (UTC)

Here is a really large one, it is even accessible with a wheelchair!

Turnstile wheelchair=yes !

--Lulu-Ann 15:11, 15 June 2010 (UTC)

boom barrier

There is no tag for boom barriers (image at http://de.wikipedia.org/wiki/Datei:Moderne_Schranke.jpg). Should we add barrier=boom? --abunai 09:24, 26 April 2009 (UTC)

What about barrier=lift_gate? It's documented on this article page and here Approved_features/barriers#Node with a link to Wikipedia. --nkbre 11:48, 26 April 2009 (UTC)

Interesting. Why is it called that? I thought a lift gate the thing on the back of a truck that's used for loading cargo? --abunai 15:12, 26 April 2009 (UTC)

Functionally, it's a barrier=gate (it blocks entrance to all and can be closed or opened). You would add extra details with gate_type=* (though both options are possible, I find the separate form is more flexible, if only because it keeps individual variations out of the main tag). Circeus 19:44, 1 May 2009 (UTC)

Barriers closed on specific moments

In some locations roads are blocked according to specific rules. Example: in one locations a lot of roads are blocked on Sundays and Bank Holidays from 13 to 19h in the summer and from 13 to 18h in the winter.

Routing could depend on this.

I guess the roads themselves could be restricted too, but that would imply several while a barrier may be enough. In the specific case I wanted to map, the type of barrier is not listed either (resembles to a big cloth blocking the road and put away in special containers on the side of the road at the end of the day).

Seasonality of access (cf. some streets in Quebec City and Montreal become pedestrianized during summer days) has no defined tags yet anywhere that I know of. Circeus 17:01, 9 May 2009 (UTC)

When is a gate not a gate

Should we call it a gate when the gate is either almost always open, or permanently locked? In particular, there are some near me where there's space for a pedestrian or cyclist to go round the gate, but the gate itself is for landowner vehicular access, and is locked. To me that's an "entrance" if the path for the pedestrian/cyclist is unobstructed, and "cycle_barrier" if the path is moderately obstructed. Any objection if I amend the wiki accordingly?--RichardMann 14:40, 19 June 2009 (UTC)

highway accompanying barriers

I'd like to see a tag for highway accompanying barriers. Since I had to offline-edit quite a lot I used this scheme: barrier:hedge=left and barrier:handrail=right (for example). So one doesn't has to paint three lines: the highway, the barrier to the left and the barrier to the right. Disadvantage is that mapnik doesn't render highways with such a tag. But that can surely and easily be helped. Pros/Contras/Enhancements? -- Malenki 19:25, 17 August 2009 (UTC)

Hi, read collected lanes about that. Not only barriers are next to a highway, also combinations like

House - garden - fence - footway - grass - cycleway - bush - buslane - carlane - grass with trees - carlane - .... (mirrored or not) ... exist. Unfortunately it's not easy, but definitely needed, for instance for the blind. --Lulu-Ann 14:57, 18 August 2009 (UTC)

I'd really like to, but your link doesn't work. Searching the wiki for collected lines gave no result. Please give a correct link. -- Malenki 13:35, 19 August 2009 (UTC)

Link corrected, sorry. --Lulu-Ann 21:43, 19 August 2009 (UTC)

Routing

Currently the problem with routing is, that routing applications can not check for millions of nodes, but only for thousands of ways without performace problems.

That results in the problem, that for example barrier bollards in the middle of the road can not be considered.

I recommend to add a route_nodes=yes or router:check_nodes=yes to such ways, so that the routing software can check only the ways in first run and then check the nodes on ways only where this is set.

Comments?

--Lulu-Ann 07:26, 10 September 2009 (UTC)

complementing highway tagging with access=*, isn't enough.? --Sergionaranja 17:07, 12 September 2009 (UTC)

This point is moot. Since routing requires the data to be-processed anyway, this can be computed when building the map file and attached to the way at that time. It means no extra tagging from the mappers' part and no risk of contradictory information because a barrier got removed but the mapper didn't see the extra tag on the way. I'm sometimes inclined to think a little bit of tagging for routing/rendering can help a lot, but this is really trivial to do. pov 15:02, 18 September 2009 (UTC)

Why does routing requiere the data to be pre-processed? --Lulu-Ann 12:56, 22 September 2009 (UTC)

While in theory it could be possible to write routing software that only needed the latest planet.osm and only as much memory as the tried routes require, the software would have to read through the whole gazillion gigabyte file twice for each node to find the next possible nodes; the nodes are stored separate from the ways, i.e. looking at the data (in the format it is downloaded from openstreetmap.org) for one node, one doesn't know the ways the node is a part of, nor does one know (with the same data format) which other ways intersect with any given way. For a suburb sized extract it could work (file size few hundred kilobytes at most), but already with limited performance. Alv 16:30, 22 September 2009 (UTC)

As I understand it, all the positional information is stored with the nodes, so anyone accessing a way for routing will need to read the member nodes anyway to find out where they are and what the way joins to/is joined by. Adding an extra check for barrier tags when reading the nodes shouldn't need an extra tag on the way. --EdLoach 14:29, 22 September 2009 (UTC)

imply access=no

That's a bold implication, and it doesn't make sense for many kinds of barriers. And I'm sure it makes many routes impassable now when you now suddenly add this implication (whether it was on the proposal page or not, who reads that page anyway when looking for information on this tag?). It makes more sense to add access=no when one really can't pass. If the roads behind the barrier aren't accessible those ways will probably have access=private or something like that already. Also, it's way too easy to forget about vehicle types when entering them all: if bicycles can pass, mopeds certainly can as well, but I'm pretty sure most mappers will forget about those. And next, are these legal restrictions or physical ones. Remember that access rules are legal restrictions, so if it's the latter this may actually not be compatible with access rules at all. And it may be subjective to the mapper as well.

So, basically what should be done is that barriers allow all traffic by default. But it's actually up to the roads behind the barrier to define the restrictions. If it's a barrier between two roads, then there's actually a path between those two roads which has the restrictions. --Eimai 19:38, 23 September 2009 (UTC)

The implied access=* needs to be defined for the individual types of barriers. For example access=no doesn't make sense for barrier=cattle_grid. --Ulfm 20:40, 23 September 2009 (UTC)

No implied access tags is fine with me, but then it should be consistent. This means

changing implications on DE:Key:barrier (some mappers reading that page will have assumed the implication until now)
adding explicit access=no to the first example
no access=no implication for any barrier value - I don't want to remember that for barrier=bollard I need to state who may pass it, but for barrier=gate I need to state who may not.

Consistency was the whole point of my edit. To me, it looked like this implication was supposed to be there. In that sort of situation, i consider a proposal useful to find out how it was "meant to be". Unfortunately, it's hard to find out the intentions of mappers using the tag. --Tordanik 21:09, 23 September 2009 (UTC)

I think you guys are right, access=yes is what should be implied to all barriers. Then the mapper adds what can not pass them or he can just leave it blank (whith access=yes implied) or if the node barrier is in a way that already has access limitations those override the node. this is easier to remember for mappers and also to read by routers. --Sergionaranja 12:10, 26 September 2009 (UTC)

Dragon's teeth (fortification)

How would you tag Dragon's teeth?. There are many of them at the Western border of Germany, see for example: http://www.openstreetmap.org/?lat=50.79446&lon=6.017&zoom=17 (Höckerlinie near Aachen). At the moment they are just marked as tag:historic=ruins, and they aren't rendered nicely. Should we add tag:area=yes? And what barrier type would be appropriate? tag:barrier=block? But these should only be used for nodes. How would you tag a wide strip full of Dragon's teeth? --Head 11:40, 9 December 2009 (UTC)

Mine field

I suggest barrier=mine_field used on an nodes or areas to indicate mines of all types. Implies access=no. Super important in post war areas. Suggested rendering: Red area + stylized scull & bones. Possible additional tags: mine_field=personnel or tank. Maybe persumed density of mines or if it has been cleared or not. See also http://en.wikipedia.org/wiki/Land_mine. Gorm 16:58, 21 December 2009 (UTC)

As land mines (and sea mines for that sake) have no legal usage outside the military, I suggest military=mine_field --Skippern 18:01, 21 December 2009 (UTC)

Land mines within military zones should not be mapped at all: the zone itself may be tagged with landuse=military, or in more restrictive countries only as access=no.

But not all land mines are within military zones. In fact, most of them in the world have been left over there, and abandoned by militaries, creating a severe danger for the civilian population living there or for visitors.

So it's OK to tag the barrier=mine_field on nodes where there's a alerting signpost and effectively a barrier on an access road (and visible from the unrestricted area), along with access=no for the dangerous zone itself, or for the way of a dangerous old road that has still not been secured.

Note that some zones may be marked as mine fields with access=no and something like danger=mine_field, and still be traversed by using an road accessible to the public, but from which you should not escape to the surrounding fields: in that case you'll need to tag that road with access=yes for such permission, but still with danger=mine_field expliciting the nature of the danger (because there's won't be signages all along the road, but only on a few points, and not necessarily a very solid barrier or fence all along the road as it could just be a classical water drain). Verdy p 09:04, 12 February 2012 (UTC)

What kind of barrier is a parking block?

These things are sometimes placed across a road that is under construction (or, in the case I'm dealing with, constructed but caught in the housing bubble collapse). What should I tag them as? --NE2 16:15, 10 January 2010 (UTC)

Strangely, that looks like an extreme case of a traffic_calming=bump to me. Alv 22:16, 10 January 2010 (UTC)

Well, yes and no. It's clearly placed to keep traffic out, not to calm traffic. --NE2 22:27, 10 January 2010 (UTC)

Slope, not quite a retaining wall?

What should be used for an artificial slope like here? --NE2 12:37, 8 February 2010 (UTC)

Ladder passing?

There's fence that allows to be crossed by ladders. What tag should I use to map them? --Dejv 12:10, 23 February 2010 (UTC)

That would be, I believe, barrier=fence for the fence, and barrier=stile for the ladder. --Gorm 11:48, 4 July 2010 (UTC)

"Kent Carriage Gate" or "Kent Carriage Gap"

Searching "Kent Carriage Gate" with Google results only in OSM pages, searching "Kent Carriage Gap" results in several websites, e.g.

Thus I propose to use "Kent Carriage Gap". Willi2006 09:03, 15 April 2010 (UTC)

+1 --vsandre 16:58, 4 May 2010 (UTC)

They sound rare, and indeed the restricted byways you'd find them on are quite a rare kind of road. There are no instances of them in the OSM database as of now. May I suggest an alternative scheme? Kent gaps consist of bollards, so let's tag as barrier=bollard vehicle=no carriage=yes horse=yes description=Kent Carriage Gap instead of inventing another barrier type. --achadwick 09:49, 14 February 2012 (UTC)

more barriers

[1]

Horse hops / horse stiles
Motorbike inhibitors
Horse friendly vehicle barriers

--vsandre 17:00, 4 May 2010 (UTC)

Traffic Island

A traffic island is a barrier for cars, because cars can not turn there.

A traffic island is a barrier for pedestrians, as maybe you'll have to wait for another set of traffic signals.

A traffic island is a barrier for wheelchair drivers, because there are often curbs.

This might be a node (in the middle of a mini roundabout)

or a way (deviding two driving lanes)

or an area (a approximately triangular traffic island at one corner of a crossing, where the traffic turning right has its own lane).

Comments? --Lulu-Ann 15:42, 11 May 2010 (UTC)

I do not think it is barrier=* so better use highway=* or landuse=*, you can then add other tags like sloped_curbs. --Skyper 16:13, 17 May 2010 (UTC)

What is your argument? I don't see why I should not be able to add a sloped_curb to a barrier. It is surely no highway, as it is not sensible to route someone around on the outline of the traffic island. It is no landuse, this would only make sense if we had a landuse=street, too. I think it is good as a barrier, because like through other barriers there can be footways leading through. Lulu-Ann

You can use all highway=* for closed ways (areas). highway=pedestrian, highway=footway and highway=service are often used for closed ways. A few month ago, Ævar Arnfjörð Bjarmason suggested on his blog and on talk_en a nice use of highway=* with closed ways to outline areas of the footway, bicycleway and even streets.

And I am open for a new landuse=street.

There is no possibility for a footway to lead through barrier=fence, barrier=wall, barrier=retaining_wall, barrier=hedge, like it is written on Barrier there has to be a shared node with barrier=entrance or barrier=gate. --Skyper 11:11, 21 May 2010 (UTC)

Or the barrier can be split into two sections, that leave a gap where the footway is - i.e. three nodes. Except for retaining_wall, for which it makes sense to have highway=steps intersecting the barrier way. Alv 14:32, 21 May 2010 (UTC)

Drops as barrier (ha-ha)

I'm looking for some way of representing drops as a barrier, including the ha-ha ([2]) and other sudden drops. Indigomc 21:25, 15 May 2010 (UTC)

You can tag barrier=retaining_wall, which is about close. The problem comes with elevation which is not well established in OSM so far. --Skyper 10:27, 25 May 2010 (UTC)

elevation you mean ele=* or height=* --Sergionaranja 07:58, 26 May 2010 (UTC)

Sorry, I meant there is no 3d so far and ele=* is not set every 10 m. --Skyper 14:55, 28 May 2010 (UTC)

Bund barriers used in spate irrigation

During the tracing of Yahoo imagery in the context of the Pakistan floods of 2010, I came across many examples of structures which, after some investigation in Wikipedia, appear to be reservoirs for use in spate irrigation. The barriers which are used for water retention, the earthen mound ridges, are referred to as "bunds", singular "bund" (bund at Wiktionary). Looking in OSM doc, I find this value has not been previously; i.e. barrier=bund has not been put into use. An example of my use for this tag-value pair: 73925583 . As for rendering, if we want to recycle the most similar barrier type, I would suggest it be rendered using the same line type as barrier=retaining_wall; the bumps indicating sidedness would be on the outside of the water retention area. If we want to render this as a new line type, I would suggest the same line format as for retaining wall, but in the blue used to render water. --Ceyockey 01:23, 23 August 2010 (BST)

P.S. one alternative to barrier=bund could be barrier=embankment, which is used in seven instances according to OSMDoc. --Ceyockey 03:36, 23 August 2010 (BST)

barrier=step

I would suggest an extension of value set to include "step", implying access=no for wheelchairs, implying step_count=1, to be used for traffic islands and landuse=grass in urban environments. --Ceyockey 14:03, 25 September 2010 (BST)

does not highway=steps suit you? --Sergionaranja 20:19, 28 September 2010 (BST)

Not if what I'm trying to map is a curb-bounded piece of greenery in the midst of an otherwise flat parking lot. Other suggestions as to how to map this would be appreciated. --Ceyockey 01:21, 29 September 2010 (BST)

Gated access, with personnel

How should we tag gated access to various facilities?

military bases (armed personnel)
private property, such as gated communities (security personnel)
inspection gates similar to customs, such as those that ensure against bringing certain agricultural products (some are in California) but obviously are not customs

maxspeed=0, but anything else?

-- Dandv 01:13, 2 November 2010 (UTC)

Speaking from past experiences, Military bases and gated communities should be tagged as barrier=(appropriate physical description that fits one of the more commonly-accepted tags) plus access=private on the barrier. If there are units guarding the barrier (security guards, military police, etc.), I suggest this tag: barrier:personnel=yes or barrier:security=yes. --Ianlopez1115 02:05, 2 November 2010 (UTC)

What is the difference between access=private and access=no? Key:access says that access=no means "Access by this transport mode is not permitted, public does not have a right of way." I think this would fit better a military facility than private access, which seems more suitable for company parking lots, for example. Otherwise, when would access=no be used? -- Dandv 03:00, 2 November 2010 (UTC)

I think access=no is for when there's literally no physical access (an unmoveable barrier blocks the way). --NE2 17:47, 2 November 2010 (UTC)

What if vehicles owned by government offices/entities and military vehicles use OSM (or an OSM-based application/service) for routing? access=private is still more appropriate than access=no IMHO. -Ianlopez1115 05:28, 3 November 2010 (UTC)

Does not imply access=no !

It is surely not true to say that a barrier key implies access=no. Let's get rid of this wrong information. --Lulu-Ann 16:30, 3 January 2011 (UTC)

i agree. The whole imply issue is wrong. Thats what the access tag is for. It is it harder to remember all the implies than just tag what you map. --Sergionaranja 07:00, 4 January 2011 (UTC)

Coincident Barriers

It's fairly common for a retaining wall to have a fence or wall at the top of it to keep people from falling over the edge. Should these be tagged as barrier=retaining_wall;wall or as two different ways? --Hai-Etlik 07:57, 17 January 2011 (UTC)

Entrance

See also Talk:Proposed features/entrance where some small discussion of barrier in the context of entrance has ensued. --Ceyockey 13:11, 31 October 2011 (UTC)

No door?

The tag "barrier=gate" seems not appropriate for an opaque door, which would allow/restrict access through a wall, while it is not possible to see through. Do you agree the tag barrier=door or am I missing some existing tag? Teuxe 12:09, 1 May 2012 (BST)