I think the discussion below Documenting solution proposals for `highway=path` - #116 by supsup
is also relevant. I think this thread is one more reason why we need
pathway=mtb_single_track
Just fitting it in with the existing mapping and tagging.
Enjoy!
1 Like
For sure, and I understand.
I think thereâs actually a pretty good set of tags out there that already work. JOSMâs MTBTagger is in line with this too.
1 Like
This is interesting, and I particularly agree with this: Documenting solution proposals for `highway=path` - #122 by Duja
I donât think pathway= is the way to go. I believe the existing tags solve it. I donât think thereâs need to add something further.
I think adding iD presets to a MTB trail such that it is tagged as a path and bike=yes/designate seems like a good idea, reserving the cycleway tag for cycle paths that are smoother and flatter. I donât think mtb:scale:imba will work because many mtb specific trails are not rated, mappers might not know it, or know how to estimate it.
I think this is a good step towards making distinctions among bike facilities suitable for different cycling styles, but there is definitely a lot more to do.
If the trail is open to mountain bikes itâs often already signed with a difficulty rating. In which case the mapper just needs to reflect that in the tagging, not do an assessment themselves.
We should also encourage mappers to use the designated rating, because trail difficulty tends to vary by region. For example some areas (say, parks) will often designate their easiest trail as green circle (mtb:scale:imba=1) and their hardest as black diamond (mtb:scale:imba=3) even if the hardest trail wouldnât be a black diamond in another part of the country.
If we were to ask mappers to separately assess difficulty weâd end up with both mismatched on-the-ground designations and the weird situation where more hardcore riders will tend to downrate trails, while newer riders may over-rate them. We should instead defer to whatâs already signed.
Iâm agreeing with all of this. Also, mtb:scale:imba seems to be a more US-centric thing, so Iâd prompt (optionally) for mtb:scale and mtb:scale:imba just to prod mappers into choosing one, but not requiring it.
And I definitely agree, lots more to do, but this is a good stopgap/step-along-the-way to improving the tooling whichâll lead to better trail data.
1 Like
I think I would even be ok with adding surface=unpaved as the overwhelming majority of MTB trails are unpaved (There are some asphalt MTB trails in Fayetteville, AR)
And Bentonville⊠Those are weird, but it makes sense with the use those places see. I like the idea of adding that. Here in Michigan itâs a weird mix of sand/clay/dirt and they often get tagged as surface=natural.
I like the idea.
Guess I should figure out how to submit a PR against iDâŠ
(IT / software stuff is my world professionally, trail system development/maintenance and MTBing is a big hobby, and OSM mapping has been a fallout of that. So this all aligns nicely.)
I believe what you actually want is the id-tagging-schema repository:
I think maybe a surface=ground is more widely used in OSM than natural. I used unpaved as it is the absolute least specific tag. Iâve definitely experienced MTB trails that have limited amounts of gravel added.
1 Like
Well, thanks!
Can you list tags the preset would add to such single-use downhill-tracks?
I see them here (Austria) too. When panning the area with the German Map Style they get rendered as a white line with blue casing, regardless of cycleway or bicycle designated path. Everybody grown up here will read that signature as 2+m wide paved, like shown in the bike path picture on top. (mtb:scale will not be considered when rendering.)
I can imagine, highway=path;bicycle=yes;mtb=designated;mtb:scale=2+;etc. That should fix the rendering, but will not keep OSRM from routing there, see for issue â GraphHopper recently started to avoid these downhill races in routes for ordinary bikes. For good reason: Either the bike or the biker will break.
Did I mention, they intersect with the regular traffic network and sometimes provide shorter routes from one suburb to the other (in the city where I live.)
The first thing that the Tag:highway=cycleway - OpenStreetMap Wiki page says:
The highway=cycleway tag indicates a separate way for the use of cyclists.
which fits specially built off-road bike-only tracks in the countryside/forest. Remembering that highway=cycleway and highway=footway pre-date highway=path, and the latter was defined primarily to be a catch-all that could cover footways, cycleways and shared routes, I donât see any reason why off-road cycle routes canât be tagged as highway=cycleway, along with appropriate surface / smoothness tags.
As far as many renderers and data users are concerned, highway=cycleway is treated pretty much the same as highway=path + bicycle=designated anyway, and I donât think you can argue against the latter tagging - itâs a generic path thatâs designed for bicycle use.
Moreover, I think it makes sense for these routes to be rendered differently from other paths. If youâre out in the countryside and are on a bike you want to be able to find such paths that are dedicated to your mode of transport. If youâre not on a bike then you want to avoid those routes. The Carto rendering at https://www.openstreetmap.org/#map=15/52.42333/0.66390 usefully shows the bike-only routes in blue.
3 Likes
I think this is something that would be best solved by a new top-level tag - highway=mtb_trail or similar.
Itâs not really a âcyclewayâ. Partly because of popular perception - if you asked someone to draw a âcyclewayâ they would typically draw a tarmac commuter path or a gravel rail trail - but also because itâs not generically suitable for âcyclesâ, itâs suitable for one small subset of cycles.
It may also have different access expectations. Mountain bike trails are often part of trail centres where thereâs a customer/company relationship. Certainly in the UK, tagging with highway=path, bicycle=yes (or =designated) or whatever is going to be inappropriate, and it would need to be bicycle=customer (or perhaps in the case of Forestry Commission trails, =permissive). Good luck getting that nuance across to a first-time trails editor.
Thereâs an argument that it shouldnât really be under the highway= tag at all - trail centres, at least, are functionally closer to sports facilities than to public highways - but thatâs probably a leap too far.
When Iâve encountered MTB trails tagged as highway=cycleway in the past Iâve just slapped a surface=unpaved on them and moved on - as luck would have it, they donât really impact routing much because theyâre usually closed networks rather than through routes. But thatâs an imperfect solution.
6 Likes
Just to note, that while Trail Centres are a big thing in the UK, thatâs not true for much of the rest of the world. In the US and Canada while âbike parksâ (the equivilent to a Trail Centre) are, we have far far more mountain biking locations that are simply trails (single or double tracked) that are de facto open to bikes, or sometimes designated as such.
These usually tend to be shared with hiking/walking/trail-running uses. And thus I concur that âcyclewayâ really doesnât fit. Since they tend to be natural surface trails that have varying access permissions, âpathâ really does seem the most appropriate.
I donât think the rendering that Carto does making highway=path & bicycle=designated is appropriate because then two wildly different âtrailsâ look the same.
Look here for an example of what CyclOSM does: OpenStreetMap
On the west side of the viewport there is some single track mountain bike trails that is highway=path, bicycle=yes, foot=yes, etc (look at way ID 87055925). This looks good, especially with difficulty designation visually on them. Then to the east of the park road is a highway=cycleway for a combined hike/bike paved path around a lake.
These are vastly different, and while people often ride the same bikes on both, the former matches much of whatâs described on highway=path in the OSM wiki, and the latter very much matches highway=cycleway (or perhaps footway). Rendering the two of these the same would be a mistake.
Then if you go over here: OpenStreetMap
This is another trail system in our area where itâs bicycle=designated, foot=designated, highway=path and itâs still not rendered in the blue of highway=cycleway which is good.
This leads me to the way Carto is doing the rendering is not good for these two distinctly different kinds of non-motorized trails.
Which, gets me back to the following feeling very rational for an âMTBâ trail preset in iD building on the currently-widely-used taggings:
highway=path
bicycle=designated|yes
foot=yes|no|designated
horse=yes|no|designated
name=*
mtb:scale=*
mtb:scale:imba=*
oneway=yes|no|reversable
oneway:foot=-1 (Many trails suggest that those on foot travel opposite bicycle direction.)
segregated=no
surface=*
colour=#xxxxxx
(This is not exhaustive, just off the top of my head while I sip this morningâs coffee. But itâs pretty close.)
And to reply to @Hungerburg, thereâd be no specific preset for âsingle-use downhill-tracksâ, but presuming this is for bicycle-only one-way downhill (which means big chunky rocks and technical features, iâd see that tagged as:
highway=path, bicycle=designated, foot=no, oneway=yes, mtb:scale:imba=4, etc. All built out of the existing tags used on MTB trails. If a tool/renderer is including that for all types of biking, thatâs a tool problem. Same as detailed above, it should not consider it the same as a cycleway.
2 Likes
I could also live with:
highway=path
access=no
mtb=yes|designated
âŠ
i.e. exclude all access, then list the exceptions only if allowed: foot, bicycle, horse.
Ae you seriously expecting user of OSM data that are not specifically into rendering MTB (or cycling) infrastructure to parse all these and try to decide what to draw? I do not see that coming.
There is a widely acknowledged problem of general renderes rendering path as one thing and then users finding themselves where they do not want to be, had they known better. A myriad of tags is never going to solve this problem.
[BTW: these two approaches are not mutually exclusive, all those tags can be added (probably by expert users, this would need an hour of studying the wiki on my side to tag properly) on top of pathway=mtb_single_track or similar. What is really the downside of having bothâ?]
3 Likes
If they ignore the extra tags, then thatâs just fine. These already exist and are widely used; nothing new getting proposed or invented here. And thatâs the beautiful part of using tags: the user of the data doesnât have to use them all, but they are there for systems which do.
Perhaps it was a bit confusing, but what Iâm detailing here is what would be presented in iD when a user picks âMountain Bike Trailâ to give them non-mandatory (but suggested) options for tagging. This would be very much like what the JOSM MTB Tagger preset does:
My goal here is to avoid creating yet another tag, use whatâs already there, and make it more accessible to mappers. pathway=* is pretty much not used (ref: pathway | Keys | OpenStreetMap Taginfo) so adding that in would require a ton of rework on mappersâ part before it becomes usable. (Insert the xkcd yet-another-standard joke hereâŠ)
I could see adding mtb=* to the list as rational, as it does seem to be reasonably used: mtb | Keys | OpenStreetMap Taginfo
Please keep in mind this would not be required tags in iD, but instead a list of predefined suggestions, similar to whatâs done with âCycle Pathâ to give mappers a good place to start:
1 Like