How to map Key:smoothness

What I do for inline skating routing is to vary the speeds I assign to different smoothness values. I block bad because that tends to not make sense at all. But for intermedia I put in something around 5 km/h. Then excellent is 20 km/h and good something like 15 km/h.

The net effect is that the router will try to find a good route, but will fall back to bad routes if nothing else is available.

Smoothness and surface can be tagged independently. If somebody likes tagging surface then do that, somebody else can tag smoothness.

Uh, I’m not quite sure I agree it would be simpler to map objectively.

For example, even for very simple case of regular surfaces (like the example at the top of this thread), you’d need at the very least:

for surface:

  • width of surface before gap
  • width of the gap
  • depth of the gap
  • viscosity of the surface (e.g. is it loose gravel of fixed stones)

Even if those were objectively specified in detail as documented on the wiki (e.g. surface=paving_stones + paving_stones:shape=rectangle + paving_stones:pattern=half_bond + paving_stones:orientation=across + paving_stones:length=10 cm + paving_stones:width=30 cm, you’d still need to invent/document some new tags (gap width/depth at least) to make such model useful at all.

Why do you seem to think that such more objectively tagged surface would be simpler to parse than just surface+smoothness is beyond me, though. :open_mouth:

Also, for vehicle being routed on such surface objectively, you’d also need:

  • number of tires, their distance and weight distribution
  • width of the tire(s)
  • pressure of the tire(s)
  • suspension spring rate (which depends not only on model but also on weight load)
  • roll rate (not only factor of speed, but also number of wheels, their distribution)

And even all that would give you only very rough “objective” physical model to work it. If you ask me, striving for strict objectivity there in context of OSM would be extremely hard, even for such evenly distributed surfaces. For uneven ones, it would be positively hopeless (you’d have to splice the road to segments of less than 1m in length and micromap each of those. It would be ridiculous)

smoothness=*, on the other hand, is somewhat subjective. Yet, in combination with just surface (and sometimes tracktype) it gives pretty much reasonable approximation to set your expectations - probably not much worse than crunching the physical model simulation above would give you – and it is undoubtedly significantly less work for both the mapper and the final user.

While I have not written a router of my own, I have made few tweaks to Brouter profiles that accomplished what I needed; and even just looking at unadulterated raw smoothness values (e.g. display in OsmAnd) have given me greatly useful information to plan the routes. (mostly trekking & touring & road bicycles, depending of the specific group of cyclists being routed; and for routes that I’m interested in, smoothness+surface combination is among most important factors - topped only by choice of separated cycleways if they exist and motorized road traffic rate if they don’t; and far more interesting than less important factors like total route length, elevation profile; and speed/time plots. YMMV, of course)

5 Likes

Agreed. Having a foot or hand or something for scale would help; as it is it seems to me that this gaps might be about 10-20mm wide? Or maybe those are very small stone blocks. It’s hard to tell without reference.

So I said bad, although it conceivably it might be intermediate if I overestimated gap size / depth, and the gaps are narrower.

Note that this gaps are below level of paving blocks.

I’m not quite sure what you’ve intended to convey here, though?

I was going to write something like this, but in fewer words: we could strive for perfection and develop a very fine grained tagging scheme that would give detailed information for every imaginable surface and vehicle, but that would not work in practice because if would be beyond the abilities of most mappers to accurately evaluate. I think smoothness as it is now is a good compromise between simplicity and accuracy.

3 Likes

that gaps form holes in road surface (road level in gap is notably below road level on block itself - in contrast to some cases where gaps are filled with concrete or similar reducing the smoothness problem)

1 Like

Here’s smoothness=bad (passenger car) on a graded natural or aggregate surface.

Here’s 2 smoothness=very_bad, (high clearance vehicle)

Here’s smoothness=horrible (4wd vehicle)

These roads always look better in photos than they do in person.

3 Likes

The votes for smoothness=intermediate outnumber those for smoothness=bad 2:1 at the moment. Can we conclude that this image should be moved from the bad to the intermediate column at the Gallery?

I suspect that many of the bad voters are cyclists? I agree that this (rather unusual, I think) surface is particularly uncomfortable for cyclists, so maybe if this is the surface of a highway=cycleway, it should be tagged smoothness=bad? Or should a subtag bicycle:smoothness=* be introduced to handle such exceptions?

By posting these images here, I assume you want to put them up for discussion? Maybe it would be better to make a poll so people can vote on them?

I think the first one is smoothness=intermediate: I would slow down on this road because of the curve and the loose gravel, but not because of its smoothness. On an equally rough straight asphalt road, I wouldn’t slow down.

The second one looks like smoothness=horrible to me: the boulder in the second shade looks like it needs more clearance than a typical SUV, and there seems to be no way to drive around it.

I agree that the third one is smoothness=very_bad because of the bedrock showing through the gravel a bit further down, though if I really have to, I might try it with a normal car (i.e. it’s at the good end of very_bad).

I agree that the fourth image is definitely smoothness=horrible

Cyclist here, but one that rides offroad more often.

I voted intermediate since even on a racing bike with properly inflated tires and minimal technical skill you’d be fine riding over the surface.

On any of the smoothness ratings I use essentially two criteria:

  1. If I was using any of the reference vehicles would I move over the surface cleanly or have to slowly pick my way through the surface and potentially lose control without reducing my speed.

  2. Similar to a rock climbing rating I define based on the “crux move” or the most common and important quality for the section of track. A smooth tarmac in the middle of the desert that has some smooth portions and other horrible sections gets a grading of bad or very_bad so someone choosing that track doesn’t get too far out and have to stop and turn around and reroute.

Micromapping every meter would be interesting but tedious and not useful. Using the OP photo, each paver looks very smooth and each gap creates a roughness overall so mapping each brick might indicate a smoother track locally but overall be rough. Using another extreme example, a smooth tarmac track that has a horrible small section on average is smooth but the horrible section that can’t be avoided or traversed is essentially a barrier for the wrong vehicle type. I can walk my bike over a rough patch, I can’t walk my sportscar over a rough patch.

Smoothness should reflect the use case for the referenced vehicle(s) on the type of track. It should also, with the judgement of the mapper, reflect the distance and connected network of the tracks for routing. Once vehicle’s barrier is another’s fun technical section.

I went for bad because it’s visually similar to pictures of bad on the Wiki. Of course in real life I don’t tag smoothness based on eyeballing a photo.

I’m afraid it’s not as simple as that. The picture you have put up for discussion is literally the example picture of bad that StreetComplete shows to its users when deciding how to tag smoothness when the surface is paving_stones. So why don’t you open a ticket in the StreetComplete issue tracker and ask them to use one of the other pictures? Otherwise the Wiki and StreetComplete would directly contradict each other.

In fairness, the StreetComplete quest is disabled by default and the user is warned when enabling it that it’s often hard to make the right choice.

For the gallery, we could try and have pictures that we mostly agree on, instead of edge cases? So I suggest removing this picture instead of moving it to intermediate.

2 Likes

For the gallery, we could try and have pictures that we mostly agree on, instead of edge cases? So I suggest removing this picture instead of moving it to intermediate.

looking at the street complete options I think they are well chosen and make sense in the context of a paving stones surface.

Maybe we should take it as a model and have example pictures for every smoothness value ordered by surface?

4 Likes

:heart: :heart: :heart: I think StreetComplete (and before, this gallery) went the wrong way by stressing visual comparison of the situation on the ground with example photos. I think the way to tag smoothness is to try to imagine using the way with the vehicles mentioned in the wiki. See also here. The explanatory text and the example photos in the wiki were added by me only 3 years ago (with discussion only on the talk page of the wiki, as I hadn’t found this forum yet) to make tagging a bit less subjective and more verifiable. I proposed to move away from visual evaluation in StreetComplete here but it was rejected.

I know, it’s the reason why I picked this photo as the first to discuss because I wanted to be sure it’s not only me who thinks it’s not suitable for illustrating smoothness=bad: at first sight, the surface quality looks as good as the “mostly even” image, and only when looking closely you notice the wide gaps between the bricks. I think it appears about as rough as the “A little bumpy” picture.

I will, as soon as we have consensus here on what should be on the Wiki.

I have in mind that we discuss most of the pictures in the Gallery here, beginning with what seem to be the most controversial ones, and then move a picture if deemed necessary and add a caption with a summary of our discussion and the result of the vote. I think edge cases are especially interesting to show what different mappers are considering when tagging smoothness.

To me the observation above is the primary reason why I tend to agree with @Richard that smoothness (and tracktype) adds little value on top of surface tag for routing profiles (I have also developed several for different cycling modes + foot). Different types of “vehicles” simply suffer in different ways from road / track / path imperfections. Then take into account the difficulty in objective grading and ratio of tagged vs. non-tagged and one will find it quite hard to design a routing profile that would effectively utilise the this tag.

I do agree though that there are specific cases where it would work quite well: e.g. routing only on roads that have a suitable surface tag and a smoothness tag with a “high” value (excellent / good) you would get a route that would be quite smooth (with high probability) for e.g. racing cycle. However, would you rather have that or a shorter route with equal quality (but missing smoothness tags) or nearly as smooth but otherwise maybe better (with e.g. intermediate values for smoothness)? That is the problem that a general purpose routing profile needs to solve. And once you have a service / application out there you start to get feedback from the users about the “routing solutions” which truly opens one’s eyes to the challenge.

I’m currently trying to solve a subset of the topic of this discussion thread: develop appropriate tagging (for Finland) for gravel bikes. As a foundation we have a very active mtb-mapping community (with +24000km of paths mapped & tagged with mtb:scale, I think only Italy is ahead of us in Europe) and we have extensively discussed the challenges of mtb:scale tag - however are reasonable happy with the outcome. We are still debating the approach to tag for gravel biking, that would appropriately describe the surface impact to speed and comfort - and this is just one specific vehicle we are trying to tackle…

From what you write, I understand that the weakness of smoothness is more the low share of highways tagged than an inherent weakness of the tag itself. Surely smoothness tells more about the quality of a road or path surface than surface? A road tagged with surface=asphalt could be newly paved or full of potholes: the surface value doesn’t contain any information about that. Statistic will probably show that surface=asphalt roads are generally better than surface=ground roads, but there are surface=ground roads that are better than surface=asphalt roads, and you can’t tell from the surface value alone if that might be the case. But a road tagged with smoothness=intermediate is quite likely to be better (more comfortable, safer for your vehicle and faster) than a smoothness=bad road, even though there are mappers who would tag the intermediate road with bad, and others who would tag the bad road intermediate if they are edge cases. However, most mappers will be able to agree on a ranking of road qualities from excellent to very horrible, though they might disagree on the borders between the categories (this is what is verifiable about smoothness).
I live and map mostly in Bulgaria, where road quality shows a larger variation than in North/Western Europe and is of crucial importance in choosing a route. This initiative by @ivanatora and @REAKTOR invites the general public to submit road quality data to them, which they then add as smoothness tags to the reported roads. It has been quite successful, and often leads to roads being tagged with smoothness before they are being tagged with surface. I take this as an indication that map users here (i.e. our end customers) are more interested in the quality of the road than in what its surface is.
"Google and Apple maps do not differentiate between a good road and a bad road - but that’s so important". It’s one of the areas in which OSM can really make a difference and offer some advantage over Google Maps

2 Likes

I meant having a picture for every smoothness value as applying to a specific surface combination. Thank you for pointing out in private that there is already such a table: Key:smoothness/Gallery - OpenStreetMap Wiki

1 Like

The weakness is a combination of tagging ratio, mapper consistency and specification of how tag values should be used. I did not mean to say that there is “no value”, just that there is not a whole lot of extra value (to the type of needs I have been exposed to). With your example you raised a very valid point on how local circumstances and main use case impact tagging usefulness. I can understand that 4-wheel vehicles & bad quality roads (even for asphalt) is a type of need that smoothness tag can help with if you manage to mobilise the mapping community.

Local circumstances around here are different: my main interest is bicycles of different sorts, paved roads around here are not perfect, but good enough that even for a narrow tired racing bikes do not need to care unless one is very keen to maximise comfort. However on unpaved roads conditions are very dynamic: due to winter the roads can be in extremely bad shape in spring with deep potholes, terrible for cars, a bit uncomfortable but not a big problem for bikes. And then they do the maintenance for unpaved roads to fix potholes, which fixes it for cars instantly, but is terrible for bikes until the fresh gravel-sand mixture settles, then the road is typically pretty good for everyone. In autumn some unpaved roads get so wet that riding a bike is feeling like riding in a swamp.

1 Like

I think the photos do a good job to set the expectations and help to use similar judgement for similar situations. Rather than just removing the pictures we could replace the 1-2 examples per value as they are currently shown here: https://wiki.openstreetmap.org/wiki/Key:smoothness
with the more exhaustive table of example photos by surface type here: Key:smoothness/Gallery - OpenStreetMap Wiki
because I guess many mappers will rather just look on the provided pictures and not necessarily follow the links from the fine print. If you are interested in information about a tag, and there is a table of values and pictures, the assumption is that this is the current state of the art.

If we find that good smoothness value can be determined for different transport modes, but the different transport modes don’t agree on a single smoothness value, then tag that as smoothness:* = *

Alternatively, if a smoothness value just doesn’t make sense on a particular road due to seasonable variations, just leave it out.

1 Like

Or, assuming it varies predictably with season, wet_season:smoothness=* etc.

Sure, if that’s what you want to do.

That’s fine with me too, it does look like it was recently graded, although one should keep in mind what that road is going to be like in 6 months or a year. Unpaved roads in my part of the world get washboarded in a short time and get very occasional or rare maintenance. Intermediate and bad are both passenger car roads which is the main criteria for an unpaved road. The distinction is subtle, and ‘intermediate’ unpaved roads don’t stay that way for long.

I’ve been there & I disagree. Perhaps it’s not the best example, but iI consider it a high clearance road & is “passable with an average SUV”. I reserve horrible for roads a little worse.