Proposal talk:Difficult Passability

use the barrier namespace?

Maybe you could also propose to use some of these values (fallen_tree,dense_vegetation) in barrier=* instead of a new key? --Dieterdreist 14:52, 8 October 2012 (BST)

• Barriers are normally not crossable, but allow exceptions for certain transportation types (and have default access tags attached to them in many applications.) The difficulties described here are normally passable, but have exceptions for certain transportation types (= sub-types of foot). I'm not arguing for or against, just want to highlight the differences.

I agree that 'barrier' is not a good choice. That key should be reserved for intentionally constructed barriers to prevent access of unwanted traffic. On the other hand I don't like the name dif_passability, it is simply awkward. What about using obstacle as the key name? Is the meaning of that term too restrictive? --polderrunner 16:39, 8 October 2012 (BST)

I had problems for decide the key's name. I considered that «passability» could help understand the key. Also is true that could be confused, and the key «obstacle» would be more concrete. I don't dislike this idea. Could be a solution. --Konfrare Albert 20:04, 8 October 2012 (BST)

There are also barrier types which are usually crossable, e.g. entrance or bollard or rope or lift_gate or guard_rail. It always depends on the means of transport. Also a fallen tree is normally crossable if you walk, the same as dense_vegetation. I did not say that all values are suitable for barrier, but IMHO some are.

It is also not explicitly stated that barrier is "reserved for intentionally constructed barriers", the definition is "Used to describe barriers and obstacles to travel.", but the former might be implicitly intended, not sure. --Dieterdreist 19:41, 8 October 2012 (BST)

I understand the possibility to tag «fallen_tree» like a barrier=*, but I have some doubts with «dense_vegetation» because could be a element that exists in a long part of path: ¿I should add the tag barrier to the highway=*? --Konfrare Albert 21:54, 8 October 2012 (BST)

I don't agree that those barrier types are 'usually crossable' as they actually prevent access of some kinds of traffic. Entrances and bollards are usually not crossable by four-wheeled vehicles, for example. Lift gates are generally not crossable until the proper authorization to access has been verified. Ok, the "intentionally constructed barriers" formulation is mine but in my opinion it reflects the intention and actual use of barrier tags in OSM. Nature doesn't intentionally create barriers to humans, it just happens to accidentally leave an obstacle here and there. --polderrunner 22:28, 8 October 2012 (BST)

highway=ford and key:ford

For waterway_crossing there is already highway=ford and ford=* in use. --Dieterdreist 15:10, 8 October 2012 (BST)

I didn't know this key existed (and could permit to avoid to cross waterway in calculating routes). I think that my proposal dif_passability=waterway_crossing loses meaning. I think that could be eliminated of the Proposed_feature page. Thanks! --Konfrare Albert 20:13, 8 October 2012 (BST)

Trail Classification or Difficulty

There already exists trail classification in some places. Wikipedia has it documented under trails. I would suggest using a trail class that could be combined with the reason for the rating. For example class=moderate, reason=steep_slope or reason=fallen_tree

Overlaps/Keys

I like the intention of the proposal. I wished something like this many times, because I search a way to classify hiking trails. But: There are some overlaps with other tags. needed_hands is better specified in sac_scale (T3: possible need to use hands for balance; T4: sometimes need for hand use to get ahead; T5/T6: really climbing). Sometimes i need more than one value. For example needed_hands and with_precipice is often together and dif_passability=with_precipice;needed_hands isn't "elegant". I think its better to use different keys like in my proposal for Safety measures on hiking trails. -- User:unixasket 21:03, 8 October 2012 (CEST)

Needed_hands: I like your proposal Safety measures on hiking trails, and I think that could cover the necessity that I expressed with «needed_hands». In my zone there are a comfortable path (you can walk with a baby carriage), but in the middle of the route you must cross a difficult stone (there are a rope to help you) and after you could continue the same comfortability in the path. Is an obstacle very short in the path (could be applied to a node), but some people can't continue the route. I applied the tag sac_scale=* in this zone but I was sure that not was correct form (there was a concrete difficulty and the key sac_scale was referred to the type of path and this is comfortable in 95% of its route).

With_precipice: In my zone there are an other comfortable path that traces the limit of a abandoned quarry. There aren't any difficult in the path, but the possibility of fall puts the willies, and there aren't any safety (railing, etc). The path isn't recommendable for all people ¿How could be tagged for calculating routes and avoid it? If I use sac_scale=* I must tag it with the minor level of difficulty: sac_scale=hiking. --Konfrare Albert 22:20, 8 October 2012 (BST)