It seems like the web editor (iD) only suggests and recognizes barrier=log. But it doesn’t seem to fit:
a bigger tree including branches covering a path,
an unmaintained forest trail with multiple logs on the way.
Then often, I also encounter woody debris on a longer path (line), which makes bicycling difficult or impossible. Is it correct to use obstacle=vegetationfor lines in that case, or should I rather also consider taking this into account when tagging with smoothness?
Specifically, I had a situation in this commit where I wasn’t sure what to use. For lines, I tried to evaluate the smoothness disregarding the woody debris. As the path was in bad condition anyway and the debris came on top, I ended up tagging as smoothness=horrible and obstacle=vegetation. But overall it seems to be tricky to distinguish between those two.
For the case where part of the path was impassable by fallen trees, I used a point with both barrier=log (which got recognized by the editor) and obstacle=fallen_tree (which was suggested in the Wiki but seems to be unrecognized by iD). Not sure if that is good practice.
I marked the commit with review_requested, as I wasn’t sure if I did the right thing. It would be nice for me to know what to do in the specific cases if I encounter them again.
I am quite surprised and confused why it is not using standard barrier=
And sadly may be a bit too late to migrate this one as it got quite popular
But obstacle= page defines it not as a specific barrier, but as tag indicating that such barrier is somewhere within the way. And that it is not used at specific location but as attribute of a way.
Though then it is used mostly on points anyway, at least for obstacle=fallen_tree.
It also mentions it as being used by specific organised mapping campaign. Which often is not well known for tagging things in way preferred by general osm community.
Also, I admit that I used few times barrier=log for long-standing obstacle in a form of fallen tree on logic that main issue is the log of a fallen tree.
Assumption on my part, rather than actually reading the wiki!
Having said that. though, Talk:Tag:barrier=log - OpenStreetMap Wiki says “because (at least for the German version) it specifically states “only purposely placed logs, not fallen trees”“! However, that’s NOT on the English version
I am using both tags in exactly this way and I’d say this makes sense as the tags describe different situations.
Deliberately placed logs to block a road or track for public traffic are permanent objects and remain in place for long. It makes sense to map them as node exactly on their position.
Fallen trees on tracks usually are not permanent objects. The may be removed at least from time to time as long as the track is in use but that may take several weeks or months or even years. The obstacle tag is helpful to indicate that a track or path is subject to such fallen trees and that every potential user has to be aware of such objects. That is why I use obstacle=fallen_tree on ways, not on nodes (except in very few rare cases), and in most cases it goes along with obstacle=vegetation and/or obstacle=deadwood.
There are hundreds of tracks in my area which are not permanently serviced and most of them are subject to obstacles. Usually it starts with vegetation and deadwood (fallen twigs and branches), which makes a walk difficult and a bicycle ride hard. Fallen trees are the escalation, making a walk really hard and a bike ride nearly impossible. I don’t think that placing a node with barrier=log at the position of every fallen tree of such tracks would make sense or add value.
As a newcomer, I can’t really judge, but intuitively, obstacle=fallen_tree seems to make more sense for a potentially temporary obstacle. (Though the singular bothers a bit if I have a track that is covered by multiple fallen trees, but fallen_tree in singular seems to be the standard?). barrier seems to be different, semantically, if I look at the other items listed for barrier as all these seem to be more single, clearly delimited items on the way, often placed deliberatly (with a few exceptions though).
However, it really irritated me that the iD editor suggested barrier only and wouldn’t display a nice icon for obstacle=fallen_tree. Depending on how this discussion proceeds, would it be a good idea to propose adding obstacle to the editor as well? Is it part of the editor’s configuration or part of the iD open source editor?
Note that I also am not sure yet if and when vegetation or temporary underground change should/could result in using smoothness. My current approach would be that if I feel like the trails underground is to be expected to be covered with some debris for a longer term (but not overgrown), this would justify using smoothness=horrible or very_horrible for example, rather than using obstacle=vegetation. What do you think?
In the cited case, I had both: bad underground (due to woody debris) as well as living vegetation growing and making the path less usable. So I used both in the commit.
Regarding the point that I added, I would probably remove barrier=log.
I have added the obstacle=* key to some highway objects in the past since it was my understanding that it tells you “beware of obstacles on the way” while a barrier is the node where a barrier crosses a highway.
My main problems would be that (1) wiki claims about use for noting general way status make sense but mismatch actual use and (2) so far such objects for points were marked as barrier= and obstacle= is weird for no good reason. (3) also, barrier=log seems documented and used for that already.
If a way has a serious case of obstacle=fallen_tree, a number of mappers probably don’t want to see how long a stretch of the way is affected. It’s physically quite difficult, as mentioned. And those who persist might no longer care have mapping as their biggest priority once they’re through. So, a node. Maybe, it’s a bit weird for me too.
In general debris that affects the way’s surface is probably better handled with smoothness, like we do with roots and rocks. And/or you can use mtb:scale=* or sac_scale=* if you’re more interested in tagging from a practical usability perspective.
obstacle=vegetation (or the less common overgrown=*) is more for overgrown plants that restrict movement or visibility on the path. Tall grass, shrubs, trees with low hanging branches, small trees growing in the middle of a disused track etc.
For the line case, I’d lean on smoothness instead of obstacle=vegetation. OSM isn’t really meant to record temporary conditions, a fallen tree or a season’s worth of overgrowth gets cleared eventually, and the tag lingers on the way long after the situation changed. smoothness describes the lasting physical state of the surface, which is what actually needs mapping.
It also happens to be the more useful tag in practice: I checked the source of OSRM, GraphHopper, BRouter, Valhalla and OsmAnd, and none of them act on obstacle=fallen_tree/obstacle=vegetation. smoothness is one of the few tags routers do weight on, so it gets you real routing benefit that obstacle=* currently doesn’t.
Same logic on the point case: barrier=log for an actual placed log (per Fizzie-DWG’s post:2), skip a node for a fallen tree that might be gone in a month.
I agree with Fizzie that barrier=log, like all barriers, should be about barriers that have intentionally been set up. Falling trees fit well under the obstacle tag.
In the original proposal the image for log was not very good, because it showed logs but not as barriers. The text IMHO implies a deliberately placed log (as is the case for all barriers), but it is not completely unambiguous.
