your example (from market & taylor to the top of nob hill) is a nice illustration: (1) straight up taylor is 229 ft of climbing at 25%, (2) via polk and california it's 251 ft at 13%.
as you probably noticed, we only look at the total elevation gain, so taylor "wins"... but I see the argument for preferring an extra 20ft of a more gradual climb.
thanks! address search uses the overture address feed, which is patchy (some blocks of 24th st have 5 numbers in it)… i'll make it fall back to the nearest known number on the street
Once I was visiting Yamaha’s Yokohama office for work, and I found a pedestrian path from my hotel to the office of ~2.5km that never touched a single roadway…
Google Maps absolutely failed.
Would be fun to rig up something for these cities. Which are you in btw?
ah, I think this is related to SF's "Slow Streets" program and a genuine bug in the parser.
Cabrillo is a Slow Street, and the parser read its "destination-only" tag as closed to pedestrians, so the tool couldn't see the street at all (and started you a block over?). fixed and deployed; your trip should now go Cabrillo → 23rd → Geary.
Also "fixed and deployed; your trip should now go Cabrillo → 23rd → Geary". The snappy sentence at the start and the unicode arrows are both pretty big flags for AI writing.
Obviously it's fine to use AI for projects like these, but copy-pasting the response from a coding agent doesn't quite sit right with me.
No, as someone who writes a cycle routing engine by hand, this stuff is endemic when dealing with the trifecta of complex traffic regulations, inconsistent mapping data, and user preferences.
Looking at the repository [1], there are very strong signs for this being LLM generated. The README.md just smells of LLM tells, and Claude Code is being listed as "contributor".
I agree that the tone the parent commenter used wasn't the nicest but unfortunately, factually he is correct.
go for it!