[Tagging] Can highway=cycleway be limited to MTB?

Mon Apr 6 16:13:11 UTC 2020

For the record (though I understand that English track meaning doesn't fit
well)
leisure=track can be used with highway=*, 5% of them

highway=path wiki page says :
«This includes walking and hiking trails, bike trails and paths, horse and
stock trails, mountain bike trails as well as combinations of the above.
[...]
Intended uses can be indicated with the various access keys; e.g.,
bicycle=designated and foot=designated.»
So I understand that for mtb trail path should be preferred.

IMBA have a book of how to make a good mtb trail, enjoy :)
https://www.imba.com/sites/default/files/GQTE_Digital_Book_Rev_6.11.18_high_res.pdf

I can understand from videos that features can be : jump, wood bridges,
high U turn, skinny board path, high stone, etc (those features could be
map)

mtb trail can be wider than a path, like track, so the tag to say that a
way is designed for mtb should be able to be used on any highway (hence
path=mtb is may be not the good one).

So to sum up my current position is :
If a path is signed to be usable by mtb we can tag mtb=designated
If a path can only be used by mtb I think access=no mtb=designated can be
used
(I understand that goes against path multi usage definition, but why access
tags exist if we cannot use it ?)

So the last thing we need is : how to tag a path made with mtb features
- tag every feature, keys need to be created (may be not this time :)
- tag the way with one key like path=mtb, but as said this is not great for
track
may be we can use trail=mtb ?

I don't know if other kind of trail (horse, hiking) can have also specific
features for their enjoyment.
(It seems : log, river, steps, climbing, rope...)

Le lun. 6 avr. 2020 à 08:52, Andrew Harvey <andrew.harvey4 at gmail.com> a
écrit :

> On Mon, 6 Apr 2020 at 03:27, Adam Franco <adamfranco at 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 <voschix at 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 <jono at jonorossi.com> wrote:
>
>> On Sun, Apr 5, 2020 at 5:49 PM Andrew Harvey <andrew.harvey4 at 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

-- 
Florimond Berthoux
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20200406/868c161b/attachment-0001.htm>