Proposal talk:Obstacle

This proposed key is derivated from «Difficult_Passability», I recommend to see these discussion page before.

Alternatives for value «dense_vegetation»

obstacle=dense_vegetation: This key could be changed by landuse=dense_vegetation or similar, but I think that the most important factor is the vegetation like an obstacle, and this key not relates them. Also could be used the key natural=dense_vegetation, with this key happens the same that the key landuse=dense_vegetation. Other option could be use the key width=* or maxwidth=*, but a trail could have two meters of width=* and only a few centimeters be useful because the vegetation impedes it. maxwidth=* reffers to the legal restriction, not to the real maxim width useful in the trail. --Konfrare Albert 17:28, 12 October 2012 (BST)

dense vegetation is not a landuse IMHO, but there is natural=scrub that might be an alternative. --Dieterdreist 10:22, 13 October 2012 (BST)

whatever you call it, but a path through scrub or dense_vegetation may still be cleared. Obstacles (I have been using the barrier tag so far) are features of a way. --09:20, 27 May 2015 (UTC)

In some cases dense vegetation will refers a natural=scrub, but not always... I'm thinking in forests and jungles, for example: tree branches, lianas, creepers, ferns, etc... I think that «dense vegetation» is a broader concept that natural=scrub (limited to one type of vegetation). --Konfrare Albert 22:41, 13 October 2012 (BST)

The key as it only apply to specify that it is impossible to pass. I suggest graduate it to indicate different levels of difficulty depending on the density of vegetation. For example, by changing the value dense_vegetation by obstacle=vegetation and indicating with vegetation=light/medium/dense the difficulty level. Light meant that you could pass but with discomfort, medium that passing is a great effort and dense that pass is virtually impossible. Javiersanp 20:27, 21 October 2012 (BST)

More than once I thought of using the obstacle=vegetation, you convinced me to change it. About to indicate the difficulty with vegetation=light/medium/dense...Although I like very much your suggestion, I think that it's more difficult to guarantee the verifiability. Some comments (like this mail in the list) observed that the vegetation is a variable element. The vegetation that in August is uncrossable could decrease density in November, therefore be needed vegetation=dense in August, and vegetation=light in November. I think that the problem could be resolved if only is used the key obstacle=dense_vegetation (hereinafter obstacle=vegetation) and add seasonal=yes, is understood that the passability is difficult for cause of the vegetation, and this difficulty could change with the seasons (where we could find vegetation light, medium or dense)... What do you think? Muchas gracias ;) --Konfrare Albert 23:55, 21 October 2012 (BST)

You are right with the verfiability of the vegetation key. Also, obstacle_description could be used for that purpose. Javiersanp 23:15, 22 October 2012 (BST)

Alternatives for value «fallen_tree»

obstacle=fallen_tree: This key could be replaced by the tag natural=fallen_tree, but could be a madness to mark all the fallen trees and no provides rellevant information. The fallen tree also is important in relation with the highway=*. Other option could be use the tag barrier=fallen_tree, this option could be complicated because perhaps this key describe other type (intentionally) of barriers (see the discussion). --Konfrare Albert 17:28, 12 October 2012 (BST)

I am opposing natural=fallen_tree, your suggestion obstacle=fallen_tree seems more consistent with the osm scheme. natural=* should be used for geographical features. --Dieterdreist 10:21, 13 October 2012 (BST)

I do wonder how geographically stable a "fallen tree" is. In Belgium they normally get cleaned up within the week, so it's not good to put that in OSM. Do trees stay longer at the same place in other regions? --Sanderd17 17:25, 13 October 2012 (BST)

In my village (near Barcelona) occured a big wind gale in January 2009 (that affected all of Catalonia), hundreds of pines were fallen in the municipally term of my village (thousands in Catalonia). Today (four years ago) some of these fallen trees still are obstructing paths. In a mail was commented that this also occurs in southern Germany (see the mail). --Konfrare Albert 22:28, 13 October 2012 (BST)

The current proposal restricts usage of fallen_tree to single nodes. We have some situations where a large area is covered by hundreds or thousands of fallen trees following a disaster like heavy storms or icing in winter period. In such cases, it might take years to clean-up the area and remove all fallen trees. In some situations, the forestry or natural park decides not to remove them at all, either due to technical difficulties or conservation reasons. In such situations, there is no sense to tag each and every tree as separate node but better to tag the entire way with obstacle=fallen_tree. Do you see any issue with that approach? --Gergely Matefi 13:08, 16 June 2015 (CET)

Alternatives for value «precipice»

obstacle=precipice: In the map we can detect the precipices with contour lines and with the key natural=cliff, but not the relation with the highway=*. Other option could be add the key natural=cliff to the highway=* for mark that the trail is very near of the precipice, but this information won't be certain, and besides the cliff will be rendered above the trail. --Konfrare Albert 17:28, 12 October 2012 (BST)

I think that the contour lines we typically use for OSM maps (e.g. SRTM) are not sufficiently detailed for determining the vicinity of cliffs to a path, but the feature natural=cliff you mention is suitable to describe a cliff. I am not sure if there is a need to attach this to the highway, in the end it is not a highway characteristic but it is a nearby feature, and this property is already spatially stored in the db (as long as the cliff is marked as such). --Dieterdreist 10:17, 13 October 2012 (BST)

Calculating the distance between a natural=cliff line and a highway=* line is a trivial task. Sooner or later there will also be laser scan based elevation models available. (Strictly speaking, they are available already, just not for free.) Both are potentially more exact than an obstacle=precipice tag, because it neither specifies the distance nor the height of the cliff. In summary, obstacle=precipice would just add redundancy and obfuscation to the database. It is also redundant to sac_scale=demanding_mountain_hiking, as the latter implies that surefootedness is required. --Fkv 18:58, 26 October 2012 (BST)

I have a lot of doubts with this value, especially the question: ¿Is it really an obstacle? But your doubts are differents...

I didn't know that calculating distance into cliff and highway was a trivial task, It's a good new for me! But, ¿Could be useful? 1) I think that create a precise vector for natural=cliff it isn't easy 2) The direction of the vector for cliff, determines where is the cliff (at least when is rendered), where is terrain elevated and where isn't 3) You need also altitude of the highway... ¿There aren't too calculations? With this data, I don't know simply if the precipice is visible when I transiting in the trail.

Seems that we need based elevation models if we want to resolve this question...but with the verticality we need a very precise highways. If there are a comfortable path (you can transit with bicycle, but narrow and with a precipice) with a desviation of one or two meters, the contour lines could determine that you are near the precipice (that it's true), or directly in the cliff (that it's very different).

Please, see these photo examples: Mont-Rebei defile (wikipedia) in Lleida (Catalonia), map, map with contours. How determines contour lines where I am? (the fall is completly vertical). The trail could be in the base of the wall (without precipice), in the center (that it's true) or on top (could be a brutal precipice)... The vector highway needs to be very, very, very precise (almost to the millimeter). If I use the sac_scale=*, I must apply the value sac_scale=hiking (for trail, terrain and requirements IMHO I think that I must not use sac_scale=demanding_mountain_hiking)...Therefore, In this case I haven't information about the precipice.

The value obstacle=precipice can be used for new contributors, and it's easy to use. It complies with the premise: «Exists because you can see it». If there is this tag in an highway there will be a precipice, how is it? I don't know, but there is.

Perhaps the key obstacle=precipice also would be used like a filter. With it you can know where must be a cliff, and search it (there is? absence of information: warning? bug?),. and can calculate the distance to the cliff. If there is the key obstacle=precipice, how deep respect for the highway? and can calculate this value. Thanks a lot! --Konfrare Albert 12:24, 27 October 2012 (BST)

Alternatives for value «unevenness»

obstacle=unevenness: The most similar key with this key, could be sac_scale=demanding_mountain_hiking and its superior values (T4,T5 and T6). I think that the major differences are: (1) sac_scale=* indicates a possibility and obstacle=unevenness indicates a fact, (2) sac_scale=* is a general characteristic of the trail and the obstacle=unevenness could be a puntual characteristic of the trail. --Konfrare Albert 17:28, 12 October 2012 (BST)

not sure about sac_scale=* being a "general characteristic", usually in OSM we split ways and set attributes/tags to the parts where they apply to. --Dieterdreist 10:24, 13 October 2012 (BST)

I'm not sure (I share your doubts), but explicit text in page sac_scale could give a solution. Cited of page sac_scale: «A way in a forest that is difficult to walk because of muddy ground and trees or bushes making walking difficult does not classify for T2. Other keys need to be used to describe it's condition.» (see this text in General notes section) --Konfrare Albert 11:41, 14 October 2012 (BST)

Such a way does not classify for T2, but neither does it classify for obstacle=unevenness, given your criterion that "you must use hands". The same criterion also distiguishes UIAA I (and higher) from UIAA 0. There is not yet a consensus on how to tag the UIAA grade (uiaa=* or uiaa_scale=* or climbing:grade:uiaa=* etc.), but the sac_scale=* and uiaa group of tags is definitely where all of this belongs. --Fkv 19:17, 26 October 2012 (BST)

I think that I have a problem with the name of the value...I hope to solve it soon ;) but, exactly, I want to express that «hands are needed». In some cases could be similar to UIAA I or sac_scale ... but if you find a margin in front (for example, 1.5 meters height) completly vertical (like these)...I'm not sure that I must tag this with climbing criteria, especially if the rest of the trail is a cleared track without difficulties. Isn't necessary high mountain routes for situations where you need hands, but these situations will be an uncrossable obstacle for bicycles, motorcars, horses, etc...

The photo of the example, is a trail that you can walk with a baby car or pushing a wheelchair perfectly, but in the center of the route you encounter this change of terrain level; a real obstacle in these situations.

I agree with you, in high mountains routes could be redundant and unnecessary... but, what can do with situations that I pose? Thanks a lot! --Konfrare Albert 09:39, 27 October 2012 (BST)

Personally, I really don't like the term 'unevenness' for what you want to describe. (Something where you'll probably need your hands to climb.) For me, 'uneven' describes gravel, cobblestones, exposed roots on a path under trees or loose stones. If I hear the term 'uneven', I think +/- 10cm and 'wear sturdy footwear and watch your step'. I'm not a native speaker, so maybe my feeling is wrong. And I've unfortunately no better term to suggest. Just wanted to share my worries. If others feel so too, your tag might not be used as intended. --Chaos99 15:25, 24 October 2012 (BST)

You are right, the tool that i use (Optimot) says for unevenness: meaning 1 and meaning 2. I wanted to describe the meaning 1. You understand the meaning 2... Therefore, you are right: the value is confused. In my first proposal I used the value obstacle=needed_hands (see here). Could be better obstacle=sudden_incline? Other option: obstacle=vertical_unevenness? What do you think? Thanks a lot! --Konfrare Albert 19:59, 24 October 2012 (BST)

Alternatives for value «hole»

This value was proposed in tagging list for Eric, see the mail.

There was a proposed key: Proposed_features/Hole (in a road), but I think that is better that hole be considerated like an obstacle --Konfrare Albert 17:28, 12 October 2012 (BST)

I wonder what's the difference between a hole and a pit? --Fkv (talk) 22:28, 17 June 2015 (UTC)

Alternatives for value «heap»

This value comes to proposal for Martin in tagging list, see this mail. --Konfrare Albert 11:51, 14 October 2012 (BST)

There's now barrier=debris.

Pits and heaps do not need to be located on a highway=*. In order to avoid multiple tags for the same thing, man_made=* comes to mind. --Fkv (talk) 22:34, 17 June 2015 (UTC)

Alternatives for key «obstacle_description»

This key was proposed in tagging list for Rob, see this mail. --Konfrare Albert 11:47, 14 October 2012 (BST)

Routability of the tags

I know you want to use this tag for routing, so I want to check how severe those obstacles are (when they need to be avoided).

• fallen_tree: 5 s extra time for the route
• dense_vegetation: half the normal walking speed, or 10 s extra if it's a node
• precipe: no extra time (only avoid for dizzy people)
• unevenness: about 3/4 of normal walking speed, or 5 s extra time for a node
• hole, heap: 3/4 of walking speed, no extra time for a node
• yes: not avoid (use other tags to determine slowdown)

Is this kinda right with what you think about it? --Sanderd17 17:22, 13 October 2012 (BST)

At no time I was thinking In this aspect... probably you have reason in your calculations, but the time isn't important for me.

When you want to avoid a toll, you aren't think in time, you are thinking in money.

When you want to avoid bumps (like traffic calming), you aren't think in time, you are thinking in comfort.

When you want to avoid motorways (you can do this with latest version of OsmAnd), you aren't think in time, you are thinking in ... driving pleasure? approach to territory?

People with less mobility, or people than want walk with little children... perhaps can't continue the route if they find an obstacle like these that are described in values of the key.

If you are a horse rider, you are ready for jump fallen tree?

If you are driving a car, you are ready for enter in a huge hole with you car?

In some cases you don't lose some seconds: simply the route finishes in the obstacle (if you drive a car and you find a fallen tree and you don't have a chainsaw, if you are a person in a wheelchair and find a big hole, etc...)

When I think in this key, evidently I never think in time... I'm thinking in the abilities and capacities (that each one know about theirs) and I want to offer the possibility that each one could personalize the route in function of these.

--Konfrare Albert 22:18, 13 October 2012 (BST)

Ah, ok, so you want that navigation apps use it by offering a list of obstacles you can avoid. --Sanderd17 09:58, 14 October 2012 (BST)

Yes. Thanks for your observation has permitted me specify the objective of the proposal ;) --Konfrare Albert 12:33, 14 October 2012 (BST)

Types of landslides (holes and heaps) and tagging

In the tagging list John was send this question:

«Would the same landslide tag be used both where part of the hill above the road had slid into the road, and where part of the road had slid downhill, leaving a hole?

Also, how would you tag a point where cracks had started to appear, but the full-scale landslide hadn't happened yet?»

See the mail in tagging list.

My response in the list was:

«I'm thinking in a very hard condition... I propose different solutions:

First, you must evaluate the obstacles. Probably one will be better for pass. For example, the heap permites the pass to pedestrians but the hole is difficult to cross it. More landslides could be occured. In this case I propose to use:

• NODE or WAY with tags:

• obstacle=hole
• obstacle:bicycle=heap
• hazard_prone=yes
• hazard_type=landslide
• (optionally) obstacle_description: Landslide with heaps and holes, and more landslides risk.

Other option (not the best) would be use two nodes (In this example, I use the generic «obstacle», that represents impediment for pedestrians). The nodes must be over the highway, therefore one will be first and the other last:

• 1st NODE with tags:

• obstacle=hole

• 2n NODE with tags:

• obstacle=heap

• Chunk of way affected:

• hazard_prone=yes
• hazard_type=landslide

Other option (the bad, for me) could be:

• NODE or WAY with tags:

• obstacle=yes
• obstacle_description= Landslide with heaps and holes, and more landslides risk.
• hazard_prone=yes
• hazard_type=landslide

If there isn't risk of more landslides, you must omit the «hazard» tags.

If only there is risk of landslide that not occured, there aren't objective obstacles in the trail, only a warning. In this case, I propose to use:

• NODE or WAY with the tags:

• hazard_prone=yes
• hazard_type=landslide

--Konfrare Albert 10:34, 14 October 2012 (BST)

barrier vs. obstacle

This proposal should define the difference between barrier=* and obstacle=*. Currently, the barrier=* key is not even mentioned.

2 possibilities:

1. obstacle is all over an area or along a way, while barrier is across an area or across a way
2. barrier is made on purpose to hinder movement, while obstacles are made for other purposes or have natural origins

--Fkv 09:50, 26 October 2012 (BST)

Thanks for your proposal, I have added the difference with barrier=* (see here) --Konfrare Albert 15:52, 26 October 2012 (BST)

I just noticed that the definition doesn't work for barrier=entrance and barrier=retaining_wall which are not made to hinder movement. Some rock boulders which are tagged as barrier=block originate from rockslide. Most barrier=log in forests are not intended as barriers either. --Fkv (talk) 22:21, 17 June 2015 (UTC)

quantification

obstacle=hole/heap may be 1cm or 5m deep/high. It is unclear how big such an object should be in order to be mapped as an obstacle. We can add some additional tags like height=*, but this won't work for the other obstacles:

obstacle=vegetation - this may vary in height. Adding height=<maximum> + seasonal=yes won't suffice because it is undefined in which season(s) it is high or low. It depends on whether and when it is mowed. Whether vegetation is an obstacle also depends on its composition. Grass is less an obstacle than bramble, even if the grass is higher. Shrubs and little trees make tracks impassable for average vehicles, but not for pedestrians and not necesserily for tractors. Stinging nettles are an obstacle for people wearing shorts, but not for people wearing thick pants.

Therefore I think that applications can hardly make any use of the obstacle=* tags, other than displaying neat icons or similar. --Fkv 18:36, 26 October 2012 (BST)

I will try to answer the question in parts:

• Heaps and holes: For holes and heaps, I think that there are an important phrase in description: «that can't be avoid». If you add this phrase to the subkeys, IMHO I think that is more clear where could use this key. A hole with 50cm depth and 50cm diameter in a track with 2 meters width, I think that isn't an obstacle for nobody, and I won't map it. But in the same situation, the hole has 50cm length and 2 meters width, probably I will use obstacle:wheelchair=hole, obstacle:motorcar=hole and obstacle:hgv=hole. I think that it's important to be present that usually holes and heaps that aren't huge, usually can be avoid and no need to be tagged.--Konfrare Albert 09:43, 27 October 2012 (BST)

• Limitations of vegetation value: You're right, this value isn't invariable (fot this reason I suggest to add seasonal=yes). I think that could be similar to combination keys waterway=stream+intermittent=yes for torrents, it's impossible determine when will rain and the torrent will have water and in what level. The value indicates that the trail usually is difficult to cross for cause of vegetation, because there are paths with a tendency to be covered quickly with the vegetation (in my zone, paths that are cleaned can be covered for vegetation quickly). About the magnitude of the vegetation, I agree with you, measurement of the height could be absurd. But I think that the use of subkeys could be useful for to have an idea about the magnitude of the vegetation, and more important, know who has difficults. For example, «Shrubs and little trees make tracks impassable for average vehicles», you can use the subkey obstacle:motorcar=vegetation. About the situation: «Stinging nettles are an obstacle for people wearing shorts», perhaps could be a good idea add tags like vegetation=urticant or vegetation=sharp (or others, or more)...--Konfrare Albert 09:43, 27 October 2012 (BST)

I'm not agree with you, I think that these keys could be useful for purpose of calculating routes , especially when there are a big density of trails and many options to route.--Konfrare Albert 09:43, 27 October 2012 (BST)

areas

The proposal says: "If the hole/heap is very big (diameter > 5 meters) and you use an area, you must add a node in the highway=* for calculating routes purpose." - I don't like that. Mapping the same object both as a node and an area actually doubles the object. Remember that routing applications also have to cope with parking places that are mapped as an area only. They should be able to do the same with heaps and holes... --Fkv 19:31, 26 October 2012 (BST)

Thanks for your observation. I did not like the idea of duplicating the object, but I thought that an area (without common nodes with the highway) could be a problem for purpose to calculating routes. I will change this idea in proposal page. One question: Will happen the same with the fallen tree that obstructs two highways? In my proposal, I suggest to use one node for each highway that the fallen tree obstructs (see here). Regards. --Konfrare Albert 09:48, 27 October 2012 (BST)

I like this

I like this proposal so I'm going to use it and probably we'll resurrect it for Hungary. --grin ✎ 08:47, 5 July 2014 (UTC)

Ok, thanks. I will help you as far as possible ;) --KonfrareAlbert (talk) 09:14, 11 August 2014 (UTC)

One comment from the hu community was well placed though: do not use seasonal=yes because it is usually about the highway seasonability. Use obstacle:seasonal=yes instead. --grin ✎ 08:47, 5 July 2014 (UTC)

You're right. I have changed this key in the proposal page. Thanks. --KonfrareAlbert (talk) 09:14, 11 August 2014 (UTC)