I’ve run into an oddity with the renderers in OSMand, where a handful of trails in my local parks had taken on this garish red color in wide lines. It took a while and a discussion with another local mapper to figure out where it was coming from. Here’s an example of what I was observing.
After a bit of research and multiple overpass-turbo queries, I narrowed it down to the “smoothness” tag set to variants of “horrible” and the like making footpaths show up like this. It took some doing because the trails in question had multiple tags I hadn’t run into before, having to do with mountain-bike ratings, hiking difficulty, etc. Those are all fine for those communities, but my remaining question was, does “smoothness” really make sense for a trail in the woods or mountains? It’s outdoors on natural terrain, it’s going to be highly variable.
The local fix for me was to turn off “road quality” in my OSMand’s details list, but then that also prevents showing actual *road quality* for streets. So I would argue that “smoothness” would apply far less to hiking [or even biking] trails than the other tags that are more relevant to their ratings or modes of transport.
Is it even worth bringing this up again? It kept me confused for about a half day just because it looked so weird on my latest map-file update.
That can be turned on or off on a “per profile” basis, right? Do you need to show road quality for streets when looking at the “walking” profile?
My tentative feeling is that smoothness is of interest depending on the mode of transport, more than the type of road or trail. I don’t think it is of much interest when walking whether on trails or in the city (except maybe when walking with a stroller or wheelchair). But it may be interesting for cycling/MTB, for both urban roads and trails.
As many trails are open to both hikers and cyclists, it wouldn’t be easy for OsmAnd to show this differently for pure hiking trails. So my tentative feeling is they are handling this OK, by allowing the user to (for example) switch it off for walking and on for cycling.
I see this the other way around. Smoothness is very important for paths, especially for biking, but for strolling too - far more than tagging smoothess of a highway=secondary or tertiary (where I live).
It will for some people, yes. Depending on someone’s surefootedness (or mode of transport) it might make the difference between them being able to use a route or not use a route.
And I think it’s important to keep in mind that there will be unavoidable “wheel traffic” on footpaths, too – in the form of wheelchair users and people with baby buggies. Even on a footway or (hiking) path, a wheelchair user will appreciate knowing whether it is “good” or “horrible” to use.
I think there’s nothing against using smoothness on paths: it will be useful information for wheeled traffic (bicycles, motorbikes) as well as for pedestrians. However when it goes into the horrible range, it may be preferable to use sac_scale and mtb:scale instead.
And why are those tags so inconsistent, with one using a colon and one using an underscore?
See, this is another one of the many problems of trying to design disparate areas by isolated committee.
So fundamentally I agree with you: truly bad surfaces might benefit by not having “smoothness” added in the first place.
I’m not convinced there is a benefit here. How would you tag a path in a flat area with a badly deteriorated surface? It would seem very artificial to tag such a path as something like “demanding mountain hiking” where there is no difficulty or exposure.
It would also be counter intuitive for mappers and data users to say “tag smoothness for good to intermediate surfaces but not if it’s really bad”. Plus the eternal problem that if one mapper decides not to tag smoothness for that reason, every subsequent mapper has to ask themselves if smoothness was never surveyed or intentionally omitted.
I understand: smoothness is something pedestrian maps might want to show? (This not the first time I read that.) That means to me, just switching off an optional layer in the viewer will not do. (As mentioned above.) It says to me: Different overlays might want to render the same thing differently
I’m not sure I follow this point. Isn’t switching on and off layers a way of creating different overlays? OsmAnd even allows user defined profiles, so if you want, you could save a “hiking profile” and “walking with elderly relative” profile and “strolling with grandchild in buggy” profile with different options in each one. Is your point that these need to be “pre packaged” rather than user defined?
I don’t think it matters for tagging anyway - if we discourage smoothness on certain types of way, there will be less information for either user profiles or predefined overlays.
I think the default is meansoftransport:scale=* so sac_scale should have been foot:scale. However for pedestrians in mountains the SAC Scale already existed so it was adopted (and modified) for OSM. I don’t see a problem here, what’s in a name?
For paths, yes, but for 2-track vehicles (cars etc.) on roads there is no alternative for smoothness.
