Talk:Proposed features/Trail (new proposal)

From OpenStreetMap Wiki
Jump to: navigation, search

Default access permissions

Note that OSM_tags_for_routing/Access-Restrictions is full of errors and contradicts the basic definition of highway=path. For this reason the link to it has been removed from all highway=path pages that I am aware of. Adding it to this proposal may cause similar problems. RicoZ (talk) 14:17, 22 August 2015 (UTC)

Wouldn't it, at least in the long run, be better to correct the OSM_tags_for_routing/Access-Restrictions page than to remove all links to it from other pages? – Tractor, 22 August 2015
This might be remotely feasible for things like "motorway" which have firm nationwide definitions although in fact it may be that privately operated motorways have different implicit restrictions than state operated for example. For things like track,path & trail the matter is more difficult. Even when the glaring errors would magically disappear there is currently no feasible plan that would make it practical to reflect the reality. Track&co are either informal or not, requiring two sets of defaults already but they are not firmly defined making it more complicated. In Germany, tracks are implicitly allowed for cars except in forests, natural reserves or whether otherwise posted or some kind of private properties. If that was not complicated enough not even the local authorities know to do it correctly - I have seen perfectly legal parking spaces at trailheads accessible by driving an otherwise unposted track through a forest.. meaning despite obvious intention the parking lot is not legally accessible at all.
The other problem is the interpretation. There actually should be more sets of tables - default if not posted otherwise and translation of national access signs into OSM standards. People who contribute to such tables tend to confuse that and also the meaning of the default as "not posted otherwise" principle with that of most frequent usage.
So there would be a lot to do to make this table work and even more difficulties to make sure mappers and data consumers don't get lost. On the other hand - what is the gain of such tables for tracks,paths and trails? For path, the table caused only trouble without any gain. Won't it be better to say everything (other than global default) should be tagged explicitly - perhaps with one set of access keys for "posted" and another set of keys for "implicit" restrictions? RicoZ (talk) 10:35, 23 August 2015 (UTC)
I really don't think that that page has caused a lot of trouble for the path tag. The problems with the path tag stem from its very own definition, meaning everything and nothing at the same time.
The "default-access-restrictions-for-all-countries" table is possibly a bad idea. Having global defaults for things like track/path/footway/bridleway/cycleway is difficult because legislation varies from country to country. That's true for legislation concerning things like legal access to tracks/paths/trails in woods and mountains, but also for traffic signs and traffic rules on public roads. A blue cycleway sign does not necessarily have the same legal implications in Germany and in Norway.
I think there definitely should be country specific default access values. There should be country specific default values for all kinds of highway=*, including track/path/footway/cycleway/bridleway. It would be rather inconvenient having to add lots of access tags to every single way in the world just because legislation varies from country to country. I think we need country specific tagging guidelines as well.
It should also be made sufficiently clear on the OSM wiki that access tags refer to what is legal usage, not what is possible or frequent usage (it is at least my interpretation that they mean legal access).
Anyway, I'll rewrite the section about default access restrictions on the proposal page. – Tractor, 23 August 2015
The default access restrictions page caused lot of pain for "path". The approved proposal from 2008 said very clearly "by default open to all non-motorized vehicles". The Austrians someday thought oh well this does not apply for us and changed the table but only updated highway=path early this year. This change did retroactively change the meaning of all previously mapped paths without an explicit bicycle=* - there are now 3 competing meanings of path in Austria. As a result at least one bicycle router consider paths as generally forbidden for bicycles.
One simple global default and the requirement to tag all posted or implicit restrictions explicitly is the safer method until the table(s) and algorithms are clearly defined. I have started looking around how this could be done.. (Talk:Proposed_features/access_restrictions_1.5#Any_life_here.3F) but it won't happen quickly.RicoZ (talk) 12:32, 23 August 2015 (UTC)
Regarding the situation in Austria with paths and bicycles, I don't know what or who are to blame: the path tag definition, the default access wiki page or the Austrians themselves.
Regarding the other proposal you linked too (not your comment, but the proposal page), that's way too complicated. Why even bother with global default access restrictions for skiing? I doubt that most countries in the world even have a legislation on skiing (or road access for elephants for that matter). Unless one allows for country specific default access restrictions, that proposal would mean tagging almost every single way with a highway=* tag in Norway with ski=yes.
In Germany and Austria there is certainly abundant legislation regarding skiing anywhere and hunters trying to enforce those. Pretty sure I could also find some 1500 pages of legislative rules concerning elephants on German roads - Hannibal certainly knew why he did not cross Germany. Also since we are in the EU it is compulsory for Estonia to have laws covering every single aspect of high mountains and for Austria to have all nautic and ocean fishing regulations.
Are those skiing paths explicitly posted in Norway or is there a nationwide rule? For the purpose of trails, path etc I would disregard all complicated proposals and promote explicit tagging with access=* or access:implicit:*=* depending on the situation on ground. RicoZ (talk) 14:19, 23 August 2015 (UTC)
On Norwegian roads the same rules apply to skiing as to walking, so you are allowed to ski on the roads except where walking is forbidden (motorways, motorroads or roads with a "no walking" sign). Elsewhere, you can pretty much walk or ski or bike anywhere you like (with some exceptions like walking in people's private gardens close to their house, crossing farmland when the ground is not frozen, crossing railway lines, biking in nature reserves, biking on graveyards etc). So, yes, there is a nationwide rule.
I just checked the Norwegian traffic rules. There are rules for riding animals, but they are not restricted to certain species, so the same rules apply to riding elephants and camels as to horses and donkeys. – Tractor, 23 August 2015.
By the way, I don't doubt that Germany and Austria have abundant legislation on skiing, but I have my doubts about Nigeria or Fiji. – Tractor, 23 August 2015

So what is a trail now?

Listing of the problems of path etc is not sufficient to define it. Having an undefined set of restrictions even less. RicoZ (talk)

The proposal is underway (it is only a first draft). We are going to improve the definition and add a series of illustrations. – Tractor, 23 August 2015.
Changed the section about access restrictions again, cf. your comment above. Haven't changed it back to the original wording though, so there's no link to the wiki page you objectected to in the first place. – Tractor, 23 August 2015.
Yes, I know it is a first draft and also very much like the idea to have trails and fix some of the old deficiencies. I think the basic definition is very important and should be the starting point for everything else. A few pictures won't make it a definition.
The basic idea is quite clear but getting that formulated may turn out to be the hardest part. RicoZ (talk) 14:23, 23 August 2015 (UTC)
Good. I know that formulating a good definition is the tricky part, and also the most important part. Any suggestions are welcome! – Tractor 23 August 2015
So what should it be?
  • non-urban footpath possibly usable by horses and bicycles (to be indicated explicitly)
  • Wikipedia/wiktionary meaning of trail - https://en.wikipedia.org/wiki/Trail - which seems to be basically anything which is not a paved road
I think OSM needs the non-urban footpath more and the question is shouldn't we call it footpath in the first place? Europeans may be a bit unaware of the wide scale of meaning of trail (search "wagon trail") and that might prove problematic. RicoZ (talk) 10:25, 26 August 2015 (UTC)
Do non-natives even recognize what "footpath" means (I've only learned that word through tagging@ discussions)? While the actual/selected highway=* value doesn't matter to experienced mappers, it is a major concern in case of newish mappers. I keep hearing about this "wagon trail" but nobody bothers to explain if the concern is only about a single historic route across a single continent (that I guess is/was "too wide" or something?) or more wide-spread problem? Also, now that I looked, I'm not even convinced that "footpath" would be less ambiguous (probably it wouldn't get mixed up with =track yes, but I think it's much more important to avoid mixing up with =path/=footway than with =track that is much easier to explain and exclude)? Ij (talk) 21:27, 31 August 2015 (UTC)

State of extreme disrepair where environment/nature takes over a constructed way needs to be somehow addressed in the proposal I suppose. I guess it will be one of the trickest things to decide when once shiny footway finally turns into a trail only. Any ideas/thoughts on this are appreciated. Ij (talk) 22:48, 31 August 2015 (UTC)

A slight overlap with footway does probably not harm. Postponing the name issue, maybe some really good tag-name will spring into mind once the general concept is more detailed.
I think I am getting the idea: it is a mix of "trail" as something you can follow and highway=path+informal=yes. Normally the "trail as something you can follow" should be a relation over the segments, or if thats too complicated tag by most difficult segment.
informal=yes is sometimes meaningless or hard to establish, would try to replace it by default properties and permissions instead:
  • "unpaved (or difficult surface like antique cobblestone, nasty gravel) but good enough to walk by almost anyone, otherwise indicate by sac_scale (estimate by most difficult segment). By default not suitable for wheelchairs, pretty difficult for horse riders, impassable for skates. Road cycles could pass with difficulties and some dismounting. Indicate otherwise using class:bicycle*, wheelchair, mtb:scale etc."
  • default permissions: foot=permissive, explicitly tag additional permissions. RicoZ (talk) 12:08, 1 September 2015 (UTC)
I had slight issues in understanding the context of what you wrote in each point but here are few points that might somewhat answer to you:
  • Yes, both informal and official trails exist, the latter ones are often part of some route ("hiking trail/route", "nature trail", etc.). Obviously the official ones might be maintained to some level but the general idea with this highway=trail is that the surface itself is still formed mostly due to walking rather than applying some surface for the whole length (fine_gravel, woodchips, etc.). Then there are the exceptions to this rule that are "trail like" constructs such as duckboards that it makes sense to include them to =trail rather than =footway/path. However, I'm considering adding a rule that would state that "isolated segment/island" of footway like constructs inside a trail network would be better mapped as trail. Ij (talk) 21:30, 2 September 2015 (UTC)
  • I don't mind overlap with footway either but it would be better to minimize it to avoid objections about cases that are not so important (IMHO). The reason for this proposal is the be able to tag at least the extremes 100% correctly. For the borderline cases it doesn't really matter that much to the user if the way is tagged as =footway or =trail. The user might not know by him/herself either which one would be "better". Ij (talk) 21:30, 2 September 2015 (UTC)
  • I think some overlap between highway=footway and highway=trail is unavoidable. I think some overlap between highway=track and highway=trail is unavoidable too. I've seen many logging roads, cart roads and tractor roads gradually turn from track to trail/path when they haven't been used by vehicles for some years. – Tractor, 3 September 2015
  • I suspect that unfortunately any "default properties" based classification solution will lead to quite negative response, even though it makes sense to the map user much more than e.g., the current legal restrictions based access model does. I was more thinking of saying that it's a tricky situation that requires deep local knowledge to know and keep an eye on those detoriating ways in order to determine if they're no longer going to be maintained ("ever"). In practice I think the number of such ways is quite low out of all anyway. Ij (talk) 21:30, 2 September 2015 (UTC)
We could probably agree on "as little default permissions as possible - tag explicitly"? Learning from the highway=path disaster, it is defined to be open for all non-motorised vehicles. In various countries opinions differ whether horses and who knows what else are "vehicles". Furthermore, having an implicit bicylce=yes does in no way mean that it is in any way suitable for any kind of bicycles. Now people are mapping via ferratas as path and forgetting to tag the as horse/bicycle=no (I think most of them are forbidden for horses, not to mention utterly unsuitable).
So foot=permissive or foot=yes should be the default permissions. Further I would state "permissions like bicycle=permissive/yes, horse=yes should be added only if the way is actually suitable for this transport mode".
What I would want to avoid at all cost is the trap of local default permissions/properties. For example in Germany tracks are allowed for all vehicles unless posted otherwise but forbidden in forests and natural reserves. There is no hope a router could deal with rules like that anytime soon, relying on deep local knowledge is just like mapping useless things because not even Germans would be able to tell you if a particular track is legal to drive without looking it up in the internet.
I am not sure default properties would meet such a negative response. The difference between a motorway and highway=track is not given by access and other restrictions only. While there may be some "legalists" most people really map by what they see and this is properties like surface and width. I am sure that if given the choice to map a way as either unpaved road, track or highway=path most users will decide on appearance first (mainly surface and width in this case) even if correct approach would be probably to first ensure whether it is actually an unpaved road and then decide based upon access restrictions. On the other hand someone might map motorways with highway=path+lanes=4+surface=paved + a few other properties perfectly adequately.
For a new object like trail (or footpath) to gain acceptance the distinction from other possible objects must be as sharp as possible and default properties that would be more precise than those of path and track would be very helpful. 90% of people think that highway=path without extra attributes are good for bicycles and horses but as I have read those are a nightmare for routers. So we need to make that better than highway=path and the easiest way I think is to say that by default they should be considered unsuitable for bicycles and horses.RicoZ (talk) 10:51, 3 September 2015 (UTC)
I pretty much agree what you say (I might have earlier misunderstood what you meant with "default properties"). Foot=yes/permissive and wheelchair=no are very obvious and I wouldn't have put more there myself (also some others which you mention such as skates which I didn't even think). But isn't there differences even with foot access between countries so how would that make trail access entirely independent of country defaults? I didn't like the addition of bicycle=yes to defaults myself although _legally_ that'd apply here in Finland too. I've only now learned about the class:bicycle so I need to think it slightly more but couldn't we just say it defaults to -3 on trails (at least for city/road bicycles or whatever they should be called) and tag the shortcut trails that are suitable for them with -1/0. However, I'm unsure if we can just say that please don't tag bicycle=yes although that's close to what I'm doing myself :-), that is, I put no bicycle tag at all for trails that are not suitable to "all" bicycles (I'll probably start using class:bicycle more in the future now that I've learned about it though). Ij (talk) 19:29, 3 September 2015 (UTC)
Access tags are for legal access only, not suitability. The exceptions to this is wheelchair=*.
As I've said earlier, I think we need country specific default access values for the different highway=* classes. Tagging everything explicitly may make sense in countries where they have such an overcomplicated legislation that nobody knows for sure what is legal or not. But it doesn't make sense in countries where the lawmakers have had enough sense to at least make simple and sensible rules for where you are allowed to walk, drive, bike, ride, ski, skate etc. (even though the same lawmakers may have made stupid and overcomplicated laws for a lot of other aspects of life). If the laws are simple, there's no reason to put 14 access tags on every OSM way just to indicate what is legal by default.
As global default access values for highway=trail, maybe foot=yes + bicycle=no + horse=no would be better than the current proposal foot=yes + bicycle=yes + horse=yes. I think I'll change this in the proposal.
I think it's far from true that 90% of the people think that highway=path without extra attributes are good for bicycles. I think that depends on were you are. Here in Norway, current usage of the highway=path tag is actually restricted to the kind of trails/paths covered by this proposal. From what I've seen from the discussions on the wiki, Github and mailing lists, this is also the case in some other countries too. That's the problem with highway=path: It's a complete mess. It can mean anything and everything and everyone has their own interpretation.


I think it should be quite obvious from the definition of highway=trail that is should not be considered good for road bikes and city bikes without extra tags.
I'm not very familiar with class:bicycle=* either, so I'm not ready to make up my mind on a default value for this. Maybe it should simply be left to the routers to decide how to treat highway=trail based on its definition? – Tractor, 3 september 2015


(combined reply) Per definition it is something like footpath so foot=yes/permissive should be valid anywhere.. what else would be left? I doubt it would make sense to make the yes/permissive a country dependent default value, most countries would have both and the difference is not important enough. I am thinking that trail will be a mix of informal and official trails. Default local rules would vary according whether it is an informal or official trail and by whom the trail was established or whom the land belongs. So "foot=permissive" is pretty much anything that can be valid country wide - everything else would be better tagged explicitly. There may be rare countries where all footpaths could have a set of local default access values but not Germany,USA,UK from what I know. We already have path,track for those who prefer to tag the old way and don't need to duplicate those and their mistakes.
As a side note, some other access tags than wheelchair=* imply usability as well to some degree: *=designated implies "intended usability" (currently tweaking it on the respective talk page). *=permissive also implies a certain level of usability because it is not really a legal access value and is applied in cases where a certain transport mode actually occurs (the mapper would not know it is permissive without knowing it is commonly used that way).
Regarding (un)suitability for road cycles without additional tags imho it would be good to write it explicitly so people know they are supposed to tag suitable trails. How to map those trails that are suitable by some kind of bicycles is not the main scope of the proposal and can land in "related tags" section where it won't attract much controversy.
Overall, it is good to mention all things like skates, horses etc for which trails are by default either not allowed or likely to be unsuitable: some people for example map via ferratas as highway=path+ferrata=yes and forget to add horse=no, bicycle=no which is a recipe for disaster. RicoZ (talk) 10:21, 4 September 2015 (UTC)
Sweden, Finland, Switzerland, Iceland, Scotland and Norway all have a general right of access to footpaths. Some rare countries? Maybe.
Access values are for denoting what is legal or not. They are not tags for suitability. Mixing legality and suitability is creating a real mess. There are other tags for suitability: sac_scale=*, mtb:scale=*, class:bicycle=*, horse_scale=* etc.
access=permissive means that the land owner allows access for the general public. The owner can revoke that permission.
access=designated means the same as access=yes but with the addition that the way is designated for the given mode of transport. Normally, but not always, this implies that the way is also suitable for the given mode of transport (because, why designate something if it's useless...). There are unfortunately many cycleways that are unsuitable for road bikes (because the road authorities don't care enough to maintain them) even though they are designated for all sorts of bicycles.
Routing software (like people) should take both legality and suitability into consideration when selecting a route. It should be obvious that it is a disaster to route a horse rider onto a via ferrata. A router shouldn't route horses onto a way tagged highway=via_ferrata, and probably not onto a way tagged highway=trail either. The router should avoid those ways because they are useless for a horse. The router should also avoid motorways, because they are illegal for horse riding. If the routing software is not able to make sensible decisions for highway=path, it is because of its generic definition, requiring additional tags to describe the way in a meaningful manner.
Anyway, this is probably not the best place for a general discussion about access tags. :-) – Tractor, 4 September 2015
ok, I can see that it might be useful for some countries to have default access restrictions allowing bicycle,horse etc - in theory. However allowing that would further reduce the difference between trail and path - and those countries where trails allow horses and bicycles could use highway=path just as well as trails and not worry when (if ever) routers and mappers will respect that Finland has a local default allowing horses and bicycles on trails. If we can not come up with a definition of trail that is convincingly different from path I don't see hope for adoption. I am wondering how many people ever read eg OSM_tags_for_routing/Access-Restrictions#Finland - it says highway=cycleway implies moped=yes unless otherwise posted -- with a footnote saying "Allowed only when additional sign "Sallittu mopoille" is present" which seems to claim the exact opposite. RicoZ (talk) 23:24, 5 September 2015 (UTC)
No, it wouldn't reduce the difference between highway=trail and highway=path. highway=path has a generic definition, highway=trail does not. highway=trail has a very specific definition. There are those who claim that there's no difference between a highway=path and a highway=footway. Are you now claiming that a highway=trail allowed for bicycles and horses would also be the same as a highway=path? A trail in the mountains is not the same as a paved road even though they could both be legally accessible to bicycles and horses and closed for motorised traffic. highway=path by its definition covers everything: highway=cycleway, highway=bridleway, highway=footway, highway=trail, highway=via_ferrata.
If almost all links to that page have been removed, there's no wonder if nobody reads it... If nobody reads it, nobody corrects what is wrong. It should probably be 'no' on a yellow background instead of 'yes' on a yellow background. – Tractor, 6 September 2015
Indeed highway=trail+bicycle=yes+horse=yes looks almost identical to highway=path+surface=ground as good as I understand the text of the proposal. Maybe you have some more differences on your mind? RicoZ (talk) 16:36, 6 September 2015 (UTC)
Then highway=trail+bicycle=no+horse=no must look almost identical to highway=path+bicycle=no+horse=no+surface=ground. If so, and since you are a proponent of tagging all access restrictions explicitly anyway, then the conclusion must be that the only practical difference between highway=trail and highway=path is an implicit surface value for highway=trail. And, if so, is there any need for highway=trail at all? – Tractor, 6 september 2015
Thats the question. I would think there is need for something like trail/footpath, because tagging non-urban footpaths as highway=path cleanly involves adding bicycle=no/unsuitable + horse=no/unsuitable + skates=no/unsuitable for many of those. Too much work and if you encounter a highway=path without those attributes you still don't know if they are just missing because the mapper was lazy or did not have the information or missing because the path is actually ok for bikes and horses. The exact surface is less important - in the mountains I encounter trails with ancient stone stairs and stepstones which are certainly man_made but still have all the properties to make them unsuitable for most bikes, horses etc. RicoZ (talk) 21:54, 6 September 2015 (UTC)
I think yellow color is warning color as such it should alert anyone who really cares about moped. But this is off-topic. Ij (talk) 16:26, 6 September 2015 (UTC)
Given the mess it is, it would be good to play defensively here, IMHO. If bicycle=no is default, it means that one wouldn't need to tag that (in case they'd be trying to tag not-suitable instead of legal access). On the other hand, I wouldn't want to see bicycle=yes on trails, even if that's legal access and thus correct, without additional information using class:bicycle and mtb:scale, and we can strongly encourage adding also those on highway=trail page in case one is adding bicycle=yes. Ij (talk) 09:43, 5 September 2015 (UTC)
If bicycle=no is the implicit/default value, it means that a way tagged highway=trail without additional tags is illegal for biking, including mountain biking. No sensible router should direct a road bike or a city bike onto a way tagged either highway=trail or highway=trail + bicycle=yes unless there are additional tags indicating that the trail is good for "normal" biking. – Tractor, 6 September 2015
This was actually the solution I sort of proposed earlier, that is, set the relevant class:bicycle to -3 by default (mtb perhaps to 0). As sensible routers would do a similar (or the same) solution anyway, it means that we'd only reinforce it explicitly to mappers what any router implementer should do anyway? Ij (talk) 16:26, 6 September 2015 (UTC)
But how exactly? Should it be class:bicycle=-3 + bicycle=no as default or would it be good enough to have it only unsuitable by default? RicoZ (talk) 16:42, 6 September 2015 (UTC)
I think it would be enough to have it unsuitable by default. I wouldn't set a default for mtb_scale; it varies a lot from trail to trail. – Tractor, 6 September 2015
So you think class:bicycle entirely lacks this "unsuitable" from the scale? I thought -3 was supposed to indicate that (not that the definition for =3 then makes sense though as you'd be taking many -3 ones :-)). Ij (talk) 17:41, 6 September 2015 (UTC)
I'm not sure. I don't think I've ever seen a way tagged with class:bicycle, and I think it's a bit hard to say from the short description/definition on the wiki. Maybe all three negative values would fit to trails? I think it's easier just to say that trails are generally unsuitable for road bikes and city bikes. Tractor, 6 September 205

(unindent) I also think that it would be fine just to say that trails are generally unsuitable for road bikes and city bikes unless otherwise tagged. Not sure if it should be "badly suitable" or "generally unsuitable", former would mean that you could get through with some dismounting etc. I am not sure if we can get away well without specifying default bicycle access. It seems tempting to do so and require that suitability should be tagged only if access is ok. RicoZ (talk) 21:33, 6 September 2015 (UTC)

I did some draft text about bicycle suitability, please see if that's ok for both of you. Ij (talk) 07:06, 7 September 2015 (UTC)
Looks OK to me. I've changed the wording slightly though. – Tractor, 7 September 2015.

informal=*

I'm deleting this section from the proposal page:

While many trails are informal, others are officially sanctioned often belonging to an official route. The subtag informal=* can be used to indicate if a trail is informal or not.

Reasoning:

  • As far as I can see, It contradicts how informal=yes is defined on the highway=path wiki page: "Distinguish purposedly built paths from informal ones."
  • There are other ways to indicate that they are part of a formal route:
    • adding trailblazed=yes, if appropriate
    • adding the way to a route relation

– Tractor, 3 September 2015

Ok, whatever. I don't care about informal=yes. I added that for the purpose to explicitly say that informal trails and official (hiking) trails can both be trails. It's currently indirectly said within the definition but not explicitly (but perhaps it's clear enough already?). Ij (talk) 19:07, 4 September 2015 (UTC)
I think it will be clear from the examples, but it probably doesn't hurt to say it explicitly as well. I've added a sentence about it to the definition. – Tractor, 4 September 2015.

Surface

Is there some particular reason why =unpaved was chosen as the default value? I'd have used =ground myself and I think it would be more consistent with the definition (perhaps stating that =ground is a subset of =unpaved). Ij (talk) 07:31, 7 September 2015 (UTC)

No, no particular reason except I wasn't sure if mud, dirt, grass, earth and the undocumented bare_rock and peat can be considered subsets of ground. I've changed it to ground. – Tractor, 7 September 2015.

Trail visibility

I've rewritten parts of the section about trails passing over bare terrain. I've deleted this: With informal trails it is often better to draw the natural feature instead, such as natural=bare_rock, natural=sand, and natural=scree, unless the connection is short and obvious.. Not because I disagree (I don't), but because it's often very difficult to do. For mountainous areas (at least here in Norway) there are often only blurry and misaligned imagery available, making it very hard to map the ground with natural=*, and your only reliable source is your GPS track. --Tractor (talk) 20:29, 7 September 2015 (UTC)

Indeed, mountains are tricky with imagery even if one would have reasonable ortho correction as inaccuracies in the height model easily create large offsets. Do you think it might be possible to somehow rephrase the sentence so that it wouldn't feel so demanding?
I find it useful to see especially natural=bare_rock sections that tend to make trails harder to follow even if there would be some erosion still visible in the (lack of) moss where the trail goes as usually the trail expands sideways to parallel routes as people try to follow those hardly visible trails over the rock. (I don't know if our tagging in Finland is exactly what natural=bare_rock would require though as moss is quite much covering the otherwise exposed surface on places that we call "avokallio" ~ "open rock" and the wikipage of natural=bare_rock doesn't seem to say a thing about moss being allowed or not; on orienteering maps those areas are rendered using light gray, although not rendered on all of them). Not that this would be very important or central thing to the proposal itself so I'm fine either way. Ij (talk) 19:16, 8 September 2015 (UTC)
Yeah, it just felt too demanding the way you had phrased it. I generally find it hard to tag surface=* accurately on trails. It would require to stop and add waypoints on the GPS and take notes every now and then, sometimes every tenth metre. Tagging natural=* accurately is even more difficult. I have no idea if moss is allowed on natural=bare_rock; there are still rocks, but maybe not "bare" if they are moss covered? --Tractor (talk) 21:50, 8 September 2015 (UTC)
It's not too difficult to draw them afterwards _if_ there's good imagery available. With GPS only, obviously much more impractical, I agree.
With experience of mapping thousands trails, I couldn't agree more what you say. The surface _and combinations various other tags_ people propose to solve the trail issue (while still using highway=path) is very impractical in practice. I'm quite sure those who propose them haven't really tried mapping trails on any significant scale (or have done it only in too trivial terrain?). Maybe the splitting might be somehow possible using pen and paper but for this approach to work one needs to map them first with GPS as "trails" (rather than path/footways) and revisit the place later with a printed map. They shouldn't appear like footways in the meantime like they would without those extra tags. If they appear "like footways", it would be incentive to input bogus, "bad enough" data to those extra tags in order to make them trails so this doesn't really qualify as adequate solution. Ij (talk) 08:14, 9 September 2015 (UTC)

My try..

Seems to me that we agree quite good in spirit, yet the text of the proposal page to me reads differently. I will try elaborate an brief proposal and post here when I can find the time. RicoZ (talk) 13:16, 8 September 2015 (UTC)

Scope of the proposal:

  • introduce highway=trail
  • approve previously documented key:informal=yes/no
Rationale

highway=path has been used to map anything from urban street sidewalks to extreme mountain paths or via ferratas. The broad set of default permissions and properties of highway=path is not well suited for some of these cases. Most people mapping demanding alpine hiking footpaths probably do not spend many thoughts whether they should specify horse_scale or horse=no in this situation. Neither would many mappers mapping urban sidewalks with path think about the need to tag them with permissions and suitability for horses and horse wagons.

While almost anything can be mapped with highway=path, any particular path not mapped with a complete set of permissions and suitability tags specifying its properties for foot,bicycle,horse,skates causes problems interpreting the data as it is not clear whether data is missing or implicit default values should apply. It does not help that there are differing opinions considering what the default permissions and properties of highway=path are.

There are designated footways, bridleways, cycleways for those specific uses but nothing that could be easily used to map non-urban footpaths or alpine hiking trails which are good enough for hiking but either not suitable and/or not permitted for other transportation modes. Informal trails may not have official permissions but some uses may be commonly tolerated. Such trails are also frequently not regulated by well defined official permissions but by a vague mix of customary rights and tolerated uses.

Definition

highway=trail : use to map hiking and non-urban trails - good enough to hike but by unless tagged otherwise unsuitable and/or not permitted for bicycles, wheelchairs, skates or anything else.

Default permissions: foot=permissive

Permissions and suitability follow lazy tagging model where usability implies permission/acceptable use unless tagged otherwise. Eg if you tag mtb:scale=1 routers can assume that mountain bikes are actually acceptable there.

Additional tags that can be used

common properties

  • surface=*
  • width=*
  • smoothness=*
  • trail_visibility=*
  • informal=*

hiking:

  • sac_scale=*

bicycle/mtb:

  • bicycle=*
  • mtb:scale=* (does not imply anything for reular bicycles)
  • bicycle:class=*

horse:

  • horse=*
  • horse_scale=*
Data consumers

Routers could follow this strategy:

  • highway=trail without additional tags is suitable for hiking and pedestrian traffic, for pedestrian routing it should be lower priority than highway=footway and highway=path.
  • highway=trail with additional suitability tags such as horse_scale, sac_scale, mtb:scale, bicycle:class can be routed according to the specified tags unless an permission tag forbids it.

Why I changed certain aspects:

  • instead of trying to define the surface as "formed by wear" or surface=ground I simply want a trail which is good enough for hiking but nothing else. I think this easier than trying to define a default surface, there are many combinations of surface and other properties which can make a trail unsuitable for bicycles or horses (head clearance, width, sharp curves..).
  • different philosophy regarding permissions and suitability. Maybe local default permissions could be added at later time but that should be after there is a way to make distinctions based on area ownership, area designation and such.