MTB surface looseness tag. Loose sand, swamps and so on

Need a tag to represent surface looseness for mountainbiking or biking in general. I think Surface tag had an already unofficial tag loose_sand but it’s not used much and insufficient to describe the surface. MTB:scale or IMBA ratings aren’t great for this either because it might just be a wide sections of sandy road that at times is very loose. With the difficulty only you don’t really see that it’s not a trail feature difficulty but rather about surface looseness.

Putting as an “mtb” tag but really applies to all kinds of bicycles as useful information.

Example:

mtb:surface_looseness
0 Hard pack ground, tires do not sink.
1 Slightly loose. Tires sink a little but easily rideable.
2 Loose ground. Difficult or impossible to ride for skinny tires.
3 Very loose. Difficult to ride on MTB tires. Tires sink significantly.
4 Extremely loose. Only rideable for fatbikes and even then easier to walk.
5 Watery loose. Can’t be ridden and possibly can’t even be walked upon.

For mudpits surface:persistently_muddy works but it doesn’t indicate the severity of it.

1 Like

There are:

  • tracktype=* to indicate how solid the surface is
  • surface=* to indicate actual surface (e.g. mud or sand are “loose”, or at least I’ve never found ones which weren’t)
  • smoothness=* indicates generally how smooth some part of the track is for certain vehicles.

That is the case for most things. e.g. Some part of the road may be lit for example, and another not. The solution is to split the way into two and mark one section as lit=yes and another as lit=no.

Same principle applies to this – some part of the MTB route might be mtb:scale=0 while other might be mtb:scale=4. One should mark each according to its properties, splitting it where needed.

Yeah, you should combine it with the other tags mentioned above to paint more complete picture. But even if mtb:scale is not only about surface looseness, it does play the role in its determination.

Also note the verifiability issues with suggested mtb:surface_looseness - same terrain might differ in the heat of the summer, in the fall after the rain, or in the snowy winter.

1 Like

None of those address what I’m talking about here. Surface is just the surface type. Like I said there is already what seems to be a fairly unofficial tag loose_sand which also isn’t sufficient because it doesn’t indicate how loose it might be. As I already explained how the surface can differ for an MTB or bicycle. Tracktype and smoothness also are more so for vehicles and are very much insufficient for this purpose. Completely different things to address with vehicles and bicycles. For a car some loose sand might not be note worthy where as for a bicycle it might be near impossible to pedal.

That is not what I was talking about. Nothing to do with splitting into smaller sections for grades. Using the mtb:scale or IMBA gradings is insufficient to address the problem because a trail being a 2 difficulty and loose sand on a road being grade 2 are very different things. The point of having a mtb:surface_looseness is to have an indicator so you understand what the trail is like. Same as surface:persistently_muddy or obstacle:vegetation/fallen_tree. Those are very important tags to have.

trailmap.fi is the main Finnish trail map and persistently_muddy and vegetation/fallen_tree are widely used and provide a lot of value in navigating. Very much the same as I’m suggesting here.

Trailmap - Löydä uusia polkuja example of all 3 showing on the map.

It’s not an issue. It doesn’t matter if the surface changes according to water retention and temperature. People understand that ground looseness changes. By your logic people would be unable to understand that surface:persistently_muddy mudpits dry out completely during summer high heat. Or that you are somehow unable to “verify” a mudpit because in the winter it freezes and in the summer it becomes solid ground. This is a complete non-issue. This is really inventing a problem that doesn’t exist.

None of what you suggested addresses the issue of describing surface looseness for bicycles.

TL;DR: it’s not my intention to force you to do or use something! I just wanted to help, and understanding what exactly you’re trying to accomplish (and in what way exactly are current tags insufficient) is a prerequisite for that. You can always use any tags you like, but unless they’re good ones, others might not. Good luck!


Well, OK, surface is “just a surface”, but it does have some properties (one of which is “looseness”), which is why I gave specific examples of mud and sand (and there are other examples, e.g. fine_gravel is loose one, while compacted gravel is non-loose one, as is surface=asphalt).

How does an a surface=mud which is not “loose” look like? Or an “unloose” (firm? compact?) surface=sand? What is surface=loose_sand and how does it differ from “regular” surface=sand (which looks very “loose” to me)?

Uhhh, I don’t follow. Bicycles are vehicles. vehicle=* tag applies to them.

Maybe you meant bicycle vs. motor_vehicle? But motor_vehicle also applies for e.g. motorcycle and mofa, which share many of bicycle issues. Maybe you meant 4-wheeled motor vehicles only? But even there there is a huge difference between say atv=* and hgv=* – the latter will have even more issues on that sandy beach than mtb=*, while the former might just work fine. Much of that “looseness” is as important (or even much more important!) to other vehicles as it is for MTBs, so it does not have sense to be under mtb: prefix.

Well, I am trying to understand what exactly you are asking about. Do you have picture of that “loose sand on a road being grade 2” so it can be better understood? Picture is worth a thousand words! And what you mean by “grade 2” there? mtb:scale=2? or tracktype=grade2? (And of course those are different!) Or do you mean some sand being blown on the otherwise asphalt road? Or something else entirely?

Is it using OSM data or something else? Because I don’t see “persistently_muddy” as widely used in OSM (there are 0 matches for key persistently_muddy=* and 9 matches for surface=persistently_muddy worldwide. Or did you mean regular surface=mud there? Or something else? Perhaps some non-OSM data?

Uh, I’ve tried, but (not speaking Finish) I can only recognize those icons of fallen trees to probably indicate obstacle=fallen_tree. But no idea about “persistently_muddy”, which is only one related to this thread? Could you be more specific here?

Perhaps I have different understanding of word “persistent”. What you seem to describe would be “temporary” as I understand it. I’d only mark something as surface=mud (i.e. persistent mud) if it is actual “mud” at least 3/4 of the year, preferably more. Otherwise, I wouldn’t map temporary features (and even if I did, it is quite likely other mapper would overwrite that surface=mud with e.g. surface=dirt as that is what it was when they were mapping it)


But anyway, my intention was to try to clarify what you want, by seeing how it differs from combination of existing tags, as I though you posted a thread in order to solicit opinions on your suggestion, in order to produce a better and more widely supported tag.

And not to “force my opinion” as seems that it was understood.

But getting that result will require some work, starting with clearly explaining (ideally by examples with pictures, accompanied by words) how current tagging is insufficient - e.g. something like:

both picture A and picture B here are highway=track + surface=sand + tracktype=grade5 + mtb:scale=2 but A is good (or less technical or whatever) because of reason XXXX, and B isn’t because of YYYY, and I propose to tag A with looseness=XXXX and B with looseness=YYYY to differentiate them

Several such examples, some rounds of back-and-forth, other people adding comments, and it would be a nice proposal with tag useful (and thus being supported in data consumers) by many.

But if you don’t want to engage in such work, sure, you can just start using any tags you like. Far it be from me to try to stop you! But you should been that warned that without the effort to clearly define it before using it, it is quite likely that other people and apps/websites won’t actually use it (or even worse, will use it to mean something different than what you intended).

For info, a couple of discussions that might be relevant are here and here.

If you want to have a go at pioneering using (and rendering) a new scheme locally to you then by all means give it a go.