Why (and how) we've switched away from Google Maps
this week we went live with a significant change to our service - in most countries we've moved away from Google maps and are now relying exclusively on OpenStreetMap maps served by MapQuest.
Before I dive into the why (and the how for all our neogeo mapping freaks amongst our readership), let me say that Google maps remains a phenomenal service that is continually adding amazingly innovative new functionalities. The boom in online cartography witnessed over the last years was kicked off by the launch of Google maps, and I can still remember the light bulb going on in my head when in early 2005 I saw housingmaps.com, the first Google maps mashup. It was clear I was looking at the future. A little over a year later, in June 2006, we launched Nestoria. So I am the first to recognize the unequaled contribution Google has made and continues to make in unlocking the potential of cartography for the world (and technology in general).
In 2006 I had another "ah-ha" moment as well, though. I met Steve Coast, the founder of OpenStreetMap. He explained the idea - a free and editable map of the world made by user contribution. A map that would not just allow me to get the final rendered output, but also the actual data underneath. At the time, looking at Steve as he showed me the GPS device he was using to map the details of our meeting (which took place in a little cafe in Soho across the street from the John Snow pub), the idea of creating a viable map via volunteer submissions seemed preposterous in the extreme. But I watched as OSM grew and grew from those humble beginnings. Now, less than six years later, that map powers Nestoria thanks to millions of man hours of contribution by individuals and organizations that recognize the power of open data.
So, why have we switched? There are four main reasons
1. The maps are equal or better
OpenStreetMap's great strength is that anyone can contibute. Since the project started over 500,000 people around the world have signed up to do just that, often going into insane levels of detail. Fixes can be added and reflected in the maps very quickly. It is a fundamentally different model than the traditional "only an expert from the government can come make the map" model. People can map whichever features are important to them (paths, pubs, buildings, etc) and escape the car centric focus of many mapping services. All of this data is then made freely available for all to use. Increasingly government agencies are realising that it makes more sense to cooperate with and benefit from this new approach to data gathering and maintenance.
Thanks to the hard work of all of these volunteers, in many places of the world, particularly the European countries we were focused on, OSM maps are of equal or better quality than any other widely available mapping service.
2. It's another visible way for us to support open data
Our service does nothing more (and nothing less!) than aggregate data from many different sources and present it in an easy to use format. We benefit greatly from open data, and as such we want to do our part (within the limited resources of a start-up) to help the open data movement. This is why we sponsor OpenStreetMap conferences and recently donated to OpenStreetMap's humanitarian efforts. This is why we feature the work of open data advocates on our blog, and also why we make our own data available via our API and other tools. We are a company that believes in open data.
3. Google introduced charging for map usage
Earlier this year Google announced that they would begin introducing limits to the use of Google maps by commercial websites. The good news is that Nestoria has grown nicely since our start in 2006. The bad news was that our size meant that we were well over the free usage limits Google announced.
In November I was contacted by a sales person from the Google Enterprise team. I had suspected we might be over the limit. Obviously no one looks forward to a new cost for their business, but I approached the talk with an open mind. Google Maps is a great service, and we had benefited greatly from it. As a businessperson, I know there's no such thing as a free lunch, and so I was open to paying Google a reasonable fee for their continued service.
Unfortunately Google's sales process was not good. Having agreed to a time for a call, the sales rep missed the appointment with no warning, instead calling me 45 minutes late. It was quickly obvious he had done no research whatsoever about our service, what we do, or even where (in which countries) we do it. He was unable to explain the basics of the new charging regime - for example, what exactly is a "map-view", telling me instead to "ask your developers". Finally he quoted a price to continue using Google Maps (just on nestoria.co.uk, one of eight countries we operate in) that would have bankrupted our company.
Google's excellence in technical services was definitely not matched by its salesmanship. The experience was disappointing, and I say this as the founder of a site that has often been featured by Google in promotional literature for our innovative use of Google maps. Having always envisioned that we would someday move to OSM, this was the nudge that pushed us over the cliff.
In the interest of fairness I should also mention that Google has been a great supporter of OSM in the past, donating funds for hardware for instance, and hopefully they will continue to be far into the future. Google remains a great supporter of opensource software with initiatives like their excellent Summer of Code initiative.
We're very thankful to Google for all the innovation they encourage and for allowing us to use their maps service for free for years. The decision to introduce charging is theirs to make and we can't argue with it. Despite this though, I have to question some of the logic they presented regarding their reasons for introducing charging now. Google claims charging is needed to ensure the long term commercial viability of the service, but is belt tightening really needed at the same time as Google announces record revenues and profits?
More importantly though I wonder if the decision really achieves the desired outcome. While us moving away from Google Maps will reduce some fractional amount of bandwidth costs for Google it also means our team of engineers will be spending our time working with, and innovating on, other geo technologies. While on the one hand Google spends a lot of effort trying to court developers, decisions like this turn them away. Especially combined with the subpar sales implementation I experienced, this seems to go completely against the ecosystem model that has enabled Google Maps to flourish, which is disappointing.
Despite all of this, we would not have been technically able to make the switch unless there was a solid set of tools and services around OSM that made the switch possible. I'll go into these in more detail in the technical part of this post, but let me here once again publicly thank all the developers around the world who have worked hard over the last few years to create the modern neogeo tool chain from scratch. Also let me explicitly thank the companies like AOL's Mapquest and Microsoft's Bing who are actively supporting OpenStreetMap.
Before I dive into the technical minutiae, let me say that all of this isn't to imply that OSM maps are perfect. No map ever is. But it all added up to a compelling sense that now was the time to switch. Nevertheless if you see problems, please tell us (via twitter or the feedback link on the page you are using). Or, better, please get involved with OSM and start contributing.
Now, in the interest of encouraging innovation (and thanking those who made this move possible) let's move on to the technical fun of HOW we actually switched map providers?
When we realized it was time for us to make the move we faced one big decision - should we use someone else's OSM tiles or should we render and serve our own? We called in an expert to advise us. OSM expert, and former Nestoria blog interviewee, Andy Allan runs OpenCycleMap, a rendering of OSM data designed specifically with the interests of cyclists in mind. He was kind enough to come to Nestoria HQ and spend some time taking us through the pros and cons of rendering our own tiles. Rendering has the advantage that you can make the map look exactly the way you want. When done well this can produce phenomenal results, a good example of this is Michal Migurski's recently announced terrain layer, but unfortunately it's no small technical undertaking, especially when we've also got a property search engine to run.
We concluded the only viable path was for us to leave the rendering and serving to experts and use someone else's OSM tileset. At this point the more astute of you may be asking why we dont just use the tiles from openstreetmap.org directly. That's unfortunately not an option due to OSM's tile usage policy. As a volunteer run organization, OSM doesn't have the technical or financial resources to serve tiles for us and the whole world. Luckily however several companies have stepped in to fill this gap - CloudMade has for several years offered an OSM tile layer for all to use. In 2010 MapQuest released a similar service. While we are longtime fans of CloudMade (we use their tiles on our Where Can I Live? service), for their global infrastrucutre and speed we decided we'd prefer to use MapQuest's OSM tiles. But now the question was how to get the OSM tiles on to our pages.
First of all, if your website is using a map I strongly advise you to consider using Mapstraction, which, as the name implies, is a javascript mapping abstraction layer. You write your code using Mapstraction methods and can then switch between anyone of 10 or more supported mapping services. Even if you plan to stay with one mapping provider this can make sense as they create new versions (as Google did several years ago when they released version 3 of their service requiring a different syntax than version 2). The good news is we've been using Mapstraction since the very beginning of Nestoria, in fact we funded the initial development - this was the topic of my 2006 meeting with Steve Coast and others. Five years later Mapstraction continues to flourish, with an active community of developers. At this point in the project (mid-Nov) Mapstraction offered two different services for loading OSM based tiles: CloudMade and OpenLayers. Cloudmade would mean using Cloudmade tiles. OpenLayers was an option, but not a technology we had much experience with. Meanwhile over the last few months I had been hearing a lot of buzz abouta new mapping library called Leaflet. Leaflet is also from the folks in the CloudMade team, but is newer (thus benefiting from all the lessons learned in building the original CloudMade map library) and is opensource. Leaflet allows the user to request any tileset, configuring it to query MapQuest was trivial. Everyone can contribute and in the six months or so since Leaflet launched almost 150 developers have forked the code. Lots of people are submitting patches, the pace of development is rapid, and the documentation is excellent.
Unfortunately, there was no Mapstraction plugin for Leaflet. And this is where the magic of an engaged and vibrant open source community once again enters our tale. The very day I pondered whether to dive in an write a Leaflet plugin, Ben Welsh submitted exactly what we needed to github for all to use (and modify). It worked almost perfectly. A few minor tweaks (and submitted patches) later we had an OSM map on Nestoria. Many thanks Ben!
So, there you have it - OSM to MapQuest to Leaflet to Mapstraction. If anyone out there can top that neogeo chain I'll be impressed. Please let us know what you think or if you have any questions.
BTW - if all this has raised your interest in all things geo (and you're in London), please do come to the next #geomob event on 16 February where I'll be giving a talk about our move away from Google Maps.
UPDATE: in the comments below paulmaunders points to this very good post where he lays out the options his firm, Fubra, considered under similar circumstances.
