Ted’s observations about Google’s limitations are spot on. Using my map I’ve already found a couple of usable routes that I didn’t even know about.

Not only that, MapQuest’s bicycle routing API works in several countries outside of the United States. MapQuest generates routes in Canada, the UK, Germany, Denmark, the Netherlands and Mexico. It does *not* work for locations in Japan and Australia.

Mapquest’s API does have a couple of serious limitations: it doesn’t seem to recognize all bike facilities, and I think Mapquest should weight bike facilities a little more strongly.

My map app is still very clunky and doesn’t demonstrate MapQuest’s capabilities very well. The major functionality fail is in it’s geocoding capability — that’s the start and destination addresses that Johnny K asked about.

The other major shortcoming is it doesn’t fail very gracefully – you either just get a blank screen, or a random map location (depending on the failure). This is *my* code and not a shortcoming of the underlying API.

I think the main difference at the moment between the proposed MapQuest tool that utilizes OpenStreetMap and the Google BikeThere Feature are the underlying data sources. While both applications get their data from a variety of sources, the data in the OpenStreetMap is much more dynamic and flexible in terms of user input. Although Google BikeThere does allow and encourage user input, by asking users to indicate problem areas where the directions generated are inadequate, incorrect, dangerous, etc., the underlying directions and structure still need to be approved by the Google system. Conversely, with OpenStreetMap, it is much more open to user input and therefore, potential more reflective of the actual bike routes that people use.

However, they are both progressing towards the same goal, which is to capture the best bike routes when queried by a user. This is, in fact, a very lofty goal and requires some very complex algorithms and programing, as a bike route can often be so much more complex than a driving route, especially if there are useful shortcuts, off-road sections, etc.

I am looking forward to watching these applications progress!

What is exciting, is that maybe we’ll see the kind of user-friendly widgets found on commercial mapping sites, combined with the user-contributed secrets added to OpenStreetMap–plus elevation data.

[T]he lack of actual human/local knowledge or input [in Google Maps], is also problematic for me, although Google claims to be solving this problem through their feedback option.
[...]
OpenStreetMap, which is an open-source, free, editable online mapping service.
[...]
What separates OpenStreetMap from Google Maps, MapQuest, or other similar online mapping tools is that it is dynamic, user-oriented, and transparent.  Perhaps the OpenStreetMap Wiki sums it up best:

OpenStreetMap creates and provides free geographic data such as street maps to anyone who wants them. The project was started because most maps you think of as free actually have legal or technical restrictions on their use, holding back people from using them in creative, productive, or unexpected ways.

[...]
OpenStreetMap allows each individual cyclist to edit or view data based on his or her riding preferences. One is not limited to avoiding major intersections, like Google’s current Bike-There feature does, for example, and instead, one can choose a route based more on personal preferences. This is limited however, by lack of elevation and terrain information, as this kind of map data is often expensive to obtain or copyrighted, and thus, doesn’t really fit with the OpenStreetMap model.

So the (potential) big deal here is that MapQuest is developing a way of providing bike routes that are enhanced with information provided by real cyclists–plus elevation information. Imagine being able to generate a bike route that includes safe shortcuts that Google Maps doesn’t know about (my bike commute includes two of these), and also allows you to choose alternate routes based on the elevation contours you would encounter.