How is the smoothness tag defined?

General talk Tagging general discussion
1

A good point was raised on the smoothness talk page by @sly about the definition of the smoothness tag. The tag obviously has something to do with surface roughness and usability by wheeled vehicles, but which comes first?

  1. smoothness is first of all a tag that describes the usability of a way for wheeled vehicles, with the roughness of the surface the most important but not the only factor to be taken into account, or
  2. smoothness is first of all a tag that describes the roughness of a surface, and can be used as a consequence to estimate the usability of a way for wheeled vehicles (but there may be other factors that limit the usability of a way).

The difference between the two definitions becomes important when there are other factors than surface roughness that limit the usability of a way. The example that was until recently in the wiki text was about steepness: some ways may be too steep to be usable for certain vehicles. Other examples of limits of usability I mentioned on the talk page are a deep ford, a log across the way or the way being overgrown. These may be passable only for certain vehicles but not others.

I prefer the second definition for practical reasons of objectivity and verifiability. Imagine a smooth road that is too steep to cycle on with a city bike without gears, but can be used by a racing bike with gears. How would you tag that? smoothness=good because a racing bike can use it, or smoothness=bad because it can’t be used by a city bike? What if Superman comes along and proves that he can cycle it with a city bike? Anyway, that it can’t be used with a city bike is not because there is a risk of damage or injury, but because of the limits of muscle power and gear ratio availability that is different for different persons and different bikes of the same general type. It would be more practical to describe this kind of usability with the incline tag instead.

Poll (hopefully better): Tracktype never dies!
2

Use incline to denote that. Don’t mix apples and oranges.

10 Likes
3

You mentioned incline for the steepness already. For the other limitations there are also dedicated tag like obstacle=fallen_tree, obstacle=vegetation and ford=yes.

6 Likes
4

In reality, of course, routers generally use a Digital Elevation Model to determine steepness, not OSM tags.

That said, the incline tag can occasionally be useful to override the DEM!

4 Likes
5

Don’t tag for the router ;-). BTW, here the added information is correct, no reason to remove it. Tagged for the router but in the good sense. But do routers use this information in practice, as incline= may also be less accurate than DEM?

6

I can only speak for cycle.travel, but it does indeed parse incline=0% (no other values) to indicate a level section.

1 Like
7

An opinion in favour of option 1 (copy-paste from the smoothness talk page)

I understand your point, and disagree. “particularly regarding surface regularity/flatness” was not part of the historical definition of this key, it was added later. And that key was used for a long time without this definition. Adding it later on only calls for confusion. The 2008 sentence that was the whole point of this tag was : “the smoothness of a way should be assessed solely based on whether the way is usable by the vehicles mentioned above. This is my whole point: as a user of a certain road or path I am only interested whether I can drive on this road or not.”

It was meant since the beginning to me a mixing tag because tacktype/surface/track/incline was not giving a simple answer to the Ultimate Question of Life, the Universe, and Everything :“what vehicle do I need to drive this road ?”

I know some people would like this tag to be something else and try to redefine it toward it’s surface smoothness, but it wasn’t meant to be. An asphalt vertical wall no matter what is still smoothness=impassable . And if those people really wants a tag for surface of way, then the surface tag or a new one if they dare should be used, not slowly redfining this one. sly (talk) 09:27, 4 February 2026 (UTC)

8

The quote used there seems a bit selective, as the next sentence is

“If I sit on a racing bike, I am not interested whether the surface of a way is cobblestone or mud, just whether it is smooth enough to be used with a racing bike or not.”

So the original proposer chose to call the key ‘“smoothness” and said it was about whether a way is smooth enough for specific forms of transport. That seems to suggest the opposite to what the person you are quoting is implying?

2 Likes
9

#2 The word “usability” is very broad and may involve a lot of different things. smoothness is often combined with surface (composition), sometimes with tracktype (firmness), occasionally with physical characteristics like incline, width, lanes, hazard, seasonal, maxspeed:practical, or the presence of features like ford or traffic_calming along the way. In a sense, some restrictions can also be thought of as affecting usability.

1 Like
10

I get the impression from this thread that first of all not many are interested in this matter of definition, and that those that do tend to prefer the second definition. Anyway, I think it would be good to add this text to the wiki (for instance at the end of the intro):

There are other reasons than surface regularity/flatness that can cause a way not to be usable for certain vehicles. These ways may still be tagged with smoothness, but it is preferable to map the specific reason why a way is difficult to use. If a way is too steep to pass for certain vehicles, add incline=*. If a way has a deep ford that is only usable for cars with a snorkel (usually only available on heavy-duty off road vehicles), then tag the ford with ford=yes + depth=*. If a way can’t be used because there’s a log lying across, add barrier=log. If the way is overgrown, add obstacle=vegetation, etc.

This leaves the possibility open for those preferring the first definition to tag the usability of ways with smoothness even though it’s not the roughness that’s limiting it, but calls for all mappers to map the actual reason.

11

IMHO, that is way too much prose, and more suitable for blog, some HOWTO text, video tutorial, or introductory OSM course.

There are much too many related factors that influence how one should best “travel from point A to point B with vehicle C” for it to make any sense to write such prose on each of the tags wiki pages.

Adding such prose would make wiki pages much less usable by making them needlessly bigger and harder to read, and there would always be things left out, and maintenance would be a nightmare as you’d have to review all of them on any new tag.

Instead, traditionally we use “See also” section in the wiki to add related keys/tags as bulletpoints with very short description of each (or seeAlso= / combination= in that key description box for even shorter links to related tags) to indicate related resources that people interested in the the tag whose wiki page they’re looking at might also want to consider.

3 Likes
12

The smoothness tag has a poor definition, bad values, and arguably (well, that depend on what that tag was meant to express) a bad name.

It now is 18 years old, and I believe it was created out of the frustration that all physical properties of a ways was not considered enough to easily answer the question “what vehicle is needed to drive along a way”
But back then, we were not precise enough to make a bullet proof, law grade definition.

There is a high probability that this tag is used varying from place to place, and, as it has been express I don’t remember where, differently depending on the values (from smoothness = excellent to intermediate it might be more about comfort, therefore steepness along the way is not considered)

while on the difficult part of the scale (very_bad to very_horrible) maybe, or, at least that is the way I tag it. People might consider the “Trafficability” “without damage” using any possible physical properties of the way. (Obstables, holes, rocks, river, steepness, vegetation, sand, mud, firmness) to merge them into a single, accepted as unprecise tag, to anwser the way “Trafficability”.

That is a good point. My guess is that Chrischan (who wrote this sentence in the first version of the proposal) was a cyclist interested in asphalted roads and had fewer concern for steepness or obstacles.
But in the history of the key:smoothness page (that sentence about “smooth enough for a bike” never made it.)
The current sentence was added with this commit : Key:smoothness: Difference between revisions - OpenStreetMap Wiki

(by me)

I can’t remember why and what made me remove the “smooth enough for a bike” but it has never been re-introduce since then and no one questioned it until recently. I don’t mean that we should not question it, and yes, that is a really valid question and respectable will for clarification.
But doesn’t that risk redefining what a part of the community has been tagging for that long ?
Should we just express in the wiki page that the smoothness is not clear about this aspect and that we live with that doubt ?

My main usage for this tag is for physical “Trafficability” by vehicles of a track whatever the cause for being unable to.
Of course, the much common causes for non-“Trafficability” are the presence of high stones risking damaging the undercarriage or deep holes or mud not firm enough to have “grip” on the road.
But loose rocks or sand together with steep slope or sharp turns might also be a reason to avoid this road with my average car.

I believe we should think in terms of usage of the information, it has to be practical for more person to use it, and if more details have use case, add more properties.

The introduction of Key:smoothness - OpenStreetMap Wiki has : “The aim of this tag should be that navigation software developers can use its information to propose an optimal route depending on the vehicle the user is using”
If we accept that smoothness=bad means : “this road is usable with an average car“, then we expect that a routing software will route you throught this road if you checked “I have an average car”, but if you meet a smooth but too steep road that need low gear ratio, will that fail the purpose ?
(I’m leaving the DEM joke aside)
We could hope that every track out there will have a incline=* tagged, and by some magical heuristic compute a f(turn angle,incline,smoothness,firmness,tracktype,ford_depth) but not only is the data far from having all those details, but I even doubt this heuristic will do.

For sake of transparency : I’m one of the few map maker trying to make use of the smoothness tag : OpenHikingMap - OpenStreetMap Wiki
Map legend : OpenHikingMap Map Legend

2 Likes
13

I agree with such explanatory text about the current situation and possible varying usage.

However, I also find the introduction already quite long for a newcomer willing to understand roughly what this tag about. But having one or more sections down the page with :
== Possible discrepancy in usage ==

== Aims of this tag for route planning ==

== Current known usage by tools or maps + their interpretation of this tag ==

== (Highly) recommended tags to further improve physical description of ways ==

In other words, try not to be prescriptive but descriptive of different known interpretation (like the wikipedia’s controversy chapter).

2 Likes
14

From a mapping perspective in Thailand and similar developing countries, I’d like to offer some practical context.

In Thailand, that question is often exactly what matters in practice: can a standard city car get through, or does it require a high-clearance pickup truck (the dominant vehicle type here in rural/mountainous areas)? smoothness=very_bad maps almost perfectly onto that distinction, making it arguably the single most useful tag on rural and residential links, more actionable than surface or tracktype alone. Outdoor enthusiasts rely on apps like GaiaGPS, which renders smoothness=very_bad and above as a distinct track style, and OsmAnd which applies it more fully in both rendering and routing.

Routing support reinforces this further. OsmAnd’s routing.xml applies smoothness directly as a priority multiplier (bad → 0.8, horrible → 0.2, impassable → blocked). BRouter weights it explicitly in configurable profiles. OSRM, GraphHopper and Valhalla support it via custom costing profiles. For outdoor users in low-infrastructure regions, the data is already being consumed as a usability signal.

On mapper interpretation: in regions with low mapper density, a single holistic usability judgment ages better than a precise surface-texture assessment that nobody will update between seasons. As sly notes:

This is part of a broader pattern. tracktype faces the same tension, officially defined around surface firmness, yet in practice many mappers in developing countries use it as a general usability signal across multiple dimensions. If tracktype=grade3 were widely understood and routed as “requires high clearance,” many of us would use it instead. But it isn’t, so smoothness fills that gap. Restricting smoothness to surface regularity would leave a real and currently well-supported usability signal without a home.

Rather than narrowing the definition, the higher-leverage fix is improving editor presets, placing smoothness alongside surface and tracktype, with plain-language descriptions anchored to vehicle type. That would improve both adoption and consistency without redefining the tag.

3 Likes
15

I tried to summarise the text I proposed in one sentence, and added it under “See also”. I also moved the texts on tracktype and surface there (where they were duplicated). Hope that’s satisfactory?

16

I tried to do something about that by adding more description to the table in 2020/2021. Do you still think so after that addition? What could be done about it, considering that there are also complaints that the text of the wiki is getting too long and there’s too much documentation to read through before you can start mapping the tag?

17

I was referring to the original intention of the tag, not the current state of the page. It’s goal to answer “what vehicle do I need” was a good one, but it wasn’t clear on what was implied by “usage of the road” like, does driving at 1km/h to save your car from damage, can this still be consider “usable” ?

Your (and other’s) attempt at improving the page is a noble cause, and yes, most modifications are welcome because they expand on examples and pictures.

But imho it has a drawback : It cannot be done without redefining the key. And the new key’s definition will not represent all of 6M usage allready in the database.

But since I don’t have a time travel machine to re-define the original key with raised concerns about expected speed of travel or what is “significant” in terms of risk of damage or injury.

I’m wondering if we should accept it like this, with all it’s defects, and focus on new defined improvement tags.

1 Like
18

That is not what smoothness tag is really about, though. What you seems to want is addressed by class:bicycle:*=* for bicycles – but it turned out not to be liked by many (for being too subjective), so alternatives like class:motorcar:sports_car=* never sprung up (to the best of my knowledge). mtb:scale=* however fared better for that specific (MTB) part of the “usability by bicycle” spectrum.

If we accept that smoothness=bad means : “this road is usable with an average car“,

We should not accept that, as it is not what is says. At most, it says exactly the opposite, i.e. “this road is likely not usable for vehicles x,y,z”. But it is only one of the several factors determining if you could ride certain vehicle there, so even with smoothness=excellent the way may be completely unusable for your vehicle.

Trying to use smoothness alone as a proxy for “driveable by certain vehicle” might work sometimes, but is inevitably going to cause problems (see example of smoothness=excellent accompanied by surface=ice + incline=45 as a random example).

(another problem with that quote is believing in a concept of “average car” (or “average bicycle”); that is in the realm of “assume a spherical cow”. IMHO, what one assumes is “average car” is likely totally different beast from what someone else believe is “average car”. One should take it at least a notch up in specificity, e.g. “average low clearance sports car” or “average rough terrain high-clearance full-size SUV” or what have you)

That suggestion makes sense to me. StreetComplete already does that (and have invested significant efforts into it), so that may be taken as a template.

Screenshot_20260308_000439_StreetComplete
Screenshot_20260308_000439_StreetComplete1080×2553 578 KB

19

Where can I see examples of these 45% (or is it degree?) ice roads?

20

On fjords? :smile: I meant degrees (as a nice half of 90 degrees), but it does not really matter, as it was an intentionally exaggerated hypothetical example to drive the point home - i.e. that smoothness on its own can at best only rule out usability of some specific way for your specific vehicle, and not prove you can use it.

(Obviously, even much much smaller incline is a problem for ice, and incline can be serious problem for for sand, fine_gravel etc. surfaces too, and, depending on its value, even for asphalt. Especially when wet, and/or covered with fallen leafs, for example. And that is not the only tag which might preclude your vehicle, e.g. it might be perfectly flat and excellent quality asphalt, but having specific access tags prohibiting your vehicle, or your vehicle being inadequate because of width or maxweight or maxheight, or tracktype=grade5 making your vehicle sink into ground, etc.)

In short, my point was that I disagree that “on its own”

or that it can