Proposal talk:New barrier types

partially inconsistent and contra-productive

While most of the proposal is really good, there is a major flaw in it, which makes this proposal as whole unacceptable IMHO.

The proposal mixes barriers that block a road, and barriers that are along a road (cable_barrier, kerb, guard_rail, jersey_barrier). The latter ones are part of the road, and it is very inadvisable to keep them separate. Not only that editing the road would become a nightmare if these things are present, also renders would have enormous difficulties. On a close zoom, these features would be far off the road, but in lesser zoom levels, these features might even overlay the road, making the road invisible.

Also kerb is not a barrier. It is definitely an obstacle for wheelchairs, so there is good reason to map it, but not under the barrier tag.

--BorisC 12:07, 2 September 2011 (BST)

other new values

Have a look at [1] for more types:

• Horse hops / horse stiles
• Motorbike inhibitors
• Horse friendly vehicle barriers

--vsandre 14:24, 12 May 2010 (UTC)

split barrier=gate

I think that we should distinguish gates wide enough for double-tracked vehicles to pass, and more narrow gates where only persons (and maybe bicycles etc.) can pass. This cannot be done with the the access=* key group, because (in my understanding) those tags say what is permitted, not what is physically possible.

We could use width=* or est_width=*, but this would be a quantitative approach. Routers and renderers can hardly make use of this.

I don't know what is the correct English term for narrow gates. Maybe barrier=door?

--Fkv 11:01, 11 October 2010 (BST)

Or use barrier = gate and foot=yes, bicycle=yes. Dmgroom 15:35, 13 July 2011 (BST)

As already noted in the first paragraph, this would just mean the permission. --Fkv 06:24, 21 October 2011 (BST)

barrier=heap

Sometimes a heap of earth or gravel is deposited on an abandoned track. --Fkv 21:33, 6 February 2011 (UTC)

Comments

• swing_gate: insufficiently explains the difference between that and barrier=gate
• rope: "this is a gate usually made of metal bars" - huh? what? this doesn't make sense.
• chain: ok, but remove the section about it being "forbidden" for pedestrians - that's specified by access tags.
• log: good.
• turnstile: good, but how will you specify which direction it can be crossed? most are one-way. I have also occasionally seen larger turnstiles whose goal is to prevent cyclists travelling through too quickly and possibly getting hit by cars. Saw this in Austria. They can be passed while seated on the bike.
• full-height_turnstile: think it should probably be a sub-property of turnstile.

My two cents. Stevage 02:02, 14 May 2010 (UTC)

barrier=gate resembles a fence, while a barrier=swing_gate typically consists of only one horizontal bar. You can easily walk around it, or creap beneath it. A swing_gate looks like a barrier=lift_gate, with the exception that the swing_gate opens horizontally and usually lacks the balance weight. --Fkv 11:19, 11 October 2010 (BST)

Place identification methods under barrier?

Hi,

I would rather see the identification issues under a new namespace "ID", as they can not only be used for access issues, but also to buy tickets, turn on traffic signal's sound signal for the blind etc.

--Lulu-Ann 07:00, 14 May 2010 (UTC)

new barrier kerb

A footway kerb is a barrier for cyclists and wheelchair drivers. The height of the kerb is important and with this information, the usage bei different groups can be determined.

This kind of barrier can be used on types: node, way, closed way

I would prefer following tagging:

barrier=kerb optionally additionally height=* in form x.xx dimension is meters

At a (non closed) way: If it is important to store the information, on which side of the way the level is higher, take

left:height=* for left side of way is higher and

right:height=* for right side of way is higher.

The prefixes left: and right: will be supported bei the JOSM-Editor. If a way with this information will be turned in its direction, the editor asks in a dialog for changing the key from left:height to right:height and vice versa. --Okilimu 18:26, 6 July 2010 (UTC)

Please note http://wiki.openstreetmap.org/wiki/Proposed_features/kerb which covers kerbs in more detail and structure than just using barrier=kerb and height=nn. I think that barrier=kerb should be removed from the proposal. -- Jetthe 23:08, 30 June 2011 (GMT+1)

I've reread the kerb proposal and understood that that is thought of only as a node feature, hence i withdraw my earlier comment as barrier=kerb could still be useful. Jetthe 08:27, 5 July 2011 (BST)

Continuation of the discussion in the voting section: I agree with the argument that kerbs are built with the intention to bar vehicles from entering the pavement. So yes, the sole purpose of a structure might not suit to distinguish a barrier from an obstacle (I'll use this term as long as no one comes with a better one).

I still find the term 'barrier' too strong for describing the kerbs though. A house blocks the path of a car and might let pedestrians through but that doesn't make the house a barrier. Or sometimes there are posts on the pavement to prevent cars from parking (e.g. [2]). They are built on intention and hinder a group of traffic participants in using a way. The same goes for steps or the height information on bridges with regard to trucks, both are worth mapping but they are not described as a barrier. So if you include kerb in this proposal a lot more things would qualify for a barrier, too.

IMHO we should handle the mapping of kerbs as a feature of the way e.g. with kerb=yes and additional information on heights (or kerb=10 for a 10-cm-height or whatever). As routers for trucks would look for height information on bridges (instead of bridges as 'barriers'), so wheelchair drivers or cyclists would look for steps or the height of kerbs.

BTW: maybe one reason for our argument is in a different sense of 'barrier' in some languages? I'm German and the German word 'Barriere' has quite a strong meaning in the sense of blocking someones path as opposed to the weaker 'Hindernis'. That's what I tried to describe with 'obstacle'. Still, a native English speaker should clarify here. --Seoman 11:39, 16 September 2011 (BST)

barrier:personnel

barrier:personnel is very useful tag, but I would extend its purpose and rename it to barrier:enforcement or such. Let it show any means which access is restricted by.

The values may be:

• moral unwelcome — there is actually no legal prohibities to go, but any brought up people understand that he ought to get away.
• legal — for example, there is a sign that prohibits access.
• device — an automatic device, uncontrolled by a human, operates the door.
• operator — device is operated by a human.
• guard — there is an armed guarder.
• soldier — same as "guard", but the guarder is a member of state military forces
• police — same as "guard", but the guarder is a member of state police service.
• dog — dogs in service.
• free_dog — dogs walk freely on the territory and even can walk out of the territory.

• pollution, radiation, biohazard - it is unhealthy to be in this area
• danger - there might be falling rocks or flooding

Island

When I read the turning_circle discussion, at the bottom under "What is the difference with a mini_roundabout?" it states that a turning circle does not have anything in the middle. I am thinking of starting to tag these as highway=turning_circle, barrier=island. I map neighborhoods, like this one, all of the time in Melbourne and Palm Bay, FL. I've seen places in streets where there is a little island splitting two way traffic. It's really not a big island but it would be nice to map without having to split the road and have two oneway streets that are only two or three nodes.

Rendering only needs to be a dot in the middle of the road, similar to Osmarender highway=mini_roundabout. This dot should render over most features like turning circles and roads. --Panther37 01:15, 20 March 2011 (UTC)

Cul-du-sac example with island Maybe it should be barrier=traffic_island with acceptable tagging as nodes and paths. Traffic Island on wikipedia --Panther37 18:36, 20 March 2011 (UTC)

list of even more types...(which could be proposed but at least should be discussed IMHO)

Key	Value	Element	Comment	Rendering	Photo
barrier	traffic_cone				[3]
barrier	delineator				[4]
barrier	guide_post reflector_post
barrier	kerb_extension
barrier	botts_dots cats_eyes
barrier	rumble_strips
barrier	raised_road_marker
barrier	handrail		A handrail can divide an outside staircase into two sections		[5]

Please see this in context of: http://lists.openstreetmap.org/pipermail/tagging/2011-June/007897.html

Regards --Fortunequest 15:11, 6 July 2011 (BST) Additional note: English is not my native language, so please forgive me my mistakes!

Comments

• post_and_chain is redundant, chain will suffice.
• barrier=kerb overlaps with the kerb=* proposal
• merge turnstile and full_height_turnstile, use subtags instead. Stevage 02:47, 8 July 2011 (BST)
  • Or call it "secure_turnstile". That hyphen-and_underscore thing is evil. Stevage 16:16, 31 August 2011 (BST)

Most of the subkeys will better fit in surveillance=*

If a barrier=gate has a keypad, RFID/biometric sensor or a video camera installed, it is still a barrier=gate. The surveillance measures should be separeted from the barrier and will better fit in an extension of the surveillance=* key, as they are not specific to barriers. --Fabi2 01:01, 14 July 2011 (BST)

I believe that rfid or biometric sensor is more like a door lock than a surveillance measure :) --Sarchittuorg 16:45, 1 September 2011 (BST)