I've been at this for quite a few months now. I'm starting to get a bit tired, or maybe it's just that I've gotten sick. Regardless, to avoid a bit of burnout and keep my enthusiasm level up,  I've been working on maps. 

I want to provide a map editor that allows us to:


 center a map at a given coordinates and zoom level
 lay out a set of way points on the map and calculate a route along them

mark Points of Interest along the way either by clicking at a point and getting the address or search for the point of interest and getting the lat/long
generate static thumbnails of the map that we can shared out.
save the maps and then reload them from search results later.


I reread the Google Maps API terms and it appears they've made some subtle changes which throws a wrench into my plans. Namely the following clause is causing me some grief:


"(b) 
No Pre-Fetching, Caching, or Storage of Content.
 You must not pre-fetch, cache, or store any Content, except that you may store: (i) limited amounts of Content for the purpose of improving the performance of your Maps API Implementation if you do so temporarily (and in no event for more than 30 calendar days), securely, and in a manner that does not permit use of the Content outside of the Service; and (ii) any content identifier or key that the Maps APIs Documentation specifically permits you to store. For example, you must not use the Content to create an independent database of "places" or other local listings information."


The net effect of this is that we can build a map, put points on it, but I am prevented from saving out the the data that represents the nice blue lines outlining the route. So if we use Google Maps, you would have to load the map and then press a Calculate Route button to see the actual route. Also, it looks like I would not be allowed to store any addresses generated by their geocoder and reverse geocoder as they specifically state.

Maybe I am too much of a stickler for the rules, but I really don't want to run afoul of Google's terms of service. I do take these things seriously. It would suck to build something only to have them terminate my account.

The terms also mean that if we lay out a route on a Google Map using their geocoding and routing engine, we would be prevented from exporting that for use on a GPS devices. So for the moment, we would only be able to export any points we laid out on the map ourselves and would have to let the GPS calculate the route between them.







Speaking of GPSs, I have most of the GPX importer built. This is the format used by Garmin to import and export routes. I've been working with a sample file Yun Lung Yang kindly gave me and it's turning out to be wicked easy.

I spent quite some time wondering whether or not we could build a successful site using only routes uploaded from GPS's. Unfortunately, route/trip planning is such a huge part of what we are trying to do here, so not being able to save out routes that were laid out on the map is simply a non-starter.

So I've started looking into alternatives. Google has by far the best maps out there. Other services, such as Bing and MapQuest have similarly restrictive terms for the use of their routing and geocoding data. 

The most promising possibility I've found so far is a company called 
Cloud Made:


 

These guys use data provided by the Open Street Maps project and as a result any data generated by their API's is free to use for any purpose under a Creative Commons license. They even expressly allow saving out the map images. It looks like they have all the features we would need including Geo-Coding (Turning address into Lat/Long), Reverse-GeoCoding (turning a Lat/Long into an address), route calculations, markers, etc. 

They also have a for-fee SDK available with data that can be installed on a smartphone to allow us to do off-line mapping which will be absolutely key for ADV riders out of range of cell signals. 

What's nice is that they do have a Google Maps API compatibility layer so all the code I've written can be re-used. (In designing my code I did anticipate that I might have to replace the mapping engine and have set things up accordingly so we could, theoretically, support any number of mapping backends that we can switch out. )

I suspect the quality of the cloudmade routing and geocoding won't rival Google's, but maybe it will be a "good enough" for our purposes. The sample apps I've seen online rival what we see with Google, at least around well populated areas.

In order to use them, I would have to sign up for an account and give them a credit card, but at our current levels, it looks like it would be free for quite some time before we get to their minimum-for-fee levels. 

So here's my thinking:

1. I'll finish up the Google Maps work that I'm doing but I just won't save out the routes, per their terms of service. 
2. Those with Garmins or other sources of GPX data will be able to upload their GPS tracks and they will get saved.
3. We'll be able to mark points of interest on the maps. 
4. We'll be able to mark waypoints for the routing engine to use. 
5. For the time being, if you want to see the route in an already saved map, you'll have to click on the Calculate Route button.

Once I get that done and working, I'll build support for the Cloud Made API's, and we can start experimenting with them to see how well they work. 

If you guys come across other mapping providers or see something I'm missing with regards to storing data from Google, Bing, MapQuest, et all, please let me know.

I sent an inquiry to Google to see if maybe their business accounts allow caching/re-use of route/geocode data.

Yermo as we work quite a bit with different third parties I reread the agreement and I think it's possible that it is simply an implementation question. Routes and directions can be saved indefinitly, just not on your local MbM servers. The API can be used to build maps and directions and then the resultant maps can be stored with Google. It sounds like you could have a MbyM account with Google and then create map/routes against them, and even publish the KML files. I didn't read anything in the terms that would seem to prevent a very rich implementation, only that the resulting data could not be stored on local servers for other than improved performance and not past 30 days. It actually seems pretty reasonable to me because all of the mapping imagry, data, and turn by turn is owned by Google or licensed by Google. It seems like a little bit of over thinking the problem.

For example these guys have a pretty nice implementation: 
http://www.newenglandriders.org/Great_Routes_and_Rides/...

yea, unfortunately  "Show me all maps with content 50 miles from my current location liked by Josh and Duncan tagged with goodroads." becomes impossible if I can't keep the data locally. There are all kinds of searches I want to be able to do using the data. They key discriminator is the search and sharing, otherwise we could just, as you indicate, save a bunch of KML files over at Google and call it done. But there's no innovation there. 

The other key thing that I want to implement is being able to use the reverse geo-coder to get the address of a point of interest so I can normalize geo-tags to an address. This will let us answer the question, "How many members have checked in at the Gap?".

Unfortunately, even the address lookup from a lat/lng is not storable and thus not searchable. I had considered asking people to enter the addresses by hand, but that obviously won't work.

Of course, there's nothing preventing us, if we like Google Maps, from doing routing/geocoding from a third party source and laying the results out on the Google Map. That may work. 

We'll see.

Would just caution to not let the "requirements" get too far ahead of the reasonable expectation of a deliverable, or the reasonable resources. There are many opportunities for innovation.

I understand. It's not feature creep. Really.

All of the social index code, the liking, tagging, @ mentioning, notifications, etc. has been in support of this set of requirements; from the beginning. There's no creep from the original vision. Really. (Actually three years ago I built an alpha version of this route planner which is what highlighted the need for a social index backend. Now that I have the social index backend built I can finally do everything I've wanted to on the maps. And then they changed the terms of service on me.)

I just got caught off guard by the terms of service. Originally, the caching language was different and allowed me to do what I want. But the new wording pretty much prevents it. 
The amount of work involved, regardless of the backend I choose, is relatively close. The more I think about it the more I'm am likely to try Cloud Made. Assuming the service works and is reasonably reliable, it will allow us to put something truly cool and, at least for the present moment, unique together. I'm really quite intrigued by their offline mobile mapping solution. That's a big missing piece for the mobile app and one that Google does not address.

I appreciate the feedback, thoughts and having people to bounce ideas off of. It's sometimes difficult to do this stuff in a vacuum and the conversations, even in the forum, help me with my thinking. 

Ok, after some more research I have a direction that I think is actually going to end up being better than my initial approach.

There are no restrictions for me to layer any additional data on top of a Google Map. I just can't use Google Map data anyplace else. The Google Maps, from a sex appeal point of view, are still vastly better than OpenStreetMaps.

Cloud Made provides a simple separate Routing and GeoCoding web service. These services speak the open GPX protocol, the same one that the Garmin GPSs, amongst, others use. I can throw a set of lat/longs at it and it'll return a route in GPX. Or I can through an address and it'll return a lat/lng. 

So, I'll just use Google maps for display but not use any of their information services. When doing route planning, I'll use the Cloud Made interface. The resulting route and address info is freely distributable, as long as I provide attribution. This means I can store it locally. This also means I can export it in GPX format which means buffalo, jpcfjr, Yun Lung Yang and Michael Milner will be able to plan a trip on the maps and then download the tracks into their Zumo GPSs, which I think is a key requirement.

So now we have a closed loop. Plan trip -> download to GPS -> go on trip -> upload resulting actual track .. repeat process ad infinitum. Tag, share and social search.

It also means that any object we place on the map can have an associated address which I can then store allowing me to do all kinds of interesting searches/statistics and will allow us to build up our own database of motorcycling places; another key requirement.

The only downsides I see might be the quality of the routing/geocoding especially in outlying areas. This shouldn't be too big a deal since these maps are for entertainment/information purposes only. For those cases where someone goes out there and finds a particular route isn't quite accurate, they can always upload a GPX track of the actual route from their GPSs.

If I can get this to work it's going to be extremely cool ... and we'll have GPS devices support out of the gate as a nice side-effect.

Sounds like a way forward