From OpenStreetMap Wiki
Jump to navigation Jump to search


There's some talk on Talk:Proposed_features/barriers about the deprecation of this tag. Is this to be taken seriously? I haven't seen much in the way of concluding remarks and a ballot on the barrier tag. Ipofanes 15:41, 10 September 2008 (UTC)

There has been some discussion on this topic here [1]. the conclusion can be that barrier=gate is recommended but highway=gate wont be deprecated until its use really falls by use.--Sergionaranja 10:27, 27 October 2008 (UTC)

Gate normally open or closed?

How can I tag a gate, which is usually open but will only be closed at high watermark? -- Smial 10:13, 19 September 2008 (UTC)

I've used a tag 'closed' containing the times a gate is closed. I imagine you can do the same, though obviously it won't be at fixed times in your case... EAi
I now did it this way: [2], but it is still rendered as closed gate by mapnik. -- Smial 23:33, 21 November 2008 (UTC)
Then you could contact people related to the mapnik rendering I guess. Logictheo 06:48, 29 June 2009 (UTC)
It is being discussed on the talk-GB mailing to add to the page recommended 'status' key and values to show if the gate is open/unlocked/locked. See talk archive. - LastGrape/Gregory 19:19, 26 May 2010 (UTC)

Gates and highways

There should be a clarification that a gate can only be a point on a single highway, not at an intersection. Otherwise the direction of the way that is impeded is unclear. This may ideally be made part of Maplint. The trouble is, many gates and barriers appear at intersections, so the highway would have to be split up into several small points, similarly to a bridge or tunnel crossing. Ipofanes 15:41, 10 September 2008 (UTC)

Very often you have a fenced area, with one or many gates within the fence way. Those are intersections which do make sense for me. So you would have to differentiate how Lint should work, e.g. no intersection of >=1 real highways (because the fence is a barrier now). Even then, three highway parts could just meet there from outside (maybe this is what you meant above by splitting?).--Rs 16:49, 26 October 2008 (UTC)

Ability to get around gate

To give an example, Node #266557951, the gate on Cornwall Way as it passes under the railway line. The description is "Prevent motor traffic passing through, bicycle and foot OK". Basically the gate blocks the road but leaves a small gap for bikes and pedestrians to fit past. My concern is I'm not sure if this information is recorded in such a way that auto routing would understand it. Should it have an access tag perhaps?

Forgive me...I am new. Is this the right place to ask?

looks like a {barrier=gate . motorcar=no . foot=yes . bicycle=yes}? (because barrier=gate implies access=no; motorcar=no should not be necessary, but I guess is ok to put it) --Sergionaranja 21:37, 8 January 2009 (UTC)


Mention gates only opened in Summer, etc. Jidanni (talk) 02:44, 13 January 2018 (UTC)

have a look at conditional access and / or opening_hours=*--Dieterdreist (talk) 16:20, 15 January 2018 (UTC)

"Loose" gates

Inexperienced contributors quite commonly place barrier=gate nodes (and all other similar barrier nodes) next to roads. Routers of course will not take such unconnected nodes into account.

  1. Should we make it more clear that barrier=* nodes should be part of a highway=* way?
  2. Do any tools (apart from JOSM's validator) find & warn about unconnected barrier nodes?

--Hjart (talk) 08:41, 22 April 2018 (UTC)

Currently, quite at the top, it reads: "This can be placed on a linear barrier, in the intersection node of a linear barrier and a highway way, or at a highway way node." I would not consider the first possibility (part of a linear barrier without any way) good mapping in general, as it doesn't make it clear to which highway the gate refers. The other 2 options seem to state already what you want, not? --Dieterdreist (talk) 14:32, 23 April 2018 (UTC)
I find a bit difficult to read the sentence you quote and I can easily imagine a lot of contributors less experienced than I will just plain not understand it (what's meant by a "highway way node"), so I think it would be better if the sentence is broken up into a bulleted list with illustrations for each. Anyway, I reported the issue to iD too, so at least iD users soon won't be able to create unconnected barrier=gate nodes. --Hjart (talk) 15:20, 23 April 2018 (UTC)
Of course you are free to improve the wiki. How would you improve the current wording? --Dieterdreist (talk) 16:37, 30 April 2018 (UTC)

Mapping on a way instead of a node?

Back in 2010 the page was changed to allow mapping on a linear way, instead of only on nodes as in the original 2008 proposal and the documentation till that point. See

However, currently there are 1.8 million nodes and 75k ways, so only 4% are mapped as ways, and many of those also have a node at the location of the highway. This is helpful for routing applications, since if there is no shared node between the barrier=* and highway=* ways, it can be quite difficult to handle properly.

Should the documentation be changed to discourage mapping as a way without also mapping as a node? Should ways share a node with the highway? --Jeisenbe (talk) 04:03, 10 October 2019 (UTC)

I am in favor of allowing ways for gates. In the end, they all have a width, and it seems logical to represent them as a way, e.g. when it comes to perimeter details (imagine drawing single posts), and especially wide gates (there are rolling gates with 5-10 meters and more) are better represented as a way. Not sure if we should propose to do both, a way and a node, but even if you opt for just the way, you should definitely add a node at the crossing of the gate and the highway. If several highways that are separated from each other cross a wide gate, you can only with the way model make it a single gate. I would consider 4% of 1.8 million significant by the way. --Dieterdreist (talk) 10:43, 10 October 2019 (UTC)
It's not good practice use a node and way for the same feature, per One feature, one OSM element, so if ways are allowed it should be mentioned that there needs to be a shared road with any highway(s) that cross. --Jeisenbe (talk) 11:04, 10 October 2019 (UTC)
It is indeed open for discussion whether the node shared by a way barrier=gate and a way highway=* should also get a barrier=gate tag. Generally, "one feature one OSM element" is not a problem. There are no such things as "features" in the world, we only make them features by defining a tag for them. We could say that barrier=gate on a node that is part of a highway just means that there is a gate obstructing the highway at this node, but it could be seen as a property (which indirectly suggests there is a gate and only directly constitutes a gate when there are no barrier=gate ways running through the node), while the way would be representing the feature (countable gates), similar to how we deal with bridge=yes on a highway with respect to man_made=bridge for the whole bridge. It is all just a matter of definitions. Something like this will be needed anyway, similar to bridge=yes on highways, because one big gate sometimes must be mapped as several nodes with barrier=gate when there are several unconnected highways passing through it, and if every node would represent a gate it would break the count.
As an alternative you could keep the nodes untagged, but still there should be a common node between the highway and the gate, regardless of its tags. --Dieterdreist (talk) 12:00, 10 October 2019 (UTC)
Re: "There are no such things as "features" in the world" - FYI, I disagree with this. A gate is a real thing that can be defined, just like a tree, a lake, a peak or a building. Map features are real things which we represent by database elements (nodes, ways, relations and tags).
Of course it can be defined, that's what I wrote. But according to your definition, the same physical thing could be one gate, two gates, no gate at all, etc. It all depends on the definitions.
Re: "barrier=gate on a node that is part of a highway just means that there is a gate obstructing the highway at this node, but it could be seen as a property" - Yes, and property tags should be different than feature tags, like atm=yes and amenity=atm
I somehow agree with this, it is desirable to be able to distinguish properties (=another thing is the feature and this tag refers to it) from features (all other tags refer to this). But this does not necessarily have to be through tags alone. A combination of tag and osm-object type would be ok as well.
Re: "the way would be representing the feature (countable gates)" - right, that's why it's better to use either a node or a way. That is an argument for using a linear way for barrier=gate in the rare case when two highways pass through one gate. --Jeisenbe (talk) 12:20, 10 October 2019 (UTC)
There are other situations where we are discussing the usefulness of having several objects with the same tag but different object type to represent different aspects of the same thing, for example settlements (place=village/town/etc.) which can be represented by areas (gives extent, shape etc.) and nodes (represents the socio-cultural/political centre). --Dieterdreist (talk) 16:34, 10 October 2019 (UTC)
Also note Jidanni (talk) 00:52, 11 October 2019 (UTC)
This is an old discussion but still. A gate is not always an entrance in a fence - quite often the gate might be placed between two buildings. If you would only use a node then there would be no barrier between the buildings and I do not consider a good practice mapping a fence or a wall where it certainly does not exist. And also an argument for dual-mapping both a node and a way - consider this an analogue to pedestrian crossing: the node signifies that there is an obstruction along a linear road and includes access restrictions for passing that point, the way describes the barrier itself that is blocking the road and shows that this is not just a boom gate or a bollard that can be bypassed on foot but that it blocks the whole span of the opening. --VileGecko (talk) 15:40, 28 August 2020 (UTC)


Mention how to map often very wide w:Paifangs, and other ceremonial massive gates often seen on borders to countries. Jidanni (talk) 00:52, 11 October 2019 (UTC)

We discussed this on the tagging list a few months ago, because there are also ceremonial / decorative gateways like this in Indonesia. This shouldn't be a gate, because there is no barrier to vehicles or pedestrians. We never really got consensus: some suggested man_made=gantry. Another option is barrier=entrance if the gate is in a wall, though that doesn't imply the overhead archway. If it was part of a historic city wall it can be a historic=city_gate - and actually that tag might be appropriate for the large Paifang's which are city entrancens even if they were not in a way. I also have been considering starting a proposal for man_made=gateway. See discussions at and and (talk) 01:18, 11 October 2019 (UTC)
OK, but some of these double as entrances to amusement parks, and are locked at night. Jidanni (talk) 01:31, 11 October 2019 (UTC)
If there is a gate that is closed at night, then it's appropriate to use barrier=gate. --Jeisenbe (talk) 07:42, 19 October 2019 (UTC)

:type suffix on gate

Hi, this wiki page indicates some gates could be completed with gate:type=* key. Why a :type suffix is helpful here and gate=* isn't preferred? Fanfouer (talk) 21:42, 16 February 2021 (UTC)

I assume people got the idea from fence:type=* in the abandoned and clean-up required Proposed features/Fence attributes. It steadily gained use following addition in 2015. Worse still per***/gate:type/&***/gate_type/&***/gate/, gate=* had much more use before, until it's surpassed in 2017. Furthermore, there's a surge in 2019 for some reason. ---- Kovposch (talk) 13:35, 17 February 2021 (UTC)
Thank you for this extensive check! Well, that will require a discussion at least Fanfouer (talk) 22:00, 17 February 2021 (UTC)

Describe gates actuators

Is there an established practice to describe by which means a given gate is powered?
For instance, barrier=sliding_gate usually got an electric motor to be remotely operated.
If not, would a combination with actuator=electric_motor be acceptable for this? Fanfouer (talk) 21:47, 16 February 2021 (UTC)

maxwidth or width?

The combination with maxwidth is more common as of now, but wouldn't it make more semantic sense to use width=* which unlike maxwidth is not a legal restriction? Also note that for barrier=gate the combination with height=* is more common than with maxwidth and much more common than with maxheight --Dieterdreist (talk) 09:47, 24 February 2021 (UTC)

I suppose we should use width=* for the width of the gate itself and maxwidth=* for the maximum allowed width of the vehicle passing through, just like we do with roads. That seems the more intuitive solution to me. --Bon (talk) 15:33, 12 May 2023 (UTC)

Gates that open on the left, right, middle, etc.

Plan ahead for future rich map detail, by adding tags for gates that open on the left, right, middle, etc.

--/ --
-- \--
--/ \--

Also of course: on the left when standing on the outside and looking in, etc.

Also there might not be an outside and inside: section 1 and 2 of a cattle ranch. Jidanni (talk) 14:05, 23 December 2021 (UTC) (See also )

generally I agree it could be tagged, but be aware that not always there is an outside and an inside (gate between things), and some gates open only in one direction while others in both directions, nonetheless a common definition is when you stand on the side to which the door opens, a right hinged door has the hinges on the right. There’ll even be gates that open to the top (e.g. common for garages), or that are segmented and will be rolled up. I believe what is equally or maybe even more interesting than the hinge position is the direction into which the door will move. And of course there are sliding and rolling gates, i.e. without hinges but usually opening only in one direction as well.—Dieterdreist (talk) 14:26, 23 December 2021 (UTC)
there could be a tag based approach (hinge=yes/no/left/right/both, etc) and a geometry based: map the gate/s as a way and the end node where the hinges are as hinge.man_made=hinge or barrier:fixture=hinge or whatever (these can cover the 2 gates for one opening situation as well (horizontally), another common case are gates that are vertically separated, likeür-Stalltore-geschlossen.jpgDieterdreist (talk) 16:30, 23 December 2021 (UTC)
Please be on-topic in Github for once man.
This should be coordinated with door=*. I have been trying a gate:wings=* in the logic of door:wings=*. ---- Kovposch (talk) 05:42, 24 December 2021 (UTC)
opening:direction=* was suggested in F3DB#Solution_A. ---- Kovposch (talk) 10:56, 25 December 2021 (UTC)
for gates maybe leaves is more appropriate? —Dieterdreist (talk) 12:16, 25 December 2021 (UTC)
Btw "leaf" is used for doors as well. Don't know why door:wings=* was chosen.
There is still much to be done. Eg much divide between barrier=life_gate and crossing:barrier=*.
--- Kovposch (talk) 05:22, 21 January 2023 (UTC)

Retractable factory gate

So a retractable factory gate, that folds up to almost nothing, (in the morning when the guard pushes a button, and the rollers start rolling,) should be tagged as a gate, or a fence? Jidanni (talk) 04:20, 21 January 2023 (UTC)

You could use gate=folding (8 instances). Being the author of Tag:barrier=gate#Comparison, it would be lamentable gate=folding is not used. That would bring it to consistency with bollard=folding. Then the unclear gate:type=single and gate:type=double can still be kept for some undetermined use. For this, as mentioned above, I personally started gate:wings=* to keep uniformity in format and definition with door:wings=*.
Additionally, I raised the idea of cycle_barrier:installation=folding to barrier=cycle_barrier, which can be reduced to installation=folding. Although, now I realized it better be movable=folding to be less sloppy, and consistent with the pattern of bridge:movable=*.
--- Kovposch (talk) 05:15, 21 January 2023 (UTC)

Page clear-up

There is a lot of irrelevant/duplicating information on this page. It's quite confusing. Wiki pages are viewed primarily by newcomers. They need clear, concise instructions on how to map. All wiki pages should follow the 'KISS' principle. Much of 'Additional details' can be removed & Osmarender has worked for eleven years! I plan to makes amendments soon. --DaveF63 (talk) 22:24, 13 June 2023 (UTC)