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.
This makes me want to take out my longboard.
(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.
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!
A surface can be flat while still increasing or decreasing in relative elevation.
Therefore, a route can only be level if start and end point are at the same elevation and there is a flat/level road between them.
Flat is an opt description for the goal here. Like you mention, with elevation gain between the points we can still try to find a flat route.
Another mechanism might be a kind of user-defined cost-curve, where a gradual climb to 10 might be preferred over a steep climb to 8, etc.
https://github.com/opentripplanner/OpenTripPlanner
https://github.com/opentripplanner/OpenTripPlanner/blob/dev-...
- Bicycles
- E-bikes up to 25km/h and 250 watt (same as bicycle)
- E-bikes with wide tires (banned in certain areas)
- E-bikes going 45km/h (need to use car roads)
- Mopeds going 25km/h (need to use bicycle lanes, can't be in certain areas)
- Mopeds going 25km/h electric (similar, but can use more areas)
- Mopeds going 45km/h (need to use car roads)
- Motorcycle (need to use car roads, don't have privileges over cars other than filtering)
- Tractor / agricultural machine
- Mobility scooter (can use bicycle lanes, can absolutely not use car lanes)
- Mobility vehicle for people with a disability (can use most bicycle lanes and have more parking privileges)
- Electric wheelchair
- Light electric car / micro-car (can't use bicycle lanes, can use ferries)
- Tricycle usable with car license
- Tricycle useable with motorcycle license
And probably some more I forgot.
Any savvy resident however knows the location of escalators, lifts and metro stops to bypass that, and all have different allowed times of access and operation.
Google Maps absolutely failed.
Would be fun to rig up something for these cities. Which are you in btw?
Sure Apple Maps tells me there’s qualitatively that there are hills on my walking route, but the estimated walk time seems hilariously optimistic once I start walking around a hilly city. For reference I’m a fast (15min or less per mile NYer) walker normally.
For example I just input a 1/2 mile walk down a steep hill and the return walk. The estimated walk time was 10min down and 11min up. These estimates are far too close to each other and far too close to default flat walk estimates in Apple Maps.
I really miss driving down Gough ("Go").
1. The length of uninterrupted high quality bicycle ways (e.g. no traffic lights crossings etc.), a 2 km uninterrupted path beats a 1 km route with a ton of crossings and traffic lights
2. The quality of the bicycle path surface. I accept a slightly longer path if the road surface doesn't resemble a moon landscape
3. The potential for "chaos" (for a lack of better words) on that route. For example I will take a detour if it avoids going through areas with tourists and taxis, all of whom appear to be surprised by the concept of the bicycle on a bicycle path on a deep existential level.
Of course hills can play a role as well, but that may be more important in some cities than others.
Most of us would take a hill with a protected bike lane over a flat 45mph.
Though I do know some people who prefer them because they can be a little faster. Not worth it for me. I'd much rather go a little out of my way for a comfortable safe ride.
The flattest route is only 0.2 miles longer than the shortest, but goes from 200ft of climbing to 500ft of climbing, 12% max grade to 22% max grade.
Apple maps picks the shortest every fucking time.
I've checked out a few bike mapping apps recently and one feature I found absolutely invaluable was grade indications like http://hillmapper.com (which unfortunately seems unmaintained.)
Google Maps elevation diagrams comparing the various selected routes are nice but they do not do a good job of highlighting extreme grades. I feel like you actually want to graph the change in elevation rather than the elevation itself.
Using a route I cycled the other day (near Mission Bernal Safeway to near Diamond Heights Safeway). I think the routing may overweight bike lanes too much. For instance it will go four blocks by shared street and bike lane to avoid the two blocks on Clipper between Sanchez and Castro which are not a bike lane.
On my heavy cargo e-bike I've found there is quite a non-linear difference as the grade increases. 12% and I'll work a bit but be fine. 22% (the route Google Maps sent me...) and I'll all but collapse after a block.
Getting between those two Safeways is rough. Bikehopper fails, it suggests the harry street steps; a non-starter for most. I’ll try to fix it. I definitely agree that grade is non-linear. We use accelerating weighting for grade so a hill that is twice as steep is more than twice as “discouraged” by the routing engine.
For bike routing I think e-bikes need a separate profile from acoustic bikes. Hill matter less and stairs are totally out of the question (this is important for routing in and out of transit centers).
I’m a cyclist - thought I knew the terms.
‘Acoustic bike means a bike without an electric assist. So, a "normal" bike. I know the Path Less Pedaled youtube channel has used this term for at least a couple of years, though I don't think that's necessarily the originator. It's a play on electric/acoustic guitars.’
https://www.reddit.com/r/cycling/comments/14wwx0t/whats_an_a...
I always thought “analog” made more sense and it’s commonly used in other areas.
(Okay, technically you could make an e-bike with completely analog electronics, but I highly doubt anyone does commercially)
There’s even “pushbike” if you want to go way back, though admittedly it sounds rather archaic.
“Acoustic” just sounds like a Portlandia joke.
I guess as a cyclist in SF I’m not necessarily looking for the routing to be perfect but I am looking to see the information that matters so I can understand how appropriate the suggested routing is.
Agree that e-bike and acoustic bike riders probably do have slightly different sets of preferences. A big one for me is that I’m ok with 4 way stops every block on slow streets on an e-bike but on an acoustic bike they’d drive me nuts.
...though the elevation model I'm currently using is courser (~30m, from Mapzen skadi). This is a good reminder to fix that where available!
Hit me up if you want to use the iOS beta which has some nice transit features (already available on the web).
This was on a k8s cluster for a bunch of reasons. We eventually scrapped it and put the stack in one box instead of five.
Combine these two for the easiest bike ride to a sunny day
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.)
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.