Should we treat smoothness=bad as unpaved or not?

Is there any way you can change the way in which MKGMAP treats the smoothness=bad tag.
There are a lot of highways where people tag the smoothness as bad, where in reality, there are just few odd potholes. This does not give the road anything like the speed reduction an unpaved road would have, and consequently its nearly impossible to get the routing engines to take you down these potholed roads unless you put a via point right in the middle.
Im assuming the smoothness=bad tag reduces the road speed down to just a few kmph ? Routing in rural Khon Kaen produces some very strange directions because of this.
Is there any way that a asphalt potholed road can be treated as paved, and if it can be done, just reduce the speed of those roads to say, minus 15 mph, from the usual speed for that road class ?
It would produce far more accurate routes.
Russ.

Moved from another topic by the moderator

Hi Russ,

At first I thought that the roads you mentioned were just mis-mapped and thus should be corrected. However, the definition of the key

smoothness=bad

is

(robust_wheels) trekking bike, normal cars, Rickshaw and all below. 

In my mind to fit this category “bad” there can only be so many pot holes per distance of road that you can avoid most of them with one of the mentioned types of vehicle. (Bear in mind that a rickshaw is a “pot hole detector”, having 3 wheel tracks.) On such a road you would want to avoid getting one of your wheels into most of the bigger holes.

Based on this I support your change.

This may open a can of worms, as this tag appears to be very controversial.

Regards,
Peter.

Sure, I can remove smoothness=bad from the unpaved list, but as Peter says this might be controversial.
I’d like to hear more opinions here first before I remove it. Would be nice if this forum has a poll.

I would certainly argue that a paved road with potholes is certainly not unpaved… and as the smoothness tag is subject to a lot of interpretation, it would be better to have it removed, than added by default to the “unpaved road list”.

My concern is more about the way that Mkgmap treats it and the effect on routing … perhaps if the tag smoothness=bad is used with surface=asphalt/paved, could Mkgmap be set to treat the road in a higher class with a road speed to match ?

I see the wiki seems to concentrate what type of vehicle can use the road, but my argument is that a potholed road does not necessarily prevent various classes of vehicle using them, but it does impact the speed at which it can be driven.

Im not sure what sort of programming can be done in Mkgmap to reflect this thought process, but if its limited, then my vote would be to simply remove the smoothness tag from the unpaved list.

This is the sort of discussion that you can find in the wiki. I think our reasoning was that with a Garmin GPS you have the option to not route over unpaved roads. There are roads that are so badly potholed they are worse to drive/ride on than a reasonable unpaved road and that is why it is flagged as unpaved. We can move the goal posts either way, but we can’t please all people all of the time. :wink:

I’m easy either way for this particular value, but I will argue that **anything below bad should continue to be flagged as unpaved for routing purposes.

As for speed, I drive my truck or car at about the same speed on paved and unpaved roads, unless there are bends, people or other vehicles around, up to 100 km/h. Ask any Australian driving in the Outback. Potholes or corrugations will slow me down on either roads. Not everybody drives the same.

If its an easy tweak, without opening those cans of worms, then I agree… only values worse than “bad” make the unpaved list.

It is very easy. I only have to remove ‘bad’ from the list of unpaved options.
But I would like to hear what others think of this first, so…I have split this section off and make it a separate topic.

If there are enough reasons to change this, the default mkgmap rule (smoothness=bad is now treated as unpaved) could be adapted. I also dropped it on the mkgmap-dev list

Edit: for my bicycle Openfietsmap I consider the tag smoothness=bad alone not good enough to give it the value unpaved.

Creating Garmin maps myself, I can tell you that changing that in the style file is easy (it is not in the mkgmap program proper, but in a custom file which contains the rules).
What does “bad” actually mean? There are many unpaved roads which I prefer to bad paved roads when I am on bicycle. In Isaan, I found many asphalted roads which have lost the smooth top-layer of asphalt (they had it somewhen, as can be seen from the remaining parts of lines on the road), but now small irregular stones of about 1 inch / 3 cm bound in the remaining asphalt shape the surface, torturing cyclists. On a car, truck, or motorbike, that’s still a good road. In contrast, heavily potholed roads are no problem for me: slowly riding on two wheels, I can drive around them, staying on smooth asphalt…

I don’t remeber if in Garmin “avoid unpaved roads” means avoid at all cost, or just avoid only if other routes exist.
For example, some could prefer driving 100m of smoothness=bad than driving 500m on a better surface.

Is too much work (now or in the future) to make this style decision dependant on country or state?
Or maybe setting road_speed to 0 or decreasing road_speed (by 1 or more), like is it done with stop signs or other OSM elements.

I’m pretty sure garmin will take the detour of 500m with unpaved avoidance on.

Decreasing the road speed is a good one. We could remove it from the unpaved options and add the following rule instead:

Highway=* & smoothness=bad { add mkgmap:road-speed = '-2' }

This topic again raises the difficult question of just exactly what makes a highway bad for certain uses. The answer is, as Russ and Bernard point out, it all depends. A bicyclist, an in-line skater, or even a wheelchair, can negotiate a heavily pot-holed road more easily than any powered vehicle typically traveling at higher speeds. An unpaved “compacted” road with loose gravel on top can be driven at highway speeds with an automobile or truck but might be extremely dangerous for a motorcycle. The pros and cons of combining smoothness, tracktype and other parameters to come up with yet another measure called “drivability” have also been discussed. However, all of these systems are based on subjective opinions and are therefore problematical. In short, you’re never going to come to a conclusion that everyone can agree upon.

Since I make my own maps I decided to remove roads with smoothness “bad” from the unpaved list in my style file because some other mapper’s definition of bad doesn’t always agree with mine. That works for me. But I think adjusting the road-speed down is a good compromise for the general consumer of Lambertus’ maps.

I’m guessing that the Garmin simply does an arithmetical calculation and because the road speed is currently so low, waypoints set , say 25%, of the way in, simply get routed to to point, do a U-turn, then back to the highway you just came from. If you do a couple of points or get one exactly in the middle, then it routes.
I strongly agree with Lambertus and if he adds the line of code above, I believe that would be the best solution. Whether -2 is right is perhaps open to discussion, but it’s a good start.

I forgot some cases:

  • it should lower the road_speed only if it is not already marked as unpaved by mkgmap
  • if those paved roads have a smoothness parameter that is even worse (very_bad, horrible etc) this should lower the road_speed too and maybe even more.

So simply put:

highway=* & mkgmap:unpaved=0 & smoothness ~ '.*(bad|horrible|impassable)'  { add mkgmap:road-speed = '-2' } 

(this rule comes after unpaved rules)

Russ, for the routing algorithm used by Garmin (at least the Oregon) see my post to the mkgmap mailing list at http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2014q3/021825.html and the answer by popeye - it is not really the shortest time as you might think, it is rather a preference of roads with a high “road class” attribute.

Thanks for the link. This also probably explain failures calculating long distance routes

In the same list they are talking about the topic of this post. http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2017q1/025725.html

I have committed it to the new generic style. Lambertus’ old generic style map is using the mkgmap default style which is maintained on the mkgmap-dev list. There are still no actions to change the old rules, so let’s first see if this works.
https://github.com/ligfietser/mkgmap-style-sheets/commit/1950f88900baaff405bab01887d7e7acbab799af