Soft and boggy paths

I have yet another variant of the essentially same problem of describing surface softness (under certain conditions). Since this discussion thread was pretty much the only one (!) on the topic I was able to find with googling I thought it would be better ask here than start a new thread.

I Finland we have multiple types of highways (unclassified, service, track), in practise typically smaller (forest) roads that are smooth and fast for biking when dry or when ground is frozen (with or without snow). However in spring, autumn and sometimes even summer time after heavy raining they turn so soft that they practically “suck” the tire and rolling resistance becomes enermous.

I have been reviewing various tags but nothing seems to fit. obstacle:mud clearly does not, because this is not a permanent condition and these areas are not swamp / wetland.

1 Like

A similar situation that we do have a tag for is flood_prone=yes. The situation described in this thread is clearly not flooding but it does seem to be about ways that are “prone” to being soft, boggy, or mucky and not necessarily on a predictable seasonal schedule. muck_prone sounds rather awkward, but perhaps someone has a better idea for a key name that would carry this meaning.

1 Like

Happened to be using this tag recently, for exactness flood_prone=yes with 35K uses per TagInfo.

1 Like

I’m reminded of tracks and paths in the Biebrzański National Park in Poland during the Spring.

With the GPX traces layer on you can see how far I ventured along the track before the overall dampness became too much (didn’t help that the soles of my Goretex boots had just come asunder). My guidebook was pretty firm that one could encounter a lot of water, thigh-deep on this track in the Spring. Obviously the park has large tracts of marshy ground anyway, but the example shown was soft and slightly damp, not wet at the time.

1 Like

The most popular walking website in Scotland, uses the following classification scheme, for the “bog factor” of a path.

| 1 | Walk is usually completely dry underfoot. |
| 2 | The route may be slightly boggy in places. |
| 3 | Much of the walk may be dry, but there are sections which can be very wet. Waterproof boots recommended. |
| 4 | Underfoot conditions are likely to be very wet in parts all year round. |
| 5 | It’s a swamp. Snorkel recommended. |

This is orthogonal to the “grade” of a path which roughly corresponds to our sac_scale and trail_visibility.

We could adapt this, though we’ll probably need something less tongue in cheek than bog_factor=snorkel_recommended. We could ask the creators of Walkhighlands, I hope they wouldn’t mind. We would need to make some changes anyway, as it’s meant for long walks.

The scheme refers to something between average and worst case conditions. Common sense is advised, “can be very wet” refers to periods after heavy rainfall, etc.

It basically answers the question if you need boots, maybe even gaiters, to avoid getting your feet wet.

There is some correlation with surface: all forms of paved probably imply a value of 1, in Scotland surface=earth/dirt/ground tends to imply 2 or higher, and surface=mud probably corresponds to a 4 or 5. But as others have pointed out, this would also be useful for grass, sand and others.


highway=track + tracktype=grade5 + surface=ground ?

That tracktype=grade5 indicates it is soft (meaning, when the rains come, it will also quite likely turn to mud - and surface=ground is unspecific enough to cover both dirt and mud and grass depending on the season)

1 Like

I’m considering writing a proposal that includes deprecation of tracktype and including its grades values into the surface key so that a very soft surface can be tagged with surface=grade5 This could solve this issue too. Just need some time to write down the proposal…

Deprecating a feature is anything but “just need some time”. :joy: It’s like saying that humans “just need some time” to terraform Mars. Technically true, but highly misleading. :smiling_face:

See part about deprecation in “Due Dilligence” section of Proposal process as well as “Everything is more complicated than expected” section of deprecated features to get a sense about enormity of the task (writing proposal itself is literally laughably small percentage of work that needs to be done to successfully deprecate a feature without casing major issues).

Also note that there is a huge difference between for example surface=grass + tracktype=grade5 and surface=mud + tracktype=grade5, so it would not be a good idea anyway.

Here, I’ve just saved you some time; can use it to go grab some :beers: instead!


I have understood tracktype (esp. 4 & 5) to indicate the surface of the track. However how wet and soft the track becomes when it rains depends also / a lot on the underlying layers (do they let through quickly or block the water). Thus using this combo of tags is probably the best alternative right now, but I’m not sure how uniform the existing tagging is and would it properly indicate track softness when raining.

Hm, surface itself is indicated by surface=* tag (and its roughness by related smoothness=* tag).

tracktype=* “is a measure of how well-maintained a track or other road is, particularly regarding surface firmness”. It is often (but not always) the result (see the description of values in that wiki, especially for softer values) of how much hard materials are mixed in / compacted with the soil.

Firmness of some types of surfaces (like surface=dirt) are more affected by rain than others (like surface=compacted). Also, if you have two “unimproved ground” tracks with same tracktype=grade5, one with surface=grass will likely be less affected by rain than one with surface=dirt.

However how wet and soft the track becomes when it rains depends also / a lot on the underlying layers (do they let through quickly or block the water).

It would also depend on amount of water received, not only in that day, but in prior days too, i.e. how saturated the soil is with water. Some types will let smaller amount of water just pass through without much effect, but bigger amounts of rain would cause more problems.

Thus using this combo of tags is probably the best alternative right now, but I’m not sure how uniform the existing tagging is and would it properly indicate track softness when raining.

Yes, it is a combination of all three tags linked above, which usually gives a pretty good estimation what one might expect in different weather conditions (snow, rain, dry season), and how appropriate it would be for their type of transport (foot, bicycle, sport car, SUV, pickup truck …)

But while very good, it is still not perfect (can anything ever be, though?), and some situations (like ground which very easily and often turns into deep mud) are harder to represent using existing tags, and might need extra effort (flood_prone=yes, or even seasonal=*) or accepting some inaccuracies (surface=mud + smoothness=very_horrible if it is very muddy and hard to pass very often but not always, and in smaller part of the year it is actually surface=dirt+smoothness=bad - note=* might by added to explain the situation)


Just had a case when someone added bicycle=no to such path.

Existing tags don’t cover it. Surface can very easily be grass and small bushes, but as soon as you take a step, it’ll go underwater along with your foot.

So far I like the idea by @osmuser63783 to use a separate tag like a bog_factor. Maybe even allow adding seasonal information like bog_factor:spring=something. At least a new tag won’t require you to guess anything.


That is not ideal, unless there is a legal restriction to use bicycle there. bicycle:physical=no would’ve been more correct, but it has its own set for issues (e.g. is it unpassable only for my road racing bike, or for 29" MTB too?).

If you can’t pass over it with any vehicle in any case, I’d just add smoothness=impassable. If it varies with seasons, there is seasonal=* as well as *:conditional. And you can always add the freeform description=* explaining the situation.

I’m also suspicious whether such might be better mapped with lifecycle prefix like disused:highway=path or abandoned:highway=path to give a clearer expectations to potential users.

I’d still tag it as surface=mud if it is mud covered by plants. If it behaves like a mud, it is mud enough for me. One can tag area around as natural=wetland or landcover=grass etc. if one wishes to indicate what is on top of that mud.

Sure, ATYL. I however forsee significant issues with verifiability there, so such idea would benefit greatly from more extensive proposal process.


Didn’t know about this tag. Thanks!

And you can always add the freeform description=* explaining the situation.

We can put all of the tags into description, but then no automatic processing could be done unless we want OSM clients to use neural networks to parse the data.

One can tag area around as natural=wetland or landcover=grass etc. if one wishes to indicate what is on top of that mud.

The path itself may have different properties than surrounding land. To make an extreme example you wouldn’t expect a trunk road drawn over wetland to be underwater or in mud.

I’d still tag it as surface=mud if it is mud covered by plants.

The problem with that is there is mud which just makes your shoes/bike dirty and there is mud in which you sink and get wet.

I however forsee significant issues with verifiability there

That is true, but I still think it’s better than nothing and it would give at least some idea. Some common sense and ability to discuss and come to agreement is often required for other things anyway. If bogginess changes too much, you could put the most boggy value under the more wet season and less boggy under less wet season.

It’s quite likely that the common substrate is peat rather than mud, and one could potentially use that as a surface tag covering this type of situation (difference being that peat is made of organic matter, mud is an inorganic slurry of siliceous particles): i.e., the surface properties will vary according to hydration level. The disadvantage of relying on underlying landcover features is that lots of data consumers will not use them.

I realize this thread isn’t new, but anyway… :wink:

As your motivation is to indicate the suitability for cycling, I am surprised not to see any mention of class:bicycle and class:bicycle:mtb in this entire thread.

Particularly class:bicycle:mtb is widely used on the trails nearby my town and it is also used for rendering in cycling specific maps like (covering only Norway). In that map example, positive values gives a “yellow highlight” of the trail, while negative values will lower the opacity of the trail. As shown also in the legend:

This tag can of course be combined with the surface tag.

1 Like

I find them far too subjective tbh. class:bicycle in particular presumes that all cyclists have the same tastes, which isn’t the case - if you look at the Strava heatmap then thousands of cyclists use the Euston Road in London, for example, but it’s crazily busy with cars, has very little cycle infrastructure, and you’d never get me riding along there.

If you do have an arbitrary scale then the IMBA scale is a good example of how to do it. Some of it (e.g. surface material) should be tagged individually in any case, but the more granular obstacles for each class are clearly and objectively qualified. That’s only suitable for actual mountain bike trails but it could in theory be extended more widely.

1 Like

Yes, it’s a subjective tag, but I definitely find class:bicycle:mtb to be very useful for presenting where to find the best and worst bike trails of an area. It obviously needs to be combined with the other useful tags like mtb:scale or mtb:scale:imba (depending on the type of trail). It will never contain any “truth”/verifiable number, but whenever it differs from 0 it will be a sign of what to expect.

I live in an area with lots of bogs, and some trails through these bogs are perfectly suitable for cycling, while other trails will either get destroyed by cycling or will require everyone to carry the bike across (unless it’s been below the freezing point for a while). The surface and mtb:scale tags are not able to provide such info, while class:bicycle:mtb is.

Regarding the more general class:bicycle tag, I do not really have experience with it. For roads (whether paved or unpaved) outside the cities I think the surface tag will tell enough, while inside a city maybe that tag can be useful.

As I live in one of Norway’s most boggy municipalities, this sort of tagging is very much missed.

I suppose I can do some “test mapping” for some 6-12 months in a geographically restricted area, document with some pictures and write up a wiki page for the criteria that turn out to be useful.

If an actual tagging scheme goes through in the meantime, it should be fairly easy to remap whatever ATYL tag I use to the agreed upon scale afterwards (I think I will go for something like bog_factor, and copy the values from smoothness).

1 Like

Sure, that is why there are documented all those other subclasses; take a look at Key:class:bicycle#Subclasses

Perhaps you could convince them to add tags they use to Taginfo Projects so they’ll be listed at ?


Thanks, now I’ve suggested this for the main (/only) developer of
I suppose it will rather be listed at and probably for some other tags like mtb:scale, mtb:scale:uphill and mtb:scale:imba.

1 Like