Proposal talk:MTB Trail Features

Tag key options

Should the tag be mtb:feature:jump/berm/etc=*, or would mtb:jump/berm/etc=* or mtb_feature:jump/berm/etc=* (with _ instead of :) make more sense? --pkoby (talk) 15:56, 27 June 2026 (UTC)

My preference is the colons, like you have it now. Heretofore (talk) 19:29, 3 July 2026 (UTC)

'Drop' vs. 'Drop-off'

What is the consensus on the name of these features? --pkoby (talk) 15:57, 27 June 2026 (UTC)

Bypass = separate

What do people think about adding an additional option for explicitly tagging that the way to bypass is another Way? Roads have that option for tagging sidewalks, and steps have it for tagging ramps. Heretofore (talk) 19:33, 3 July 2026 (UTC)

Ha oh wow, I had a double take here. pkoby and I discussed this exact tag out of band earlier this week. My analogy was Tag:cycleway=separate and we both agreed this was something we should consider. It sounds like you agree! Arichnad (talk) 02:50, 4 July 2026 (UTC)

Yep, I'm adding it to the proposal. I think it should be discouraged to map bypasses, though. Agreed?

Also, I think there's value in splitting bypass tags to be specific to each feature. Changing that as well. Let me know if it makes sense. pkoby (talk) 20:19, 4 July 2026 (UTC)

Feature sequences

On the big table of features, the bottom ATYL says to try to fit things into the categories if you can. Is a shark fin a *:wall_ride way that ends in a *:drop node? or is the whole thing a *:jump and you rely on the curvature of the way to communicate it to the consumer?

Relatedly, if features are a sequence without gaps in their node-to-way, way-to-way, or way-to-node connection, what does *:bypass mean on the subsequent features? Is it no if the first feature forces you into the sequence? Or is it only no if there wasn't a way to bypass the first feature? Heretofore (talk) 20:11, 3 July 2026 (UTC)

First off, a shark fin could be a mtb:feature:shark_fin=* as far as I'm concerned. I can add it to the list. I'm not too up and up on MTB feature variety, so if there's anything obvious I'm not including, let me know.

To your second point, I don't know how to take that into consideration. Let's say it's a wall ride to a drop. If you could bypass the wall ride, you'd probably not be able to take the jump. If you take the wall ride, you might be able to bypass the jump at the end. This might be a case of something that's too uncommon to figure out a solution for. If it's no on the second feature, I'd consider it not bypassable at all, even if the first feature is.

Do you have a suggestion for how to solve this? pkoby (talk) 22:13, 4 July 2026 (UTC)

I don't have great suggestions. The best I have is a special value of =previous or =next to chain things together along the direction of a way. It breaks down if there's space between chained features and if the way directions don't line up (which could happen naturally with a junction at a bidirectional feature, if unlikely).

I can start another topic to consider other feature types. Heretofore (talk) 15:20, 5 July 2026 (UTC)

Tags that duplicate normal OSM data

Particularly for the purposes of a shared-use trail (but also loosely relevant for MTB-only trails): Do you want to recommend mtb:feature:*:surface all the time, or only when it differs from the base surface? Similarly for width etc. Heretofore (talk) 12:32, 4 July 2026 (UTC)

I would say the mtb:feature:*:surface=* is valuable for nodes, but if it's a way with highway=*, then surface=* makes more sense. If the surface of the feature (or width) differs from the path, then the specific tag makes sense. I'll clarify that in the text. pkoby (talk) 20:22, 4 July 2026 (UTC)

Drop height

The proposal specifically mentions that drops can be rollable. Is a rollable drop :height=0? Or is it the height you could drop if you were going faster? I can see arguments both ways, but 0 might be best. Heretofore (talk) 12:53, 4 July 2026 (UTC)

Maybe this is a misunderstanding on my part. An artificially-made drop is like in the photo

, where you definitely can't roll down anything. I was thinking a natural drop could be a near-vertical rock face that could be rolled down (unless this is something else, perhaps a "rolldown"?). pkoby (talk) 22:19, 4 July 2026 (UTC)

I was going off the "Description" column where you wrote "A jump from a high level to a lower level. May be possible to roll down the surface." (emphasis mine)

I don't have any issue with considering drops as only when there's real discontinuity in trail height. I'm just trying to understand. Heretofore (talk) 15:24, 5 July 2026 (UTC)

No I think a rollable drop is not height=0. I believe the height is the literal Key:height: measured vertically from the top to the bottom. Ignoring the landing and ignoring any added "safety/beginner" ramps (so, usually, this is the lip straight down to the ground? How far you would fall if you went off too slowly? Maybe?). Ignoring the landing is probably controversial, I think. I've been using a tape measure on a lot of drops, and ignoring the landing means that some drops seem much taller/shorter than they actually are as someone "doing" the jump. But, also I'm typically doing pretty small drops (less than 3 feet) so my experience is very limited. Arichnad (talk) 14:51, 6 July 2026 (UTC)

I agree to all of this. See my comment in Additional_feature_types about *:rock_face too.

Additional feature types

Discuss additional feature types Heretofore (talk) 15:36, 5 July 2026 (UTC)

Launchpad / drop-in / platform

I don't know what terminology suits this best. A raised area, usually at the beginning of a trail, to gain speed. May have a loitering area for additional riders waiting to drop in. (*:capacity=*?) Heretofore (talk) 15:40, 5 July 2026 (UTC)

Roller

Is it too noisy to add generic rollers? Or are they *:jump if they feel substantial and otherwise left out? I can upload a pictures if I can figure out how. Heretofore (talk) 15:46, 5 July 2026 (UTC)

Great idea. *:drop-in might be a bit confusing with *:drop, though, so platform, maybe? But "drop-in" sounds best to me…

Rollers might be too generic if they're just dirt lumps. Roller coaster might be a thing (see https://www.trailforks.com/ttfs/). pkoby (talk) 15:11, 6 July 2026 (UTC)

I also like *:drop-in, but I concur on it possibly being confusing. Also, maybe it's just nomenclature local to the U.S. I suddenly realize we're three east coasters picking names for everyone. Heretofore (talk) 17:35, 7 July 2026 (UTC)

This is so true, and something we should address. What's more, we're all east coasters that don't even really have big stuff near us. To find the bigger stuff I could, but don't, go to Bryce, Massanutten, Roanoke, etc. And by west coast standards even those are small. pkoby I think it's time we post to osmus #bicycle? (thanks in advance!) Arichnad (talk) 18:02, 7 July 2026 (UTC)

Yes please add a picture or slack/signal it to me if you can't figure out the upload process or don't have permission to use it. The rollers near me (are you near Wakefield?) probably should be mapped as jump. Anything that is big enough to jump, but you don't have to jump, I think is a jump. I assume a pump track is not addressed by this proposal, because it's mostly not an mtb:feature thing. Arichnad (talk) 19:31, 6 July 2026 (UTC)

Montgomery County is working on a Bike Skills Track with hefty wooden rollers (see link). Wheaton Regional Park used to have something similar, although the back side was dirt. I encourage a distinction between features that force a jump and features that allow a jump. I suspect that unifying them would intimidate new people away from the sport. Sources at Carroll Knowles park renovation. That park also has a BMX-style pump track design whose wall rides you could tag with this proposal. Heretofore (talk) 15:40, 7 July 2026 (UTC)

I'm going to propose *:rock_face (per https://www.trailforks.com/ttfs/). This might help differentiate from *:drop. pkoby (talk) 15:07, 6 July 2026 (UTC)

mtb:feature:bypass or mtb:feature:*:bypass?

I started out thinking you'd add a bypass around feature(s) as a separate entity, e.g. mtb:feature:bypass=*, with values indicating where the bypasses fit between things. However, Arichnad tagged some points with mtb:feature:*:bypass=*, where * would be each feature (jump, wall_ride, etc.). This allows specific tagging about where a bypass is per each feature, but would mean slightly more tags if there are multiple features on a point. I've written the proposal with the second method for now. Does this make more sense? pkoby (talk) 15:19, 6 July 2026 (UTC)

I am totally fine with either way. Heretofore, which makes more sense to you? I did switch everything over to mtb:feature:bypass after our discussion. But, I can switch it back if we come to a consensus. [out:json][timeout:25];nw[~"^mtb:feature:.*:bypass"~"^"]({{bbox}});out geom; currently returns nothing. taginfo for mtb:feature:drop:bypass is empty. Arichnad (talk) 14:15, 7 July 2026 (UTC)

We could also recommend mtb:feature:bypass=* for most instances, and use mtb:feature:*:bypass=* for more granularity if there are multiple features. Values would only be left, right, or left;right (or both?). In practice, the granular tagging is annoying, so best to avoid it if possible.

I was just mapping new features while you wrote this, so try your overpass query around Philly now. pkoby (talk) 14:48, 7 July 2026 (UTC)

I don't have strong feelings, sorry. There are too many trade-offs each way.

• Discoverability is best with mtb:feature:bypass directly, but I can conceive of situations where it is insufficient.
• Including the feature each time can handle the most situations, but it is somewhat more tedious to map and to look up.
• Allowing the former and falling back to the latter where needed covers both situations, but it requires more conditional nonsense for consumers.

Heretofore (talk) 15:08, 7 July 2026 (UTC)

Hello, I reverted a few of my bypass changes to conform to the current version of the wiki. I'll be slowly emptying out my other additions to `mtb:feature:bypass`. Thanks! Arichnad (talk) 19:32, 21 July 2026 (UTC)