21

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

22

Just fitting it in with the existing mapping and tagging.
Enjoy!

1 Like
23

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
24

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.

25

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.

26

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.

27

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
28

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)

29

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.)

30

I believe what you actually want is the id-tagging-schema repository:

31

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
32

Well, thanks!

33

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.)

34

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
35

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
36

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
37

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.

38

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
39

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:

image
image1816×1212 210 KB

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
)

40

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:

image
image798×2496 88.1 KB

1 Like