I find this is a bit of a surprising action from Google. In 2005 they changed the mapping and geospatial web by providing a powerful, easy to use great API (eventually), and primarily free of charge slippy map platform. The term “GoogleMap” became synonymous with being able to pan and zoom through the entire world without any reloading of the page or poor user experience. Since then, there have been millions of sites that have used GoogleMaps to provide simple map views and location services. Assumedly this information has been of huge value to Google in understanding interest, spatial-context, and generally eyeballs to Google tools and content.

Google has also worked to monetize maps, often subtly through sponsored map markers, and other times more directly through in-map ads. Each of these decisions brought discussion and disent but it was difficult to argue with the fact that the tool was still free to use. Google has clearly put real value in content and engineering into Google Maps. The quality of geocoding, data availability and power of the API has always been extremely capable and arguably the best of breed.

Now, with a very direct pay requirement being imposed this will dramatically change the adoption of GoogleMaps. Developers will have to consider very carefully how they will afford the potential – and optimistically likely – fees that the service will require as it becomes successful.

Fortunately, there are still a few really good alternative options for developers of sites if they can’t afford the usage fees. MapQuest has really embraced the future of open by supporting and integrating OpenStreetMap into their sites. Microsoft Bing maps are very capable and there are many more – not least of which is a developer “rolling their own”.

This interesting change by Google also validates abstraction libraries such as Mapstraction. Mapstraction provides a common API where a developer can easily switch between map provider libraries without having to rewrite their code – something that would likely cost much more in the short term than paying for usage fees. On GeoCommons we use ModestMaps to be able to switch to any map data provider service.

I’m very interested to see the general developer reaction to this change.

The project originally started with just three providers: Google, Yahoo, and Microsoft; and was developed by three developers: Tom Carden, Mikel Maron, and Steve Coast. At the time, it was succint and easy – using constructs such as switch statements in a single mapstraction.js file.

Over time, as more providers were added – this became quite unwieldy. 11 case statements in any method, various callback hooks necessary, and in general quite slow to load and run for the client.

Fortunately, some very bright JavaScript experts: Rob Moran, Derek Fowler, and Adam DuVander, all congregated to help architect a complete new version that takes incorporates the current evolution of Mapstraction to provide a smaller file download and computation overhead. In addition, because each provider is now split out into an individual file such as mxn.google.core.js, it makes it easier for developers to support single providers without having to worry about any other provider or their impact on other code.

New Code Neighborhood

In order to start promoting the new API and encouraging developers to come and help out, we put the source code and tickets into a Google Code project. Although, being Subversion, you still have to submit patches to get changes accepted for now. So I personally suggest working from the Github version, which will be kept up to speed with git-svn, and then you can submit patches from here to push into the ‘official’ subversion repository.

The demos on the Mapstraction homepage do well at showing the capabilities of the library, but are difficult to maintain and users and potential contributors can’t really play with them at all. So as part of our Where2.0 workshop, I put together a Mapstraction API Sandbox, built with Google’s AJAX API Playground, and running on AppEngine.

In this sandbox, you can see more demonstrations of the API, associated code, and even modify JavaScript or HTML and create your own personal copies. For example, you can see complex marker creation, the initial version 2 demo, or the marker filtering demo.

There is definitely a lot of recent excitement around the API. We decided to use Mapstraction as the basis for our own GeoCommons Maker map integration – making it easy for developers to work within a common framework (demo). So get started contributing!

For more recent news on Mapstraction checkout the recent posts onO’Reilly Radar and ProgrammableWeb.

Please let me know if you run into any issues. There had been numerous bugs in the beta – and I think most of these have been ironed out. I also updated the KML to use KML 2.2 and some simple atom links to your blog and post authors.

Also, the geopress_map function has some nice functionality for being embeddeable in Archive, Category, and Search pages. Right now the function signature is a little long, but if you want to have all your markers for a category or search show up in the map, you use the following in your template (assuming you want your map to be (200px high, 400px wide)

This will embed the map with unlimited (-1) locations from the category (unless you have lots of geo-posts in a single view). Check out my conference blog post archive.

There have been numerous requests for per-item and categorical styling. This shouldn’t be too hard to add. And also per-post zoom and map types. Also I will be updated GeoPress/MovableType to converge on the same feature-set.

Also – if you have any updates/patches/suggestions for GeoPress – chime in (and contribute code

There are several easy ways to fix this. The first was to look at the Ditu tiles, and confirm they are the same as Google’s nominal tiling scheme. Which means you can add the China Street tiles as a simple GTileLayerOverlay with Google Maps standard satellite view underneath. This was incredibly easy with Mapstraction and I put up a demo here.

For bonus points I even added a Mapufacture syndicated feed of Erik’s venues for LocWeb2008 and nearby Wikipedia articles from Geonames.

The other way

The terms of how mixing Google’s various tiles together isn’t clear. So the other way to address his issue is to use the freely available data.

Namely, OpenStreetMap for roads, OpenAerialMap or other remote imagery, and run in OpenLayers. Here is the same map done with open data and open source. The resolution or completeness isn’t there yet, but you can see where it’s going and the ability to be use the information as you want is very appealing.

You can see a demo of OpenLayers here or grab the latest revision here (r163 as of this posting).

This effort was headed up by Henri Bergius (aka Bergie), of Midgard fame, and now Mapstraction-OpenLayers will be supported in the Midgard CMS. Read more on Bergie’s blog.

In addition, by default the Mapstraction-OpenLayers creation uses the OpenStreetMap tiles, therefore no longer requiring a Google Maps API key just to use OSM in Mapstraction.

Why wrap one wrapper in another?

At conferences and get togethers, the devs and users of Mapstraction and OpenLayers frequently ask the question “What’s the difference between Mapstraction and OpenLayers?”

The primary distinction between the libraries is a difference in objective. Mapstraction seeks to provide a simple wrapper to meet the primary needs of a mapping user. The purpose being to make it easy for a user to read a single API and then easily switch to any of the major providers. By contrast, OpenLayers provides a very powerful, but potentially complex, interface that allows for bringing in content from OGC services, data feeds, overlays, and tile servers.

With Mapstraction generally targeting the ‘lowest-common denominator’ of all the API’s there isn’t built-in support for the additional capabilities of OpenLayers for layers, drawing, and services. However, Mapstraction goes provide a simple mechanism for gaining access to the underlying mapping provider such that a developer can utilize Mapstraction for the 80% of their development, and then access the remaining 20% provider specific capabilities directly.

All you need to do is call getMap() on the Mapstraction object to get the underlying OpenLayers object and go to town.

With this new support, it now brings Mapstraction up to 9 supported map interfaces (Yahoo, Google, Microsoft, Map24, MultiMap, MapQuest, FreeEarth, OpenLayers, OpenStreetMap). If you are a map provider and would like to find out how to be the 10th provider feel free to email the dev team – mapstraction@lists.mapstraction.com.