Improve speed limit calculation for narrow roads

[sanderd17]

Following a discussion on IRC, I'm opening a ticket here.
A narrow road penalty was implemented in #1338. But halving the speed is way too harsh IMO.

The width of a road (or the number of lanes) is normally related to the throughput of the road, and not to the speed of single vehicles. Yes, you may have to wait until someone from the other direction passed you, or even back up a bit. But 1-lane roads normally have only one lane because it's very calm there, and you're unlikely to bump into someone else. And on a 2-lane road you can also be stuck in a traffic jam (something that's very unlikely on a 1-lane road) or behind a slow vehicle.

Also, most small roads are badly tagged (due to lower traffic thus less mappers). Perhaps some have a width tagged, others don't. Same for the lanes and maxspeed.

I'd prefer to completely remove the narrow-road penalty, and replace it with a penalty based on curvature, or perhaps road classification.

F.e. on a highway=unclassified (the typical narrow road), the legal speed limit is usually 90 km/h around here. But trying to get a speed of 90 km/h would be suicide or murder. On an unclassified road, you can't expect more than 60 km/h in my experience.

Apart from that, lanes=3 and width=3 should be the default for unclassified roads, even if it's not tagged like that (but then the penalty should also be made less harsh, the current speed for roads tagged with lanes=1 is really too low).

The most interesting thing would ofc be speed depending on curvature. Though I don't really know how to calculate that (and make it independent from the density of nodes on the way).

In my example on IRC, the estimated speed ranges from 12 km/h for a street with tagged width but no tagged maxspeed (so the maxspeed defaults to 90 km/h), to 84 km/h for a street with tagged maxspeed but no tagged width (but also just one lane, which should be the default for unclassified roads). I hope you can agree that this difference is too big for two roads that are basically the same.

http://map.project-osrm.org/debug/#16.05/50.94951/3.08938
http://map.project-osrm.org/debug/#16.05/50.93666/3.07863

Actually, the 84 km/h road is a lot slower as it's surrounded by trees which block your view, while the 12 km/h road has an open view most times of the year (if there's no corn on the fields), so you can even get above 60 km/h on that road. But as a routing engine can't realistically take the view around a corner into account, both streets should be about equal.

Thanks for considering this request.

[cmoffroad]

Reopening this discussion as I am currently investigating this topic.

As of April 2024, OSMR handles narrow ways as follows (standard car profile):

• will not direct a vehicle along a road with a width<2.2 and a narrow=yes tags
• will adhere to any specified legal max_width
• will impose a 0.5 speed penalty for any way with width<=3, or any way with lanes<=1 that does not have oneway=yes.
• will penalize oneway=alternating by a delay of 40%.

Note: I maintain these rules on the OSM wiki page: https://wiki.openstreetmap.org/wiki/Routing/Narrow_Roads

The width of a road (or the number of lanes) is normally related to the throughput of the road, and not to the speed of single vehicles. Yes, you may have to wait until someone from the other direction passed you, or even back up a bit. But 1-lane roads normally have only one lane because it's very calm there, and you're unlikely to bump into someone else. And on a 2-lane road you can also be stuck in a traffic jam (something that's very unlikely on a 1-lane road) or behind a slow vehicle.

To clarify, I completely disagree with the original poster. Narrow roads should be tagged based on their physical condition rather than anticipated traffic volume. In Thailand, narrow roads are prevalent in both urban and rural areas due to historical motorcycle use, inadequate infrastructure planning, and budget constraints. Routing cars through these narrow roads, often less than 3 meters wide and bordered by fences or walls, can be extremely challenging, especially when encountering oncoming traffic.

---

Here are some concerns regarding the current rules:

will not direct a vehicle along a road with a width<2.2 and a narrow=yes tags (source)

The OSM wiki does not clearly specify the use of narrow=yes for very narrow ways. The examples provided often depict wider roads, including two-lane roads with parking on both sides.

will impose a 0.5 speed penalty for any way with width<=3, or any way with lanes<=1 that does not have oneway=yes. ([source](Source: https://github.com/Project-OSRM/osrm-backend/blob/master/profiles/lib/way_handlers.lua#L400-L402))

It appears that the bidirectional check is only applied when lanes <= 1, but not when width <= 3. This implies that a one-way narrow street may receive an unnecessary penalty.

It's worth considering why borderline cases, such as roads with width <= 4, where vehicles passing in opposite directions would need to slow down, are not currently addressed.

---

My proposal, inspired by this GitHub issue: #6712

-- Extremely narrow cases, where two vehicles in opposite directions won’t pass each other, should be avoided at all costs.
if is_bidirectional and (width <= 2.2) then
  width_penalty = 0.25
end

-- Narrow cases where two vehicles in opposite directions cannot pass each other, drivers must find side gaps or maneuver around side streets.
if is_bidirectional and (lanes <= 1 or width <= 3) then
  width_penalty = 0.5
end

-- Borderline cases where vehicles in opposite directions can pass each other but must slow down beforehand
if bidirectional and (width <= 4 or (not lanes and lanes_marking=no) or narrow=yes) then
  width_penalty = 0.75

Looking forward to receiving feedback from the community. Let's work together to improve routing support for narrow roads 😃

Note: I've also put forward a proposal for rendering narrow roads: gravitystorm/openstreetmap-carto#4948

[github-actions]

This issue seems to be stale. It will be closed in 30 days if no further activity occurs.