From a native (so never as much authoritative as Wikipedia): The only essential defining properties of a Steig are: It it is narrow and it is not paved. It need not be steep, eg. when it runs on the contour line. Steepness is at best a property of the terrain, Steige are in. Where I live, we have lots of steep terrain, almost all of the terrain here is steep.
The maintainers of hiking trails in Austria are to take care, that what has the map signature of a Steig is at least 10 or 12 inch wide, so walking is always comfortable.
I see one problem: If youâd ask me, how to translate Steig into Englisch, Iâd answer with certainty, In English, its called a path.
It also doesnât say anywhere that any kind of hiking trail is excluded. And if youâre new to OSM and have a closer look, thereâs only highway=track, footway and path that are useful combinations with sac_scale, including all values which involve hands. So the use of hands is not contradictory to the current definition and usage of path; for me this proposal would have changed that, which is one of the main points.
If it was only for the people, that want to keep the highway key clean, the proposal would have been accepted. The proposal failed, because too big a number of people obviously are happy with what they can do with path and did defend their use of it.
The suggestion from one of the opponents, to bring hiking map producers on board, so transition can be without downtime might be a game changer, but unfortunately is beyond my capabilities to organise such a roll-out.
If the feature was wider, perhaps 1m or so, I would call it a âWegâ in German, or a âwayâ in English. Most of what is mapped as a path in openstreetmap, we here call âWegâ, like Gehweg/footway, Radweg/cycleway, Reitweg/bridleway. Perhaps. our use of terms is not much different from English, with the notable exception of path, of course. The picture on the OSM Wiki for path does not show a Steig.
Nor does it show a âPfadâ. If you ask me, it shows a way. I rarely use Pfad/path, but when I do, only where the terrain is not steep. Maybe that is the reason, why I use it rarely.
The difference I see is that the approval of highway=path + scramble=yes would be a clear statement that scrambles should be included within highway=path. Although an approval of route=scramble would allow for dual tagging with highway=path it could be made clear that this is considered an incorrect combination (at least eventually). However, a proposal tolerating such dual tagging during a transition period might gain more more support, as it would give data consumers time to adapt.
I can follow this thought. Going through though, I can only see a mechanical edit to heal the double tagging, perhaps disguised as an editor validator suggestion, to make it less obvious.
I suspect it would be easy to get a proposal to pass that is more generic than highway=scramble, I didnât vote on it because that was my major issue with it too (what would be the next one, highway=ledge ?).
What we really need is a generic tag value* that will not be rendered âaccidentallyâ (the main issue with adding more attributes to highway=path), and feels reasonably natural to add sac_scale or other difficulty scales to (this is assuming that untagged ways in a route will not fly). highway=climb would be my favorite, but highway=trail would work too. Both of these have the potential to be misunderstood one way or the other, but that is likely unavoidable.
* I would argue that the actual value is of no concern at all, and could just as well be â123456â, but we still have to give the thing a name that will be used for display and preset purposes.
** micromapping say a scramble as highway=climb climb=scramble would look fairly good to me.
*** and yes this is essentially highway=mountaineering without the implied âmountainâ
Iâd be fine with âtrailâ. It sounds reasonably generic to go into the highway key, after all, trails will get people from A to B. Narrow and unpaved is too little to make it specific, more has to be specified. It was one of the first terms I looked at, before starting to develop scramble which took quite some turns If I understand correctly, it was once a contender for what is path now, https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtrail - I guess then I stopped to pursue this. The work from then is not bad Proposal:Trail (new proposal) - OpenStreetMap Wiki
Uh wait, wouldnât this exactly be the problem? highway=trail sounds so generic that people may just use that tag for non-scrambling/non-climbing paths too. Just look at a random image search for âtrailâ:
I said, I stopped to consider that, it is just too generic. Width and surface could rule out much of what the pictures show. Event then, this would affect practically the whole hiking network. But âdemanding_pathâ is just crying abuse. And climb is worse than scramble, because climb has no upper limit on UIAA or YDS.
While that is true, data consumers would still need to make a conscious effort to process it, and hopefully they would only use it in an appropriate way, Mappers misusing the tag simply wouldnât get the way rendered/routed in non-specialist contexts contrary to the situation with path today, so that should be erring on the harmless side.
That said Iâm not a big fan of using trail either.
With a DWG hat on I see quite a few complaints about âmap X is showing path Y when it should notâ.
Most of the time âmap Xâ is some sort of phone app, marketed to users on the basis that it shows what Americans would call âtrailsâ (i.e. non-city paths). Quite often there is information in OSM about access rights, surface, sac_scale, etc. which just isnât shown in the phone app. The phone app user assumes that because a way from A to B is shown, it is suitable for them.
This is of course the fault of the developers of those problem apps; while some do a really good job of âshould I show this and if so, what asâ, some do not.
I find some of the ânoâ votes a bit frustrating where people have said âapp developers ought to be able to do Xâ. Obviously theyâre correct in one sense, but experience shows that some app developers canât or wonât. Following on from that I think that âhighway=trailâ isnât a good answer because lazy app developers who want to show âtrailsâ will include things that are scrambles rather than paths with the new tag.
Furthermore I would suggest to people voting ânoâ based on thinking that âhighway=something elseâ is needed instead of âscrambleâ or âpathâ; that voting no will mean that we stick with the status quo. If you think that âhighway=scrambleâ is better than what we have right now, please vote yes.
In an entirely personal capacity, with my hiking hat on, I would like to add that some way of getting the information into the database would much improve the usability of OSM for hiking. The requirement is that it enables data users to use the information without interrupting current usage.
The usage of sac_scale and other qualifying attributes does not say âthis here is a scramble sectionâ. It conveys that somewhere on the path you might have to scramble. On a path marked with sac_scale values which might include scramble sections, I would still like to know which parts actually are scrambles.
I think highway=scramble for scramble sections qualifies, though it probably would interrupt some paths which are not really paths. It could be argued that that is beneficial, because it detects false use of highway=path.
I think adding scramble=yes or, say, path=scramble to other highway=* (or route=*, for that matter) also adds the information, without interrupting anything at all.
scramble=yes just in the scramble section is very simple and effective tagging, IMO it carries exactly the same information as highway=scramble, and requires very little in terms of data usage. A data user who can process highway=scramble, should have no problem processing scramble=yes.
path=scramble would be very logical in a highway=path, path=* sequence. But I see a lot of protests coming, I fear for a can of worms if not a Pandoraâs box⌠Forget this idea, please.
Even in a widely optimistic scenario we can only assume that this will make the situation better for data consumers that care but fell in to the trap of using path without looking at details and for whatever reason canât back out of that (for example the devs of OSM-Carto). The lazy lot will just throw in scramble/trail/climb/etc to whatever they are using now so they can render complete routes, so Iâm not expecting the situation with that group to change a jota and donât think we should even try to cater for them.
I would note that a more promising approach to get data consumers to handle âcriticalâ tagging better is the label or badge approach suggested at this years SOTM. Though that was mostly in the context of protection areas it applies equally to the topic at hand.
I disagree. The majority of OSM data users doesnât care the tiniest bit about paths in mountain side. They will do the most lazy thing of them all: nothing. If a data user wants to show these routes, then they probably produce a hiking map. If they are lazy and show highway=scamble in the same way as highway=path, I donât care. They cater to a clientele that should at least be aware of the possibility that mountain paths may be difficult.
There is a world of difference between a data user that actively adds support for a tag and is then to lazy to find a different rendering and a data user who accidentally renders things in the same way because they are not aware of some obscure extra tags they should be looking at.
If I understand correctly, it was once a contender for what is path now,