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 <>

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.

Movable bollards

What about 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)


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)

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)


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:


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

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


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:
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)


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)

56 02 17-030408 half.jpg Unknown barrier.jpg 23 05 17-030408.jpg

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)


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!

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

boom barrier

There is no tag for boom barriers (image at 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)


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.


--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 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)

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)

I think the implied “access=no” needs explanations. It is wrong to imply access=no on all barriers, each barrier has (or should have) its own default access restriction (example of documented barriers: bollard, motorcycle barrier). The imply access=no should be applied as a fallback on non documented barriers. It helps routers interpreting unknown barrier tags. This clarification could be added to the wiki page? --Oligo 21:33, 11 October 2012 (BST)

Yes, certainly a barrier=toll_booth should not imply access=no. --NE2 03:11, 12 October 2012 (BST)

Dragon's teeth (fortification)

How would you tag Wikipedia-16px.png dragon's teeth on Wikipedia ?. There are many of them at the Western border of Germany, see for example: (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)

I suggest tag:military=dragon's teeth or tag:military=antitank block associated with tag:barrier=block and with tag:historic=yes or tag:historic=ruins.
Somebody use simply tag:barrier=tank_trap. See tagwatch

In switzerland, see for example Wikipedia-16px.png Ligne des Toblerones on Wikipedia.
--Pyrog (talk) 09:02, 14 June 2013 (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 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


  • 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: Way 73925583 (XML, Potlatch2, iD, JOSM, history) . 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)
I would say you have encountered a local form of Dykes/Dikes/Levees or Dams rather than barrier=embankment (I have just written an unofficial proposed definition for barrier=embankment in another comment below, my proposal distinguishes embankment barriers from water-dikes as being substantially different structures in appearance and purpose).
Jbohmdk 23:34, 9 June 2013 (UTC)


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

Military facility access gate.jpeg

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)

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)


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)

soil barrier / Earth Wall?

Embankment? [3], see here

I think your links are referring to the barrier type known as an Earth Wall (There is no appropriate English Wikipedia article for this), that is a barrier formed by piling up Earth to form an long narrow artificial hill, like an upside-down ditch. Unlike the old link to the archeology page about historic earthworks, earth walls are still being built as barriers, primarily as sound barriers along noisy roads. For example here is a newspaper photo of one built in 2001.
Despite the inclusion of the word "wall" in the English name of this barrier type, it has little similarity to a wall and is not so named in many other languages. The form of barrier I am thinking of generally has no wall, palisades or other significant barrier structure on top. It is like a dyke without water. And is often covered in light vegetation such as grass, bushes or young trees. Flowers are occasionally added for decoration where budgets allow.
The one example I could fine in non-English Wikipedia: Landweer (nl) (second photo, not the drawing that includes two ditches), the word in Danish is "vold" (second dictionary meaning, not the one with a Wikipedia article).
Jbohmdk 23:53, 23 May 2013 (UTC)
After some more searching and browsing, I have come to the conclusion that the most appropriate tagging would be "barrier=embankment", and I have some ideas about how to define and clarify the various embankment tags in different categories, however the current "proposal" process seems to be too much work for an occasional mapper like me (It assumes the proposer will work the process like 20 hours/week for months or years).
So here are (without fancy templates), my proposed definitions:
On osm, an embankment is an artificial (man-made) long narrow "hill" which outwardly appears to be made mostly of soil, sand etc, but may or may not be internally strengthened with other materials. Unless otherwise tagged embankments are symmetrical, i.e. the surrounding land is at about the same level on both sides and a single way tagged as an embankment is assumed to rise steeply from the surrounding land on both its left and right. All embankments tags are applied to ways, which track the approximate center line of the top of the embankment.
Embankments have been built since prehistoric times and are still being built whenever needed, since they tend to be a cheap way to get the desired functionality, which may be anything from fortifying a military compound to just needing a pretty use for the excess soil from digging out a school basement.
In accordance with the principle of mapping what is visible "on the ground", embankments are tagged according to the first of the following tags which describe its relationship with other objects:
embankment=yes Another linear feature, such as a road, railway, canal, fence, wall etc. runs on the top of the embankment and the embankment looks like its primary purpose is to keep that other feature at a desired level above the surrounding land. To map this, draw the way that is at the top of the embankment and then add embankment=yes to that way, similar to how you would add bridge=yes if it was running on top of a bridge. Because this is an attribute of another feature, it may be used even if the embankment rises as little as 0.5m/2feet above the terrain, though it would mostly be used if the height is greater for most of the affected length. On paper maps this attribute is traditionally rendered as a line along each side of the way with short perpendicular lines outward from each to symbolize the steep slopes down to the regular surface, and this also seems to be how some OSM-based renderers draw it.
Dike/Dyke (proper tag unknown and possibly undecided by the project). The embankment has been erected to stop water from getting from one side to the other. The water may be always there or only during floods. The most famous example are the massive dikes which allows Holland (part of the Netherlands) to function as dry inhabitable land even though it is mostly below sea level and was formerly part of the seabed of the Atlantic Ocean. (Note that some of the famous Holland dykes do in fact carry roads or canals on top and thus might be tagged accordingly). Someone else has made at least one proposal for these, and my proposal is not intended to conflict with them nor to endorse them.
barrier=embankment plus embankment=yes (This is the only thing intentionally new in this proposal): The embankment stands on its own with nothing on top (except perhaps vegetation and/or a narrow unofficial walking path) and serves primarily as a barrier for anything other than water that might wish to cross it, including sound in the form of traffic noise. As a standalone map feature, it should be drawn only if it is at least 1.2m/4feet tall for most of its length. As with other barriers, openings may be tagged as points without splitting the drawn way in two. It is suggested that renderers draw this the same way as other ways with the embankment=yes tag, but with either no extra symbol for the stuff not on top of it or a generic barrier symbol, where an opening is tagged as a point on the barrier way, rendering of the embankment decoration should be interrupted to show that passage is generally at ground level even though this is not explicitly tagged. Routing algorithms should simply treat it like any other impassable barrier (such as barrier=fence) with the same possibility that gates and other openings may allow passage at designated points.

Jbohmdk 20:29, 9 June 2013 (UTC)

Remove Rendering column

I propose to remove Rendering column. Renderings are renderer specific and should be discussed on their own page. And some images are not meaningful as they were generated with the now unmaintained Osmarender. --Oligo (talk) 19:28, 15 July 2013 (UTC)

I agree. If rendering examples are deemed useful, then I would prefer adding them to a gallery on the tag pages (e.g. barrier=bollard which already has two such examples). This would allow for adding more than one renderer. --Tordanik 23:55, 15 July 2013 (UTC)
This would be better discussed at Talk:Map Features -- note that the majority of tables have a single Rendering column. --goldfndr (talk) 01:41, 16 July 2013 (UTC)


How to map handrails? If is very often around stairways. --Jakubt (talk) 00:48, 24 January 2014 (UTC)

See Key:handrail for handrails. --Tordanik 16:26, 24 January 2014 (UTC)


I noticed that we do not have a tag to describe acoustic screens located along streets or roads. What kind of a name for the tag would be the best to describe these screens? --Władysław Komorek (talk) 11:32, 14 August 2014 (UTC)

There's a tag documented: barrier=wall, wall=noise_barrier --HeikoE (talk) 08:16, 15 August 2014 (UTC)


In Greece they love to chain dogs at the side of a road, preferably one on each side. If the dogs are fierce enough, this virtually stops any sheep or hiker to pass, while vehicles can cross the barrier without problems (Cf.: Crete). How can we tag this? --GerdHH (talk) 14:56, 28 October 2014 (UTC)

Haha! :)--Jojo4u (talk) 18:36, 25 March 2015 (UTC)

barrier to block cars but allow bicycles to pass

How to tag barrier that blocks wide vehicles but allow bicycles (or probably also motocycles) to pass? See the picture. Barrier bicycle pass.jpg --*Martin* (talk) 21:04, 27 March 2015 (UTC)

I guess Tag:barrier=cycle_barrier with the appropriate access tags is the best fit. --Jojo4u (talk) 21:31, 27 March 2015 (UTC)

Gates that open sideways

Which barrier=*_gate should be used to gate where the obstable part is moving sideways (not lifting nor swinging)? barrier=shift_gate? -- Ij (talk) 19:06, 14 September 2015 (UTC)

Photo sensor

How to map a sensor barrier? Something that counts vehicles or triggers an alarm, usually found to protect properties in a discrete way. Sometimes they are complimentary to a another barrier, for example to alert a guard down the road that a vehicle is approaching.

Access through barriers - legal or technical?

When there is a barrier with an access tag, does that access tag refer to the ability of passage for a particular type of traffic or what is legally allowed? For example for a gate on a track that you can legally walk through, but not legally (only technically) drive through, should it be tagged with 'foot=yes' and 'motorvehicle=yes' or 'motorvehicle=no'? --Abc26324 14:35, 15 December 2015 (UTC)

We usually tag the legal restriction if it is known. --Hedaja (talk) 19:29, 2 March 2016 (UTC)

I think what is usually done is to tag the combination of both. It certainly is not just the legal restriction. If you can't drive around a bollard, then it's motorcar=no, even if there is no sign or anything visible. --Tordanik 22:12, 2 March 2016 (UTC)


I had a discussion regarding special gates for animals (for example in enclosures). I'd like to document the new tag barrier=animal_gate. and the gate:type=guillotine.

If no one has any objections, I would make a wiki page for animal_gate and gate:type.

Cheers --Hedaja (talk) 19:26, 2 March 2016 (UTC)

Glass Wall

I have faced with the problem of mapping glass material wall (like this). How to map this? Santamariense (talk) 02:54, 3 May 2016 (UTC)

Looks like some type of fence to me. There are 30 occurences of barrier=fence+ fence_type=glass.--Jojo4u (talk) 07:35, 3 May 2016 (UTC)

'Bus gate'

In Aberdeen, Scotland, a 'bus gate' has recently been added. This is simply a narrowed area of the road with a road sign indicating that legal access is only for busses. It may soon have CCTV enforcement. There is no physical barrier. At first I thought to split the road with a very short way with appropriate access tags but that doesn't seem like a great plan (not explicit enough), so now I've mapped it as a barrier=gate. This also seems slightly misleading as this implies a physical barrier that doesn't exist. Any ideas? Here's the barrier on the map, and here's a picture of the bus gate in question. Spark (talk) 22:40, 9 June 2016 (UTC)

In my opinion if there is not a barrier, you should not map it as a barrier. Just split the way and put the appropriate access tag. It can be useful if you can also map the traffic sign. -- AnyFile (talk) 19:58, 10 June 2016 (UTC)
Thanks, the problem with splitting the way is that there is no access restriction on either side, cars can drive right up to the 'gate' from either side, they are just not allowed to pass through it. So if I was to split the way I'd end up with an unmanageably tiny way with the access restrictions on it. This doesn't feel right, and the distances are too small to map accurately. Spark (talk) 21:56, 10 June 2016 (UTC)