Soft and boggy paths

Help and support Tagging help & support
21

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)

2 Likes
22

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.

3 Likes
23

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.

2 Likes
24

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.

25

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.

26

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.
https://wiki.openstreetmap.org/wiki/Key:class:bicycle

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 mtbmap.no (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:

548×1136 73.4 KB

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

1 Like
27

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
28

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.

29

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
30

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 https://taginfo.openstreetmap.org/keys/class:bicycle#projects ?

2 Likes
31

Thanks, now I’ve suggested this for the main (/only) developer of mtbmap.no.
I suppose it will rather be listed at https://taginfo.openstreetmap.org/keys/class:bicycle:mtb#projects and probably for some other tags like mtb:scale, mtb:scale:uphill and mtb:scale:imba.

1 Like