When the Earth API launched back in May 2008, there was a simultaneous addition to the Maps API that allowed creating an 'Earth' map type with just a single line of code:

Figure 1: Old version

This was really the first time that the 2D world of Google Maps and the 3D world of Google Earth came together. Users could navigate content publishers' geographic content in 2D or 3D, whichever they desired.

However, there were a few limitations with G_SATELLITE_3D_MAP. For example, only Maps markers and polylines were synchronized in 2D and 3D. Other overlay types were not kept in sync. Also, the transition from 2D and 3D wasn't as transparent to the user as it could've been. See Figure 1 to the right for an artist's depiction of the feature set.

Today, we're excited to announce a completely rewritten and 'beefed up' G_SATELLITE_3D_MAP (see Figure 2), available now in the latest experimental version of the Maps API (currently 2.160). While the usage is the same (simply use the line of code above), the overlay/feature synchronization is much more extensive, the 2D/3D transitioning is seamless, and the overall Maps/Earth integration is much stronger.

Most common Maps API overlays are now supported: markers, polylines, polygons, ground overlays, screen overlays, and even GGeoXml objects are automatically mirrored in the Google Earth Plugin. In fact, GGeoXml works in an especially powerful way: although Maps may not display all KML from a GGeoXml (i.e. 3D models), the Earth Plugin will show all the content, in all its 3D glory.

If you're as psyched as I am about the new features and want to give them a go, check out these demos and the short screencast below:

To enable the new Maps/Earth integration on your site, simply load the experimental Maps API version using:

google.load('maps', '2.160');

and add the G_SATELLITE_3D_MAP map type. When Maps API v2.160 or later becomes version '2', the new Maps/Earth integration will replace the old version, which will then only be available by hard coding to version 2.159 or earlier in the google.load statement.

Lastly, if you have any trouble with the new integration code, please post in the Maps API or Earth API developer forums. Also see the Earth API notify group announcement for more details on this release.

Since our last major release of the JavaScript Maps API three years ago we've been delivering feature requests that all of you have been asking for month over month. With over 150,000 active websites implementing it, the Maps API has become one of the most popular and trusted developer tools on the web. We're in the process of giving the Maps API a major facelift and today we're providing you a look at V3 in our Google Code Labs.

The primary motivation behind this new version was speed, especially for rendering maps on mobile browsers. Last year, several of us starting thinking about the possibility of getting the JavaScript Maps API to work on mobile devices. With the advent of powerful, fully functional browsers on devices such as the iPhone and the Android-based G1, why couldn't we bring the flexibility and reach of modern web development to people who wanted to write maps mashups for mobile phones? While we've been able to get the existing v2 API working on mobile browsers, we found we were constrained when trying to reduce latency and we needed a new approach. And thus was born the idea for the next revision of the Maps API.

We wanted to get this in your hands as soon as possible, so we've intentionally released it early, and with a basic set of features. We're releasing it in Labs because it's not fully baked yet; we want to get your feedback on the new design and what you'd like to see in future revisions now that we have a chance for a fresh start. Yes, this does mean that you'll have to rewrite your existing mashup code if you want to take advantage of v3, but we think that speed is very important to a great user experience.

What's changed in v3? Besides the substantial improvements in speed, a few other things that you'll notice in the initial release:

  • iPhone Safari mobile and Chrome added to our supported browsers. Your mashups will also work on Android-based phones with the recent update, but you may notice some issues, like the "View/Save Image" dialog showing unexpectedly. We're working with the Android team to fix this and improve the end user's experience in interacting with the map. We could've waited until it's perfect, but we really wanted to get an early release in your hands and start getting feedback while we fix up a few remaining issues.
  • No keys required. You can now copy 'n paste code easily or embed in RSS readers, for example, without getting key errors.
  • MVC-based architecture. This allowed us to significantly reduce the size of our initial JavaScript download. We found it to be simple and powerful.
  • Default UI is enabled automatically. We'll provide default UI controls and behavior (and we'll update them) so your mashup can keep up with the latest and greatest changes we make to Google Maps. Of course, if you've got customized controls you're happy with, you can disable the default UI updates.
  • Namespaces. Everything is always in the google.maps.* namespace and there is no "G" prefixed variables in the global scope.
  • Geocoding API has been overhauled based on the feedback we've received with the existing implementation over the past three years.
Check out the reference and documentation for more details.

What does the API look like? Here's a quick, complete example that you can grab to render a map. It's even set up to render a full-screen interactive map on the iPhone and Android browsers.

<meta name="viewport" content="initial-scale=1.0, user-scalable=no">
<script type="text/javascript" src=""></script>
<script type="text/javascript">
  function initialize() {
    var latlng = new google.maps.LatLng(-34.397, 150.644);
    var myOptions = {
      zoom: 8,
      center: latlng,
      mapTypeId: google.maps.MapTypeId.ROADMAP
    var map = new google.maps.Map(document.getElementById("map_canvas"), myOptions);
<body onload="initialize()">
 <div id="map_canvas" style="width:100%; height:100%">

We've set up a new group for you to provide feedback. Also, the terms have been updated to remind you that versions we release as "experimental" or in Labs may not have the same level of support as ones that are already out of Labs. This means that we'll continue to support the current v2 API well after v3 matures and graduates from Labs. In the meantime, we're looking forward to adding a lot more functionality to this new release so please send us your feedback!

From simple GPS tracks to rich KML documents to collaborative maps, the geo developer community has continually redefined and enriched the geoweb, giving rise to better canvases for geographic participatory culture. Notably, the Google Maps API and other tools have led to the creation of more dynamic and interactive content, putting new demands on the ways in which geodata is stored, accessed, indexed and rendered. To address these challenges, today we've released the Google Maps Data API in Labs, a Google Data API for viewing, storing and updating geodata on the web. The Google Maps Data API is built on the following principles:
  • Storage should scale simply with usage. You shouldn't have to worry about maintaining a data store to build a cool Google Maps mashup. Focus on building the client, and we'll provide hosting and bandwidth for free.
  • Geodata should be accessible across platforms and devices. With many client libraries and clients, accessing stored geodata should be possible from anywhere, whether it's on the web, a mobile phone, a 3D application, or even a command line.
  • Realtime geodata requires realtime indexing. For a lot of geographic content, freshness is important. Geodata from the Google Maps Data API can be instantly indexed and made searchable in Google Maps.
  • Rendering geodata is better and faster with the right tools. Through JavaScript, Flash, 3D, static images and more, we'll continue to provide better ways to render your content to meet platform and latency demands.
Much like KML, the Google Maps Data API is based on a data model of maps (collections) and features (placemarks, lines and shapes). Since it uses this familiar model, this new API makes it easy to build geo applications for specific activities like planning and sharing trips, collaboratively mapping hiking trails, or saving a list of favorite restaurants. Also, for any map that is associated with a Google Account, that map is immediately available to view and edit in Google My Maps. Some examples of applications which already use the Google Maps Data API:
  • My Maps Editor for Android allows users to create and edit personalized maps from an Android mobile phone. Integration with the phone's location and camera makes it easy to document a trip with photos and text on a map.
  • ConnectorLocal is a service that informs users about the places where they live, work and visit by gathering trusted hyperlocal information from many sources. Using the Google Maps Data API, ConnectorLocal makes it easy for users to import and export their geodata in and out of Google Maps, and also improves their ability to have data indexed in Google Maps for searching.
  • My Tracks enables Android mobile phone users to record GPS tracks and view live statistics while jogging, biking, or participating in other outdoor activities. Stored with Google Maps Data API, these tracks can be accessed, edited and shared using the My Maps feature in Google Maps.
  • Platial, a social mapping service for people and places, uses the Google Maps API to host geodata for community maps on both Platial and Frappr.
If you're a developer, we encourage you to get started with the Google Maps Data API immediately with our HTTP protocol guide. Additionally, the team at We-Create (the company behind ConnectorLocal) has released their Webready library for PHP developers, built on top of the Zend Framework. Of course, this release in Labs is only the beginning -- in the future, we'll continue to add new functions and libraries to make the API even better. In the meantime, we hope you'll get an early start in developing new applications and pushing the boundaries of the API. Be sure to stop by our group to ask questions, give us feedback, and let us know what you've made!


Today we are excited to announce the Maps Ad Unit, a new feature that will enable geo developers to generate advertising revenue from their Google Maps API implementations.

The Maps Ad Unit joins the recently updated GoogleBar as part of the AdSense for Maps portfolio. This new opt-in Maps API feature overlays AdSense ads over an embedded Google map on your site. The ads are targeted to the map's view and update as the user moves around the map. To generate revenue after adding the Maps Ad Unit to your Maps API implementation, you need to link it to an AdSense account enabled with AdSense for Content.

To see the Maps Ad Unit in action, take a look at Acme Mapper and ZipMaps who have both added it to their Maps API implementations.

Adding the Maps Ad Unit to your site is easy. You simply need to create a GAdsManager of style 'adunit'. You will also need to link this Maps Ad Unit to an AdSense account. If you don't yet have an AdSense account, sign up for an account. Once you have done so (or if you already have an account) make sure you've also enabled the account with AdSense for Content.

Once you have an AdSense for Content account, you will have received an AdSense for Content (AFC) publisher ID. Specify this publisher ID in the GAdsManager constructor (see code snippets below). Optionally, you may also specify an AdSense for Content channel if you've set that up. (More information on advertising channels is located here.)

The snippet below creates a Maps Ad Unit with the given publisher ID and AdSense for Content channel. We assume that there is a map object that has already been created.

var publisher_id = "pub-1234123412341234"; // Replace 1234123412341234 with your Google AdSense publisher id.

adsManagerOptions = {
maxAdsOnMap : 2,
style: 'adunit',
channel: '12345678' // This field is optional - replace 12345678 with a channel number that you created for GooYAMLgle AdSense tracking

adsManager = new GAdsManager(map, publisher_id, adsManagerOptions);

To alter the position of the Map Ad Unit, modify the GAdsManager's position property by specifying an alternative GControlPosition as shown below.

var publisher_id = "pub-1234123412341234"; // Replace 1234123412341234 with your Google AdSense client id.
var adPos = new GControlPosition(G_ANCHOR_BOTTOM_RIGHT, new GSize(7, 20)); // Set the anchor position and GSize offset to your desired values.

adsManagerOptions = {
maxAdsOnMap : 2,
style: 'adunit',
channel: '12345678', // This field is optional - replace 12345678 with a channel number that you created for Google AdSense tracking
position: adPos

adsManager = new GAdsManager(map, publisher_id, adsManagerOptions);

If you want a smaller ad unit (for example, if you have a small map), you can get one by setting maxAdsOnMap to 1 in your adsManagerOptions.

We hope you consider implementing this new tool to generate revenue from your Google Maps API implementation! More information can be found within the Google Maps API docs and please be sure to provide feedback within the Maps API Google Group.

That's right, we're on Twitter. Here are some Google accounts you might want to follow:

We'll post about interesting new features, cool sites, and anything we think is of general interest to the Geo Developer community. Also some of us who post here are also on twitter and you might want to follow us as well. These are unofficial of course, but may be of interest to you:

And don't forget to register for Google I/O, it's coming up fast.


Today, we are pleased to announce the Google public location badge. In its simplest form, the badge is an easy way for Google Latitude users to share their current location to the world, whether it be on their website or blog. This works with a simple <iframe> snippet that users can just embed in their page. We have tried to make this process as easy as possible, but we realize there is an entirely different set of people (you guys, the developers!) that want to do more interesting things with their location.

For those users, we are also pleased to announce that we're releasing KML and JSON feeds of the location data underlying the public location badge. You can take your personal KML feed and open it in Google Earth, load it in Google Maps, or put it on your own website with the Google Maps API. Or you can gain access to the raw latitude, longitude and accuracy from your Google public location badge with the GeoJSON format seen below. As an added bonus, both the JSON and KML feeds allow you to fetch the locations of multiple users — you only need to change the user parameter to use comma separated identifiers instead of a single one. These two feeds put location information back in the hands of our users, and we're excited to see the kinds of applications developers will build. If you make something cool, be sure to stop by and show us at one of the upcoming geo conferences!

            "reverseGeocode":"San Francisco, CA, USA",

Note: These feeds are read only; there is currently no API to let you modify your location.