|
Many ridges, aretes and spurs are part of a hiking path to summit. To define difficulty level of a hiking trail, we must duplicate a way tagged natural=ridge; tag it with highway=path; and then add sac_scale. It does not seem reasonable. Is there any idea about adding sac_scale=* to natural=ridge or natural=arete directly? It seems more reasonable. And is there any software to render such kind of tagging. Besides, the question may be extended. Bikers can ask: "Can we add mbt:scale to ridges and aretes?" What is your idea? |
|
A ridge or an arete is a geographical feature. Period. We tag it with natural=ridge to show the distinct feature on a map and give it a name. A path is something completely different. In OSM we abstract from the physical feature (beaten path to motorway) by drawing a line at the centerline. It's done to show where to walk/ride/drive/etc and again give it a name. A path may follow a ridge or it may not. It may also be in the slope a couple of meters below the ridge line. Paths are also interconnected. You want to be able to find a continuous route from a village in the valley to the next summit for example. So the path following the ridge needs to be connected to the streets in the village and the path on the summit. That's why we need to duplicate the line. How would I know the ridge is supposed to be hiked along if it's not tagged as a path? You want to show how difficult it is to hike there? So put sac scale on the path, because it is a measure of how well the path can be followed not a measure of how steep or rough the ridge is (even if they are related). The ridge and the path could also both have distinct names that we couldn't tag if we re-used the same way. It's also unlikely that the path/route absolutely follows the ridge line, but rather weaves close to it to bypass harder parts. Even when it does this is likely for only short sections.
(07 May '19, 19:19)
SK53 ♦
I understand all you well noted and agree. I'm just thinking that where there is no trail on the ridge and the path is the ridge itself, why we do not reduce the work and optimise the database volume and define the way once for both ridge and the path. If we start applying sac scale to ridges, it is easy for renderers to identify sac-scaled ridges as hiking path and include them in ways for addressing. And the name of the path, where it matches the ridge, is often the name of the ridge.
(07 May '19, 19:23)
babri
2
It's not as if we could not spare a couple of more bytes in the database for an additional way. The benefits of having two way clearly outweigh the advantages of only one way. It's more easy to maintain, easier to understand by human as well as machine, you can have different names etc. We try to have one OSM object per feature. When you write "where there is no trail on the ridge and the path is the ridge itself", you contradict yourself. Either there is no path or there is. It may not be clearly visible, it may not be marked, it may not be popular but if there is evidence that it is walked s add a highway=path by all mean.
(07 May '19, 20:29)
TZorn
1
@babri: I'd be fine with both tags on the same way, but as an INTERIM step, where the actual path/route & the ridge gets refined later. An alternative way is to just to create a second way sharing the nodes of the ridge way for the path. This latter approach is closer to what @TZorn is advocating. (For instance, I've often mapped ridges in out of the way places because having the ridge pattern really assists interpreting the landscape, but no-one seems to render them now).
(08 May '19, 11:01)
SK53 ♦
|
