For example, a route from SOMA to Nob Hill can be made flatter by approaching from either the east or west. Technically the "flattest" as measured by elevation gain between the two is straight up Taylor from Market, but it's much nicer to bike to the top of Nob Hill by going out of the way (e.g. Polk → California, Embarcadero → Broadway, etc.)
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.
Most people on most bikes can only take so much grade before climbing becomes impossible. A maximum grade setting would be very helpful for that exact reason.
My reasoning for the bike-hike being faster is that legs are designed for it. Legs are only inefficient on flatter ground because you have no equivalent of high gear (like extendible legs), so all that torque is going to waste.
Legs have to start, go up, go down, stop.
Wheels go brrrrr.
And almost any practical routing system will have a mechanism for tradeoffs of different aspects. Often there is a distance/time tradeoff which directly relates to speed on corresponding segments. But the tradeoff can also be in the form of "on average x seconds spent waiting green light in each intersection or time to stop before railroad crossing. So there is no reason for a system optimizing grade to completely ignore all other factors, it's just a question of weights and curves of each of them.
Edited: which apparently is hosted for free on AWS S3.
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.
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.
I agree that the tone the parent commenter used wasn't the nicest but unfortunately, factually he is correct.
(in honor of my old commute, which I miss)
https://flattensf.com/#t~-122.40850~37.77493~-122.50940~37.7...
I have to say that the Claude UI has made many inexplicable decisions here, including (but not limited to) the mysterious color coding, the confusing continuous slider over a discrete set, and the weird positioning of the height labels in the altitude graph.
This makes me want to take out my longboard.
Other than knowing the direction of my destination, it only used local information
[1]: https://github.com/valhalla/valhalla
[2]: Currently it only supports 30m resolution for elevation unfortunately
The bug seems to be apparent when you set the end point at Duncan & Diamond Heights Blvd and the start point directly north along Clipper.
This route seems to maybe save 1 ft of climbing but goes up a 23% grade.
https://flattensf.com/#t~-122.43968~37.74865~-122.44028~37.7...
Half a block up the street it takes the sensible route with only a 13% grade. (Between the two different starting points is 41ft of climbing.)
https://flattensf.com/#t~-122.44087~37.74864~-122.44028~37.7...
seems like a worthy addition to the objective!