On Mon, 6 Apr 2020 at 03:27, Adam Franco <adamfra...@gmail.com> wrote:
> Thank you for putting together this highway=path + path=mtb suggestion, > Andrew. This is first suggestion on this thread that has felt like a good > direction forward. First and foremost, mountain bike trails are paths, > anything further is a qualifier that adds precision, but not a > contradiction. > > In contrast, proposals to change to leisure=track feel wrong because these > are routable ways and dropping highway=* removes them from the routable > network. > In theory you could still include leisure=track in your routable network, but it needs more fine tuning hence less likely "out of the box" and isn't ideal in my opinion. > Similarly, fiddling with access tags to imply mountain-biking trails feels > like adding too much inference and dual-purpose to these tags that then > complicate the access scheme. In general, I think expanding the path=* > key would be a good way to add additional precision for other "special > purpose" paths. > > I'm a long-time mountain biker and also a bicycle commuter, so I can > sympathize with both camps. While my area (Vermont, USA) has some > special-purpose mountain-bike trails (with ramps and the like) that are > built at ski areas, most of our trails are built and cut by and for > mountain bikers, but are also used by trail-runners and walkers. The "built > for mountain bikers" part means that they have been sculpted to follow the > terrain in a way that is fun on a mountain bike, with turn radii and grades > that allow a flowing cadence. Often elevation gains/drops are managed to > optimize for time coasting downhill, rather than dropping steeper than is > needed only to have to climb again. These trails are also usually great for > hiking/running, but also feel great on a bike. In contrast, a trail "built > for hiking" might not worry about twisting between some large jumbled rocks > that tires simply can't traverse, or might use steep, straight grades and > stairs that "waste" elevation gains in a way that is less-fun on wheels. > Long story short the vast majority of specialized mountain-bike trails > *are* highway=path, they are just a particular flavor of highway=path. > > I would strongly support a formalized proposal based on what you put > together. > Good to hear that feedback In my proposal I'm agnostic to built/maintains it, and agnostic to if it's officially sanctioned or not, so path=mtb would be based on how it's built/who it's built for. On Mon, 6 Apr 2020 at 04:50, Volker Schmidt <vosc...@gmail.com> wrote: > It sounds as we have not yet made clear the difference between MTB routes > and MTB leisure tracks. The former are routes that are suitable for > mountain bikers, but they are on ways shared with other users, whereas the > latter are for the exclusive use with MTBs - no other user is admitted. > That is a similar distinction as between a road and a motor racing track. A MTB route is just a relation with type=route + route=mtb, usually a signposted collection of smaller track segments, it could go over other track types like highway=track and or designated mountain bike trails (as proposed highway=path + path=mtb). On Mon, 6 Apr 2020 at 14:16, Jonathon Rossi <j...@jonorossi.com> wrote: > On Sun, Apr 5, 2020 at 5:49 PM Andrew Harvey <andrew.harv...@gmail.com> > wrote: > >> [...] >> > >> bicycle= as an access tag should refer to any class of bicycles by >> default. Today I was walking a track which had a no bicycles sign, meaning >> all types of bikes are disallowed. Conversely bicycle=yes just means that >> bicycles are legally/physically allowed, it does not indicate suitability >> by a specific type of bicycle. I don't think I've ever seen signage which >> says no mountain bikes but you can use a road bike, or vice versa. If there >> is then we should use sub bicycle access tags like road_bike=, mtb=, bmx= >> etc. You could have a path which is clearly a mountain bike track but >> officially bicycles are not allowed. So based on this we can't use these >> kinds of access tags to define the type of path they must be kept >> independent. >> > > Agreed, land managers don't define different access by type of bicycle, > because at the end of the day what is a MTB, I had a MTB without suspension > when I was a kid so it's not suspension, a MTB is just an advertised > bicycle with heaps of features which has continued to change heaps in the > last 15 years with technology, even today the range of features and price > is amazing; eMTB is another category that is different per region/country > whether land managers treat them as a bicycle or motorbike based on their > power output. > > In my experience of riders I've met, the trails you can successfully ride > are much more determined by your skills and ability than the bicycle you > are on. > > Not all mountain bike tracks are mtb=designated. Many paths are built for >> and used mostly by mountain bikes, key giveaways are jumps, corner banks >> and other technical features, but not officially signposted or marked for >> use by mountain bikes. Conversely the track could be signposted for use by >> mountain bikes but not actually be a mountain bike track, eg. it could be >> highway=track which is not a mountain bike track, but indicated as a way >> for use by mountain bikes so mtb=designated. >> >> So I'm proposing the access tags bicycle= refer to any/all bicycles. mtb= >> become an access tag (mtb=designated for signposted mountain bike). >> path=mtb become a tag to say the path on the ground here is designed=mostly >> used for mountain biking. >> > > Around here 5 years ago there were few MTB trails actually signposted, > they had existed for many years but only as the parks got more use had land > managers spent money to signpost the trails. When would I use > mtb=designated when land managers just signpost for > bicycle=yes,foot=yes,horse=no? > Going by https://wiki.openstreetmap.org/wiki/Key:access#List_of_possible_values designated means "A preferred or designated route for the class of traffic specified by the tag key, such as foot=designated, in general this means that there is a (explicit) sign saying something like "pedestrians allowed", or a pedestrian icon." So if there is signage indicating the track is for use by mountain bikes then mtb=designated seems appropriate. Otherwise if it is allowed it's just =yes but since they probably don't distinguish the type of bicycle better to use bicycle=yes. For mountain bike tracks that aren't really official by the land owner "tolerates" to some degree then bicycle=permissive seems best. Where they actively forbid bicycles then bicycle=no. > > I feel this is better than a new highway=singletrack tag since renderers, >> routers, etc can still interpret the path without making changes. If we >> move to a new tag, these tracks will disappear from routers and maps >> overnight. >> > > Agreed, it wouldn't just disappear from renderers but it breaks the long > time documented scheme. My suggestion was playing devil's advocate because > I am still not sure what we can't do with the current tags. > > All other tags like surface, smoothness, mtb:scale, route=mtb still apply. >> leisure=track would still apply to short loop tracks like a BMX pump track >> or a velodrome, but not to longer A to B tracks. >> >> Thoughts? I can help work on the wiki proposal for these tag changes >> (mtb= as an access tag and path=mtb) but keen to hear feedback here first. >> > > *Summary:* > - When would/could I use the proposed mtb= access tag if land managers > only define bicycle=, and what is a MTB (as mentioned above)? > I would mostly use the bicycle access tag and only use mtb if it's specifically signposted for mountain bikes specifically. > - Your proposed path=mtb would be a specialisation of highway=path (like > service=parking_aisle) which seems odd and against highway=path being a > non-specific path? > I agree, which is why I don't like highway=path + path=mtb since path=mtb contradicts highway=path. highway=path says it's a non-specific path and then path=mtb says it's specifically for mountain bikes. But it's the best compromise for the people who say highway=cycleway (the tag for designated bicycle paths) can't be used for mountain bike paths (which are just a specific type of bicycle path). > Objectively how would I know what is a MTB path, many signposted IMBA > green trails don't have berms and rollovers? > Good question. I would look at how it's generally used, indented to be used by, who built it, who maintains it. > What does this tag provide that just adding mtb:scale=* doesn't already? > I guess it provides a way to say it's a mountain biking track but without knowing or wanting to make a determination of the exact mtb:scale. Also mtb:scale on a highway=track is still a track so it provides some way to say whats a mountain biking track. Some people here have been very vocal that presence of mtb:scale should not be the only way to distinguish a mountain biking track for an urban cycleway, this started back at https://github.com/cyclosm/cyclosm-cartocss-style/issues/208#issuecomment-607100435 . > I think general purpose routers should ignore highway=path if they don't > want to understand path grading, the same can be said for highway=track. > Personally I've only added mtb:scale:imba=* here from signposted trails, > just never thought adding mtb:scale=* was helping anyone so didn't put in > the effort, but could now. > If you know the mtb:scale:imba then that's enough, addition the additional mtb:scale should be optional, any good router and rendering engine should be able to deal with all combinations of mtb:scale:imba and mtb:scale tags. I'll put together a proposal on the wiki so we can start getting something more concrete down and then do a round of feedback then voting.
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
