You can have a trail which is indistinct but doesn’t have any major obstacles on it.
Saying that a T1 trail would have to be well cleared just refers to the fact that it has been cleared of obstacles that would make it T2 terrain (roots, rocks, etc). It doesn’t mean that it automatically has a visibility that would be considered excellent.
There can be very difficult terrain with an easy to follow path (lots of markers/cairns/use) and very easy terrain with little to no path - conflating the two isn’t particularly useful imo. A rarely used or informal pass in easy grassy terrain could have a T1 difficulty but a visibility of intermediate despite being clear of obstacles.
I would be tempted to agree unless it is regularly used by hunters as a sort of common route to get somewhere. I will follow game trails (essentially paths created by and mainly used by animals) for some length of time if they make sense and get me somewhere, but I also would agree that they don’t belong on OSM. Mapping every path that deer make would lead to madness.
That feels more like a case where something doesn’t really belong on OSM vs a trail_visibility issue, though I’m not aware of any formal consensus.
this tag is generally about the function. Amenity=telephone with capacity =2 is likely to mean 2 telephones and not that 2 people will fit in the booth (if you look it up in the guiness book of records you will maybe find out that you can cram 16 people in a telephone booth or something like this )
I wasn’t talking about prefixes. I’m sure there’s a discussion to had there, but realistically how much is anyone going to factor in options like capacity:rooms when they are making a passing comment about the main tag in a discussion about something else, or really at all for that matter?
Sure, it could mean that. I don’t think that meaning is inherent to the tag or how it’s defined on the Wiki though.
I guess it’s just the ambiguity of the amenity=toilets tag since I’ve understand it to be more about mapping the room where the toilets are located and really about the actual toilets themselves. I think that’s reflected in how the tag is used to. Like you can have an outdoor restroom facility say a national park tagged with building=* + amenity=toilets all day (and before you bring up building=toilets, there’s like 200,000 uses of the former and only like 21,728 of the later). No one maps the toilets as a separate entity from the washroom or entrance way.
So sure, if you added capacity=6 in an instance like that it could very well mean the exact number of physical toilets. It could also mean the number of sinks, how many people total could fit in the room (which is something they have signs for. I saw a few myself when COVID was going on), or maybe something else entirely. It’s not inherent to the thing that capacity means the exact amount of toilets though. Like if it was a bathroom facility with an occupancy sign it would be pretty responsible for most people to assume that’s what the tag is referring to. Not to mention if a tag is being used on a building it’s generally reasonable to assume the tag applies to the whole building, not specific areas or parts of it. At least in absence of any specific evidence to the contrary.
So am I! So I hope very much that this post will clear the last disagreements and we can update the wiki to address at least some of the problems identified. For me the most important ones are the mentioning of markers and the mentioning of “has to be searched for” for trail_visibility=good, which has been solved to my satisfaction (and I hope everyone else’s…). All the other changes are additional but not crucial for me.
Fixing the text was all I wanted with this post that lead to such a long thread about many other subjects. The tag would probably benefit from more drastic changes like reducing the number of categories, but considering how much effort it is taking just to agree on a text fix, I don’t think I want to spend the effort needed for a major change. I hope the changes we’re making now will be considered minor, so we don’t need to spend time on organising a vote about them.
I implemented these latest texts in the proposal on the talk page.
Indeed it looks like after trail visibility was separated out, the remarks about visibility from the original SAC scale text remain in the German version for T3+. Could you edit the German version so it doesn’t deviate from the English one? There might be other places where texts need updating to conform to the English wiki text.
Indeed part of the difficulties we’re having here is that we’re from different regions with different levels of organisation of hiking. I assume Austria is among the most regulated and organised countries wrt. mountain hiking while the Western USA has lots of real wilderness and very little organisation. I think I am in between: mountain hiking is very popular in Bulgaria, but things are less regulated, organised and maintained than Austria. I’ve also hiked quite a lot in Turkey, where it is not popular and there are few facilities.
I’ve put back all the pictures that were there in the original version, but kept the ones for bad and horrible contributed by @Hungerburg . I’ve also re-added the Controversy section. I think these two subjects should be discussed in other threads.
I hope we’re all happy about the text so it can be published on the wiki?
IMO The text should be put up as a voting proposal. I don’t think having the handful of people that have stuck through this thread have a majority vote signing off on the change is within OSM norms.
Sorry, I will not edit the German Wiki page or JOSM preset. It is not rare that documentation varies from region to region. All this talk here proved, that it is impossible to fix this burden of a key. So it is best left alone to die some day. Hopefully the work of @erutan started in several topics bears fruit.
PS: Been rambling and scrambling today, got by some paths with excellent trail_visibility
Yesterday I reread the proposed changes and noticed that the “subjective” stance got reworded, but I could not make much sense of it. Again, I was left with the impression, that we now can map cutlines as paths. I am not fond of that.
Nah, the whole idea of trail_visibility as split off from sac_scale reminds me of this (you first seen this here, will be on TV only tomorrow, better quality picture of course ):
I agree on the second quote more or less (though I’ve met a people that are good technical gym climbers that have a hard time doing basic routefinding in wilderness), but it’s certainly possible to have a “simple” trail in terms of technique that is hardly visible. You gave an example of a path which went on from a bridge over a grassy hillside that was hard to see or follow despite being T1 in that it wouldn’t be “harder” than just walking in an urban park.
Sometimes cutlines follow power transmission lines over fairly long distances (kilometers, tens of kilometers) and have highway=track of a grade (tracktype=grade3 or so) to support a high-clearance and/or 4-wheel-drive maintenance vehicle for access to power towers. These can often be seen in satellite imagery, if they exist.
I have mapped many man_made=cutlines. They are cutlines. I would not “automatically” consider them a path, even though it is very likely that they might be or are a path. In the latter case, I wouldn’t change any tagging in OSM, even if in the real world I were to use the cutline as a path (because I happened to be hiking in the area and found myself on a cutline and it was a possible route for me to hike to another place I might want to hike to). If I then later fired up an OSM editing session, saw (or entered) the cutline as data in OSM and thought to myself “hm, should I add highway=path here?” I would only do so if there were a clear highway=path (or highway=track) ON that cutline (in my personal experience / from my earlier on-the-ground survey). Especially if I didn’t know there were a highway=path or highway=track there, I wouldn’t enter one by speculation, simply “because it is a cutline and is likely a path.”
I think these attitudes and behaviors are in harmony with “how we map” in OSM.
Amusingly the first photo for “trail_visibility=good” is labeled with the following:
“While the way is not directly visible. As soon as one advances around 20m, way goes up on the right and is very well visible again. Only feature is that for a few (50) meters the trail is not really defined. Orientation is very easy however.”
That photo always confused me, it makes sense with the caption.
The second is better as a faint path through grass.
If “good” can include 50m gaps in visibility that require orienteering, excellent is really the only value which indicates a trail is adequate for the average hiker.
I’ve looked at that photo a few times and wondered where the path is. Never noticed the description, now it makes some sense.
Might it be possible to get consensus here on a better replacement picture that illustrates good?
To go one step further: if changes to the text are too contentious, then maybe we could work on a gallery with pictures from all over the world, with trails of different surfaces and difficulties? Like Key:smoothness/Gallery - OpenStreetMap Wiki We could limit this to examples where there is broad agreement
I honestly wouldn’t consider the faint path through grass one as "good’ in a meaningful sense of the word either. Good is essentially an intermediate value and intermediate is the beginning of bad which continues on for three more vague values.
It’s not a useful key without wording changes, but wording changes will make it (temporarily) more broken than it already is which will probably deter changes passing. I do generally agree with more photo examples being good but I’m not sure the key will really benefit from it and realistically speaking having proper photos would probably break historical usage.
I’ve soft proposed a new visibility key based on discussions and looking at different formal systems that should be more grounded in non-alpine specific reality and verifiable. Ideally this or something like it would slowly take over and then trail_visibility be used as a fallback.
)
):
