You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Consider routing on Cayuga instead of Alemany where appropriate. Not sure there's really a heuristic here besides local knowledge, but fairly chill side street with sharrows arguably beats fast dangerous street with unprotected sometimes-disappearing bike lane
Example origin/destination pair:
Something like 1 South Van Ness -> 92 Ottawa Ave (bike only routing, with transit is obviously going to use the 14 on Mission). Personally, I'd take Cayuga there instead of Alemany, though obviously that's a personal preference and others might do something else. They were talking about making Cayuga a slow street but it's been in perpetual limbo
Alemany between Lyell and Ottawa is a highway=primary, cycleway=lane while Cayuga is highway=residential, but no cycleway value set. For one block approaching Geneva, Alemany's bike lane used to disappear, which the router did notice (since this screenshot was taken, SFMTA restriped that block and filled the gap):
Cayuga has little traffic in my experience, but I don't know how our router would programmatically know that. I'm not sure if preferring highway=residential, cycleway unset, over highway=primary, cycleway=lane, would be the right call.
If Cayuga were a Slow Street, motor_vehicle=destination might make us prefer it.Update: as of 2024, Cayuga is a Slow Street, but Slow Streets are no longer officially restricted to local traffic only.
We could consider programming in the SFMTA Recommended Bike Routes map in some way, which includes Cayuga as recommended; this seems to only be able as a PDF, not GeoJSON or similar in DataSF, though we could ask SFMTA for a machine-readable version.
The text was updated successfully, but these errors were encountered:
Since there's tags describing cycling infrastructure, the cycling infrastructure penalty takes precedence over the highway penalty. lane receives a penalty of PREFER (2.0).
There's no tags describing cycling infrastructure, but there are tags describing the road, so the highway penalty takes precedence. highway=residential receives a penalty of SLIGHT_PREFER (2.5).
For a potential solution, I don't think we should always prefer ways based solely on cycling infrastructure. For example, we could use a hybrid mechanism to penalize a road like Alemany. For example, if a way has mediocre cycling infra but is on a major thoroughfare then it should be assessed a higher penalty, and vice versa; if a way has sharrows but limits cars, then it could be rewarded with a lower penalty.
I'm not confident that there's a general rule here. Some residential streets might still have fast traffic. Preferring residential streets might have the side effect of more difficult crossings (busy arterial at 2-way stop) which we don't take into account.
Beta tester feedback:
Example origin/destination pair:
Alemany between Lyell and Ottawa is a highway=primary, cycleway=lane while Cayuga is highway=residential, but no cycleway value set. For one block approaching Geneva, Alemany's bike lane used to disappear, which the router did notice (since this screenshot was taken, SFMTA restriped that block and filled the gap):
Cayuga has little traffic in my experience, but I don't know how our router would programmatically know that. I'm not sure if preferring highway=residential, cycleway unset, over highway=primary, cycleway=lane, would be the right call.
If Cayuga were a Slow Street, motor_vehicle=destination might make us prefer it.Update: as of 2024, Cayuga is a Slow Street, but Slow Streets are no longer officially restricted to local traffic only.We could consider programming in the SFMTA Recommended Bike Routes map in some way, which includes Cayuga as recommended; this seems to only be able as a PDF, not GeoJSON or similar in DataSF, though we could ask SFMTA for a machine-readable version.
The text was updated successfully, but these errors were encountered: