Talk:Key:barrier/Archive 1

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)

bollard=rising is the most one according to taginfo (added to barrier=bollard). The RedBurn (talk) 09:59, 20 July 2019 (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)

200px

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)

Second image (which will be removed due to unclear license) is very similar to File:Gartenverein Ardeyblick, Dortmund (1).jpg Mateusz Konieczny (talk) 13:15, 27 December 2023 (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)

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)