Bicycle profile routes around the edge of a movable bridge area

[1ec5]

Issue

A man_made=bridge area only represents the physical footprint of a bridge structure, not a routable closed loop. But the default bicycle profile routes around the edge of this man_made=bridge area in Milwaukee, Wisconsin, that happens to be tagged bridge=movable:

Though this example may seem contrived, it’s actually quite easy to encounter because any roadway that the bridge carries needs to be connected to the bridge area. Here, the bicycle profile is using the edge of the bridge area as a shortcut to hop off the curb from the sidewalk to the roadway:

Diagnosis

The default bicycle route’s initial routability check passes, because the way has a man_made=* tag (and would also pass it if it only had a bridge=* tag):

osrm-backend/profiles/bicycle.lua

Line 256 in 0ca9131

data.bridge = way:get_value_by_key("bridge")

osrm-backend/profiles/bicycle.lua

Lines 262 to 264 in 0ca9131

	(not data.man_made or data.man_made=='') and
	(not data.public_transport or data.public_transport=='') and
	(not data.bridge or data.bridge=='')

The profile assumes that bikes can go 5 kilometers per hour along a movable bridge:

osrm-backend/profiles/bicycle.lua

Lines 171 to 173 in 0ca9131

	bridge_speeds = {
	movable = 5
	},

So it turns the bridge area into a highway=movable edge with a duration weight of 5:

osrm-backend/profiles/bicycle.lua

Lines 324 to 332 in 0ca9131

	local bridge_speed = profile.bridge_speeds[data.bridge]
	if (bridge_speed and bridge_speed > 0) then
	data.highway = data.bridge
	if data.duration and durationIsValid(data.duration) then
	result.duration = math.max( parseDuration(data.duration), 1 )
	end
	result.forward_speed = bridge_speed
	result.backward_speed = bridge_speed
	data.way_type_allows_pushing = true

The tests make clear that the profile isn’t checking for a routable highway=* value, as it should:

osrm-backend/features/bicycle/bridge.feature

Line 18 in 0ca9131

| cde | | movable | yes |

History

This issue was fixed in #3739, but contrary to the commit message, it was only fixed for the car profile. The foot profile theoretically has the same loophole, but it happens to avoid this issue because no speed is defined for any bridge=* value.

This issue was recently rediscovered by @kaneap in OSMUS Slack. By coincidence, this bridge exacerbates the problem, because each of the streets and paths that pass under the bridge also connects to the bridge area.