Thematic Mapping Web Interface Thematic Mapping Engine (TME) lets you create thematic or statistical maps on-the-fly in the web browser. It then returns a KMZ file which you can view directly with the Google Earth browser plugin, or you can download to view in the regular Google Earth.

TME supports various thematic mapping techniques like choropleth maps, proportional symbol maps and animated maps. The goal of this project has been to explore the pros and cons of doing thematic mapping with KML. You can read about the various techniques on the thematic mapping blog

The Thematic Mapping Engine is also a good example of what you can achieve with open source tools and datasets in the public domain:

So far, you can only create thematic maps with statistics from UNdata ( The possibility to add your own data will be supported in a future release.

Two examples (all statistics from UNdata):

Infant mortality rate in 2005 visualized as a prism map (extruded polygons).

Infant Mortality 2005

Mobile phone subscribers in 2004 visualised with proportional 3D objects (mobile phone model downloaded from 3D Warehouse).

Mobile Phone Map


Our Maps API team strives each day to develop features to help developers build the next generation of great maps mashups. One of the requests that we've received from our developer community is to build features that will help convert map traffic into revenue for their site. To that end, we've been working hard on improving the program that allows Maps API sites to choose to display Local Business Ads on their map as part of the AdSense for Content program. As with all Google ads products, we feel that success depends on providing ads that actually improve the user experience, while at the same time allowing businesses to reach their target audience.

Although we've had an ads program in the API for some time, this week, we are pleased to announce some key improvements to that system:

  • An improved user and advertiser experience. Ads now display "flat on the map," and we've introduced new more informative category icons. We've also built a system to "nudge" ads so they do not obscure key elements on the map. Check out an example of the new look and feel.
  • Improved coverage. We introduced GAdsManager last year, but didn't show many ads. Now, our coverage is much improved without impacting relevance. We also now show ads for all countries where the Local Business Ad format is supported. (For your ad to show up on API sites, you need to opt-in to the "Content Network.")
  • Continuous ad serving. You may have noticed that ads would not be refreshed when users panned the map, so your highly interactive Maps API site wouldn't be able to take advantage of the program. We've changed this. Ads are now loaded whenever the user moves the viewport to a new location.

We hope that these improvements will help you generate some revenue from your Maps API site and continue to make it better.

You can read more details about these changes on the Maps API Developer Forum or sign up for an AdSense account to get started.

NOTE: To be clear, this program has always been and remains completely opt-in for API users. You are under no obligation to display ads in order to use the Maps API. For more details see the Maps API Terms of Service.


Sometimes, we fulfill feature requests that we never realized we had, and then wonder why it took us so long to discover that hidden desire in our heart. GMapOptions.backgroundColor, introduced in 2.119, is one of those features. It's never been asked for and it's a trivial code change, but it's damn nifty. By setting it, you can change the background color of the tiles that appears before tiles load, and on the north/south edges of the world at the low zoom levels. You can use it to make your map blend into the rest of the page, make your tiles blend in better when loading, or just to be obnoxious (hot pink tiles, anyone?).

The example below shows setting both the backgroundColor of the map and the page to our beautiful ocean blue. If that piques your interest, check out this demo that lets you try out any color with any of our default map types (like #000000 with G_SKY_MAP_TYPES).


In the past, Pamela's blogged about ways to create map mashups out of published spreadsheets using the Spreadsheets GData API. Well now we have a more integrated approach using spreadsheets gadgets. For the uninitiated, here's a spreadsheet gadget I'm using to plan my road trip:

It's reading data from a simple spreadsheet and displaying it here. Any changes a collaborator makes to the underlying spreadsheet will be reflected on this page. So what's new about this approach? Spreadsheet gadgets can be embedded directly in spreadsheets, like the heat map in this sheet, or even on on their own sheet. And spreadsheet gadgets can be accessed from within Google Docs Spreadsheet's built-in gadget picker, so they're very easy for everyday folk to discover and use.

For more info, check out our post on the Google Gadgets API blog.


We at Lonely Planet are thrilled to share some experiences from our latest project,, a location-based world travel guide for mobile devices enabled by mashing the Google Static Maps API, the Google HTTP geocoder, and our new Content API. We’ve been publishing travel content for decades, (in case you’re not familiar, we’re the guides with blue spines in your local bookshop), but we’re excited because this is the first time we’ve been able to deliver our information in a mobile and spatially relevant way, allowing us to ask questions like “what should I explore today?” and “what’s around me worth exploring?”

Of course, to answer these questions, we need to know the lat/lng of both our user and the points of interest (POIs) around them. POIs aren't a problem, as our authors plot these on a map during their on-the-ground research. User locations are trickier. As our mobile site is a browser-based service, we don't (yet!) have the luxury of APIs for grabbing precise locations via GPS, wifi, or cell tower triangulation.

So, for the moment we’ve asked our users to self-select their location by entering it into a form field. Because typing on typical mobile keypad is painful, we wanted to save thumbs and offload parsing to a geocoder which could deal with the ambiguity of short location descriptions, various zip/post code formats etc. Enter Google's geocoder (HTTP flavour – no JavaScript available on most mobile browsers!). We can proxy this API from our server and allow users to enter a wide variety of location descriptors, from zip codes (90210) to tube stations (holborn) to street names (oxford street) to suburbs (footscray) and the geocoder will decipher it, geocode it, and return either a lat/lng or a list of options for disambiguation.

Once we know the user's lat/lng, we can assess which content is most spatially relevant to them by calculating proximity to POIs in our database. To this end, we use the POI proximity method from our Content API, in which we pass in the user's location and a radius in kilometers, returning POIs within range in their order to proximity. This service uses the Haversine formula, a tip we picked up from Pamela a couple of months ago.

Once we’ve got the POIs, the next step is plotting them (and the user’s location) on a map. Since ours is an application for a baseline of devices with limited capabilities, we don't have the luxury of Flash, AJAX, or JavaScript. Enter the Google Static Maps API. By passing in our geocodes, a set of parameters for labeling markers, and a map height / width (calculated per device by querying screen sizes from WURFL) the Static Maps API produces for us an image displaying a marker for the user's location and for each of the POIs.

To help our users explore further, we augmented the map with a lightweight navigation bar (north, south, east, west, zoom in, zoom out) so that users can pan around the map to surrounding areas. This little navigation bar uses a bit of code we thought we’d share:

Let's say we have a static map of width w pixels, height h pixels, centered at (lat,lng) and zoom level z.

$map_link = "{$key}&size={$w}x{$h}¢er={$lat},{$lng}&zoom={$z}";

Then, we can generate north, south, east, and west 'panning' links as follows (this example assumes the existence of a mercator projection class with standard xToLng, yToLat, latToY, lngToX routines):

// a mercator object
$mercator = new mercator();

// we'll pan 1/2 the map height / width in each go
// y coordinate of center lat
$y = $mercator->latToY($lat);

// subtract (north) or add (south) half the height, then turn back into a latitude
$north = $mercator->yToLat($y - $h/2, $z);
$south = $mercator->yToLat($y + $h/2, $z);

// x coordinate of center lng
$x = $mercator->lngToX($lng);

// subtract (west) or add (east) half the width, then turn back into a longitude
$east = $mercator->xToLng($x + $w/2, $z);
$west = $mercator->xToLng($x - $w/2, $z);

So that our north, south, east, west links are:

$north = "{$key}&size={$w}x{$h}¢er={$north},{$lng}&zoom={$z}";
$south = "{$key}&size={$w}x{$h}¢er={$south},{$lng}&zoom={$z}";
$east = "{$key}&size={$w}x{$h}¢er={$lat},{$east}&zoom={$z}";
$west = "{$key}&size={$w}x{$h}¢er={$lat},{$west}&zoom={$z}";

To see the site in action, go to in your mobile browser, select the "What's around me?" feature and enter your location or a place you're planning to travel. Make sure to send us feedback - as this is our first location-based service there are plenty of things we're learning as we go. At the moment we're experimenting with additional ways of enhancing the accuracy of the user's location - like everyone else, we're excited about the location capabilities available on the Nokia, Android and iPhone platforms and are thinking through services which could make best use of those.

As you've seen from this post, our mobile site is really just a mash-up of our own Lonely Planet Content API and the Google geo API's. The Content API is available through our newly launched developer program, so if you head over to and join our developer community, you can build the site yourself! The only thing we ask (actually, 2 things) is that you remain non-commercial and that you don’t openly compete with us. So, sign up! We’d love to see what you can create using our content, Google’s geo services, and any other API you choose (YouTube? Flickr? Twitter? Others?).

Ken Hoetmer – Digital Mapping Manager
Chris Boden - Head of Wireless & Innovation
Kris Nyunt – Senior Engineer, Wireless & Innovation
Follow us on Twitter @ lplabs

Hi. This is Craig Johnston and Brian Hull of Sudjam, LLC, the company hosting and developing the new online presence for the band Nine Inch Nails. This guest blog entry will cover how we went about creating a Google Earth representation of downloads for NIN's latest album, the slip. We started out with about the first 1.4 million downloads logged (ironically just a subset of the total downloads), and wanted to end up with a dramatic representation of the data set, suitable for the exacting stylistic demands of NIN. Something along these lines:
We first needed to generate lat/longs, which we did by running the IP addresses logged for each download through the GeoIP® database. The process yielded a high precision set of locations, yet too many to represent as a single data set in Google Earth (we tried). We solved this by grouping the data into histogram-like bins, which we accomplished simply by dropping the precision of the lat/longs when we retrieved them. This took us down to a more acceptable ~40,000 Placemarks, each with a total number of downloads. The next step was to represent the data in a dramatic fashion... or in Google Earth terms, extruding a polygon into space in proportion to the total downloads. We accomplished this easily enough, but then also wanted the download totals for each column to be clickable. We used a solution we found in Jason Birch's blog which involved embedding a point with the polygon section of the Placemark and wrapping them in a MultiGeometry tag, which ended up looking like this:
   <description>17875 downloads.</description>
To avoid the icon clutter, we substituted a 1x1-pixel transparent PNG icon placed in the center of the polygon's base. Finally, we added in a watermark logo and some instructional text using <ScreenOverlay>, and it was complete. The final result is available for download from the NIN website. Fans of the band can also follow its upcoming tour directly in Google Earth -- their performance page lets you subscribe to tour updates as a KML file, with all the tour stops in sequence and time-tagged. Because the tour data is implemented behind a <NetworkLink>, it's always up-to-date, even when users save it to their My Places in Google Earth. We had a lot of fun doing these visualizations, and are grateful to have a client like Trent Reznor who understands and appreciates a cool little side project such as this enough to not only promote it but to put his name behind it. And thanks to Topspin Media for providing the original idea.


First, let's go over a few new features for static maps:

  • We support larger maps, up to 640X640 pixels.
  • We use a more compact Google logo for maps less than 100 pixels wide.
  • We support the ability to specify a map viewport by sending in a span and center (instead of zoom and center).

More info in the documentation.

Now, for the good stuff. I've just spent the last 3 hours surfing the web, looking for example sites using our Static Maps API, and I'll admit that I had no idea developers were using static maps in so many different ways. Below, I've summarized the various techniques and linked to example sites for each. I urge you to 1) visit each of them, and 2) decide your favorite technique and implement it on your own site.

  1. Include a static map on the page, go to a large interactive map when clicked. This is a good technique for those of you who'd like to cater to map-centric users versus text-centric users.

    Example sites: (pictured above), TripAdvisor, OpenRice, Qype, HotelTravel, and ADN

  2. Include a static map on the page, and replace that with an interactive map after some user interaction. This is a good technique if you'd like interactive maps on every page, but are worried about them making the page load too slowly for users on a slow connection.

    Example sites: Yelp, GumTree, and Geocaching (pictured above - For a good laugh, check out the difference between their map when you're logged in versus when you're not)

  3. Include a static map on the page that's centered on the geographical region that a page is about. This is a good technique if you just want a quick reference map for the user, and if you don't have multiple points to display.

    Example sites: Wedding Mapper Venues (pictured above), Adriagate, citybeat, and (this one links to a URL for the displayed location, which is a good variation on this technique and should be minimal extra work for the developer.)

  4. Use static maps inside a gadget. This is a great technique for all gadgets, since often times users will have multiple gadgets on the same page (on iGoogle or their own sites). Each gadget should ideally take as little time as possible to load, so that the parent page loads quickly.
    Example Sites: Geo IP Locator Gadget (pictured above), and Google Map Search Gadget

  5. Use static maps for mobile implementations of map sites. This is a no-brainer, as Javascript isn't supported across most/all mobile browsers (and loading all the interactive map resources can be a bit much over a mobile connection).
    Example Sites: Mobile YellowBot, Mobile Lonely Planet (pictured above), OrbitzTLC Traveler Update, and Non-JS Local Search (this demo is running on Google App Engine, using code written by a Googler and open sourced here).