Yes -- at the bottom of the post we show how you can use our mapzen.js library to draw routes on a map. If you know Leaflet it's relatively straightforward.
Hi! I'm with Mapzen. Setting `use_roads` to zero means a preference for using roads tagged in OpenStreetMap that have bike infrastructure, as opposed to roads without bike lanes.
We don't route on sidewalks, and will avoid paths that are tagged `bicycle=no`. You can get a sense of these on our bike map. https://mapzen.com/bikes/
Where is your bike lane data from? For example, the chicago loop detail on the linked page is incredibly (years now) out of date, and would send people down routes that have replaced bike lanes with dedicated high speed bus lanes.
Have you considered using data from the California Statewide Integrated Traffic Records System (SWITRS) in your routing algorithm? You can filter traffic collisions for those involving bicycles in order to identify roads or intersections particularly dangerous for cyclists.
Hi! I'm with Mapzen. Yes, the default for `bicycle` are now 0.25.
If you're familiar with Leaflet, it's also pretty easy to draw routes in mapzen.js and pass different parameters to the router -- check the bottom of that post.
We thought a lot about the colors for the new bike map. Green is pretty universal for trails and paths where bicycles are protected from cars. But colors are less standardized for places where bicycles share the road with cars – bike lanes, streets with "sharrows", and signed bike routes.
For this first version of the bike map we focused on creating a "warm" map that complements the basemap and invites the reader to spring into exploring the bike-friendly ways tagged in OpenStreetMap, the community mapping wiki.
While red draws the eye and is a warning color, we found that it overwhelmed the map in most cities when used for the least safe routes. If you want to experiment with colors, you can do so in Tangram! Instructions are at the bottom of the post. Please let us know what you come up with.
While OpenStreetMap's tags are a great starting point, they aren't a perfect proxy for safety. We're working on ways to effectively mark greenways, green waves (timed lights), `living streets`, or even buffered bike lanes.
Seattle is quite well tagged in this regard, and we're working to improve San Francisco. What will help most is tagging important streets into a `route relation` in OpenStreetMap (and of course getting your city and state government to build more protected bike lanes and neighbourhood bike routes).
This map is a first step, and your feedback will help make the next version even better. Thanks!
hey eean -- that's on our roadmap! We can already route by bike, and by BART. Multimodal Bike+BART would basically look and act like the walking + transit directions we have now. Drop us a line at hello@mapzen.com and we'll let you know when it's ready.
Hey, I'm with Mapzen, let me know if you have any questions. We're importing GTFS feeds from multiple transit agencies and serving them via a single API via our Transit.land project. We then pass the data into Turn-by-Turn, our open source routing engine which serves them up as data tiles. We select routes with on-the-fly costing and draws it via LRM (Leaflet Routing Machine).
open > proprietary: If you want routing (and elevation and a time-distance matrix) based on open data, via an API with liberal licensing, all based on open source code that you could run yourself if you wanted, you may want to take a look at Mapzen's Turn-by-Turn routing. We built it to get away from this kind of thing.
Mapzen seems like a good idea, but I can't help but wonder (with respect): Can a developer expect it to be here in 2026?
Seems like someone integrating against an API has the choice of "Use one from a big company with a proven business model and risk their TOS changing to have it taken away" vs. "Use one from a firm with only a few years of history and risk them going dark one day (or changing their TOS)."
In this specific scenario, I'm not sure that this solution would guarantee the developer could have avoided this failure mode.
A great question. That's why we make all the underlying source code open, including chef and docker config info for people to build it themselves if they want or need to.
You're right, it's a bit of Catch-22. But the benefits of using the open approach though is that it helps promote them which could help get them marketshare/mindshare and help bring attention/support to them. At least that's what i'm hoping would be the case.
