Find the flattest route between any two points in SF
A new web tool for San Francisco cyclists and pedestrians maps routes that minimize elevation gain rather than distance, highlighting how much hills change the experience of getting around the city. Commenters praise its live elevation profiles but probe its underlying data quality, routing quirks, and lack of awareness of bike infrastructure or steepness limits, comparing it with projects like BikeHopper, OpenTripPlanner, and BRouter that juggle hills, safety, and surface quality. The conversation broadens into how elevation-aware routing could better serve e-bikes, wheelchairs, and other cities worldwide, and how finer-grained terrain data and smarter cost functions are essential for truly usable hill-sensitive navigation.
Overall reception
- Many commenters find the tool clever and fun, especially the live-updating elevation profile and the “wiggle”-style SF routes.
- Several say they’d found this kind of thing very useful when they first moved to SF or when choosing e-bike / longboard / running routes.
- Others note it mostly confirms the well-known “wiggle” and general hilliness of SF.
Routing accuracy and data issues
- At least one user reports a clearly wrong route choice in the Richmond; the author attributes it to a tag‑parsing bug around “Slow Streets” and says it’s fixed.
- Another reports odd detours (e.g., at 22nd & San Jose) and discontinuities where the tool doesn’t follow an obvious straight path.
- Some routes pick very steep segments (e.g., 20–23% grades) to save trivial climbing compared to gentler alternatives; current optimization only considers total elevation gain vs distance.
- Discussion points to the importance of good elevation models; digital terrain models (DTM) are preferred over DSM to avoid “building hills.” USGS 3DEP and 1m DTMs are mentioned as better sources than coarse 30m data.
Grade vs total climb and human effort
- Several cyclists emphasize that maximum grade and steepness matter more than total gain, especially in SF.
- Suggestions:
- Add a steepness penalty or user‑defined cost curve.
- Allow maximum grade constraints and possibly separate profiles for e‑bikes vs non‑assisted bikes and wheelchair/stroller users.
- Show grade or derivative-of-elevation graphs, not just elevation profiles.
Safety, bike lanes, and preferences
- Some say they would trade hills for safer, calmer streets; current tool doesn’t yet know about bike lanes and sometimes routes along dangerous arterials.
- Other dimensions users care about: uninterrupted bike paths, surface quality, traffic “chaos,” stairs avoidance for e‑bikes, and avoiding frequent stops.
UI/UX and implementation criticism
- UI feedback: confusing color coding, slider over a discrete set of routes, unclear elevation label placement.
- Some suspect the code and even some replies are heavily AI‑generated, and debate whether that’s acceptable; others push back on tone but acknowledge AI involvement signals.
Comparisons and extensions
- Compared to Google/Apple Maps, OpenTripPlanner, BRouter, Valhalla, Bikehopper, Modemix, etc.; those often balance hills with safety and transit.
- Many request similar tools for other hilly cities (Seattle, Istanbul, SF Bay–wide, Puget Sound, Amsterdam, Sydney, etc.) and joke about flat cities like Dallas or Cambridgeshire.