Google Geo Developers Blog

Google I/O 2009: Geo Round-Up

2009-06-24T21:28:00.000-07:00

At Google I/O 2009, we had the opportunity to meet many of our favorite developers in the Sandbox and Office Hours, and deliver several advanced talks on geo topics. Check out the description of those sessions below (originally posted on the Google Code blog), or jump straight to the embedded player and watch them yourself.

Mano Marks and Pamela Fox started with a grab bag session covering the vast spectrum of Geo APIs, discussing touring and HTML 5 in KML, the Sketchup Ruby API (with an awesome physics demo), driving directions (did you know you can solve the Traveling Salesman Problem in Javascript?), desktop AIR applications, reverse geocoding, user location, and monetization using the Maps Ad Unit and GoogleBar. Pamela finished by sneak previewing an upcoming feature in the Flash API: 3d perspective view.

In the session on performance tips for Maps API mashups, Marcelo Camelo announced Google Maps API v3, a latency-oriented rewrite of our popular JS Maps API. Also see Susannah Raub's more in-depth talk about Maps API v3. Then Pamela gave advice on how to load many markers (by using a lightweight marker class, clustering, or rendering a clickable tile layer) and on how to load many polys (by using a lightweight poly class, simplifying, encoding, or rendering tiles). Sascha Aickin, an engineer at Redfin, showed how they were able to display 500 housing results on their real estate search site by creating the "SuperMarker" class.

Mano and Keith presented various ways of hosting geo data on Google infrastructure: Google Base API, Google App Engine, and the just-released Google Maps data API. Jeffrey Sambells showed how ConnectorLocal used the API (and their own custom PHP wrapper) for storing user data.

On the same day as announcing better integration between the Google Earth and Google Maps JS APIs, Roman Nurik presented on advanced Earth API topics, and released a utility library for making that advanced stuff simple.

Posted by Pamela Fox, Developer Relations

Travellr: Behind the Scenes of our Region-Based Clusters

2009-06-22T17:26:00.000-07:00

Recently, there has been a lot of interest in clustering algorithms. The client-side grid-based MarkerClusterer was released in the open source library this year, and various server-side algorithms were discussed in the Performance Tips I/O talk. We've invited the Travellr development team to give us insight on their unique regional clustering technique.

Travellr is a location aware answers service where people can ask travel-related questions about anywhere in the world. One of its features is a map-based interface to questions on the site using Google Maps.

Figure 1. An example of the Travellr Map, showing question markers for Australia.

Clustering for usability

We learned that the best way to display markers without cluttering our map was to cluster our questions depending on how far you zoom in. If the user was looking at a map of the continents, we would cluster our questions into a marker for each continent. If the user zoomed-in to France we would then cluster our questions into a marker for each region or city that had questions. By clustering our data into cities, regions/states, countries, and continents, we could display relevant markers on the map depending on what zoom level the user was looking at.

Optimizing for Clustering

Our next challenge was how to extract clustered data from our database without causing excessive server load. Every time the user pans and zooms on the map, we need to query and fetch new clustered data in order to display the markers on the map. We also might have to limit the data if the user has selected a tag, as we're only interested in a questions related to a topic (ie: "surfing"). To execute this in real-time would be painstakingly slow, as you would need to to cluster thousands of questions in thousands of locations with hundreds of tags on the fly. The answer? Pre-cluster your data of course!

Step 1. Structure your location data

When a question is asked about a city on Travellr, we also know its region/state, country and continent. We store more than 55,000 location points as a hierarchy, with each location "owning" its descendent nodes (and all of their data). Our locations are stored in a Modified Preorder Tree (also called Nested Sets). Modified Preorder Trees are a popular method of storing hierarchical data in a flat database table, having a focus on efficient data retrieval, and easy handling of sub trees. For each location we also keep a record of its depth within the tree, its location type (continent, country, region/state, or city), and its co-ordinates (retrieved using the Google Maps geocoder).

Step 2. Aggregate your data

We calculate aggregate data for every branch of our locations tree ahead of time. By storing aggregate data for cities, regions/states, countries, and continents, we provide an extremely fast and inexpensive method to query our locations database for any information regarding questions asked about a particular location. This data is updated every few minutes by a server-side task.

Our aggregations include:

Total question count for a location
Most popular tags for that location
Number of questions associated with each of those tags.

How we query our structured, aggregate data on the map

Whenever the user zooms or pans the map we fire off a query to our (unpublished ;) API with the tags they are searching for, the current zoom level, and the edge co-ordinates of the map's bounding box. Based on the zoom level (Figure 2) we work out whether we want to display markers for continents, countries, states, or cities. We then send back the data for these markers and display them on the map.

Figure 2. Clustering at different zoom levels (blue = continents, countries, pink = states, cities)

Everyone Wins

So what is the result of structuring and aggregating our data in such a way? It means that we have nicely organized, pre-clustered data that can be read from cheaply and easily. This allows us to provide a super-fast map interface for Travellr that puts minimal load on our infrastructure. Everyone is happy!

Comments or Questions?

We'd love to hear from you if you have any questions on how we did things, or suggestions or comments about Travellr's map. This article was written by Travellr's performance and scalability expert Michael Shaw (from Insight4) and our client-side scripting aficionado Jaidev Soin.

You can visit Travellr at www.travellr.com, or follow us on Twitter at twitter.com/travellr.

How low can you go? Introducing getMaxZoomAtLatLng

2009-06-16T20:12:00.000-07:00

When you're showing satellite imagery with our Maps API, it's often the case that you want to show the most detailed imagery available. But it's always been tricky figuring out the best zoom level for a particular location. If you don't zoom in far enough, your users won't immediately get the most detailed image available. If you zoom in too far, you might get the dreaded message "We are sorry, but we don't have imagery at this zoom level for this region", and no imagery at all.

What if there were a way to know programatically what the maximum zoom level was for any point in the world? Fortunately, now there is.

It's not easy to solve this problem naively; the world is a big place. At zoom level 22, there are 4 to the power of 22 potential satellite tiles -that's over 17.5 trillion. The zoom level for satellite imagery that exists varies wildly all over the world. Sydney's Bondi Beach has imagery right up to zoom level 22, whereas the centre of the Pacific Ocean only goes up to zoom level 9. (I make no accusations about whether this means the Google Maps team prefers to look at tanned, sunbathing Aussies).

But with a good search algorithm, and data based on the most frequently viewed areas of the earth, we've been able to make a search for the existence of imagery very efficient, and we are now exposing this functionality to our API developers.

The new solution is an asynchronous function which is part of the GMapType class: getMaxZoomAtLatLng. The function takes a GLatLng and returns the maximum zoom level at which imagery exists. Because the function requires a call to Google's servers (much like GClientGeocoder.getLocations()), you must also provide a callback parameter, which is a function which will deal with the response.

As an example, here's a function which will set the center of the given GMap2 object to the maximum zoom level at the given GLatLng:

 
function setMaxZoomCenter(map, latlng) {
  map.getCurrentMapType().getMaxZoomAtLatLng(latlng, function(response) {
    if (response && response['status'] == G_GEO_SUCCESS) {
      map.setCenter(latlng, response['zoom']);
    }
  });
}

As you can see, the response object contains a status code, and, if the response was successful, a zoom field containing the maximum zoom at that point.

Click on the map below, and it will zoom to the highest zoom level available at the point at which you clicked.

Note that this function is only implemented for satellite imagery, and not roadmaps, whose zoom levels don't vary nearly as much. It works for both the G_SATELLITE_MAP and G_HYBRID_MAP map types. The full reference is available here.

We hope this function makes developing with satellite imagery a simpler, easier and fuller experience. Please provide any feedback in the Maps API Google Group.

Posted by Jez Fletcher, Maps API team

Announcing the Google Qualified JS Maps Developer program

2009-06-05T13:00:00.000-07:00

Last week at Google I/O we released the Google Maps API (JavaScript version) addition to the Developer Qualification program. Designed for professionals who currently develop or want to develop applications based on Google and Google-sponsored Open Source APIs, the Google Qualified Developer program will help promote developers to the Google community, provide credibility, and leverage the wisdom of the masses in rating and recognizing best in class developers. In this program, we assess developers in four areas, each of which provides a score towards an overall total required for qualification. Developers must maintain a minimum number of points to remain qualified within the program. Points are awarded for examples of development work, community participation, professional references, and scores on examinations.

With the addition of the Google Maps API to the available qualifications, the program landing pages and registration have been moved to the Google Code site at http://code.google.com/qualify. The new landing pages provide information on the program and available APIs, details about qualification requirements, answers to frequently asked questions, and an opportunity to apply as a candidate in the qualification program.

We've also recently partnered with 3rd party training vendors who can help you get ready to qualify. The Developer Qualification program provides a mechanism by which Google can evaluate and promote the best developers in the community, but does not provide training in preparation for qualification. With the success of the program there exists a business opportunity for 3rd party training vendors to develop and deliver this training. In order to stimulate the growth of this ecosystem, several vendors have been identified and are working closely with Google to develop initial training efforts for the Google Maps API qualification.

To read more about the program, take a look at our site. We look forward to expanding our API support and growing the Developer Qualification program. Please reach out to us with questions and feedback at devqual-proctors@google.com.

Posted by Shannon Madison, on behalf of the Developer Qualification team

Hey Maps API and Earth API developers, we just beefed up G_SATELLITE_3D_MAP!

2009-05-29T11:00:00.000-07:00

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:

map.addMapType(G_SATELLITE_3D_MAP);

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.

Posted by Roman Nurik, Google Geo APIs Team

Announcing Google Maps API v3

2009-05-27T02:20:00.000-07:00

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.


<html>
<head>
<meta name="viewport" content="initial-scale=1.0, user-scalable=no">
<script type="text/javascript" src="http://maps.google.com/maps/api/js?sensor=false"></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);
  }
</script>
</head>
<body onload="initialize()">
 <div id="map_canvas" style="width:100%; height:100%">
</body>
</html>

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!

Posted by Mickey Kataria, Product Manager

Introducing the Google Maps Data API in Labs

2009-05-20T11:00:00.000-07:00

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!

Posted by Taj Campbell, Google Maps Data API team

Earn revenue from your mashup with the Maps Ad Unit

2009-05-20T00:35:00.000-07:00

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);
adsManager.enable();

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);
adsManager.enable();

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.

By Nick Verne, Google Maps API Team

Follow Google Geo on Twitter

2009-05-12T12:02:00.000-07:00

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.

Posted by Mano Marks, Geo APIs team

Build on top of your public Latitude location with GeoJSON & KML

2009-05-04T14:35:00.000-07:00

Posted by Chris Lambert, Software Engineer, Google Mobile

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!

{
   "type":"FeatureCollection",
   "features":[
      {
         "type":"Feature",
         "geometry":{
            "type":"Point",
            "coordinates":[
               -122.421092,
               37.79236
            ]
         },
         "properties":{
            "id":"-1890825674540886039",
            "accuracyInMeters":75,
            "timeStamp":1241400239,
            "reverseGeocode":"San Francisco, CA, USA",
            "photoUrl":"...",
            "photoWidth":96,
            "photoHeight":96,
            "placardUrl":"...",
            "placardWidth":56,
            "placardHeight":59
         }
      }
   ]
}

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

Upcoming Conferences: Global Geo Goodness

2009-04-29T23:30:00.000-07:00

Posted by Pamela Fox, Maps API Team

It's conference season, and the geo team is coming out in full force. Here are some of the upcoming conferences that we'll be speaking at - if you attend any of these, be sure to say hi and let us know how you're using our APIs!

WebDU: Sydney, Australia, May 21-22
Where2.0: San Francisco, CA, May 19-21
WhereCamp: Palo Alto, CA, May 22-23
Google I/O: San Francisco, CA, May 27-28
Google Developer Days:
GDD China: Beijing, China, June 5
GDD Japan: Tokyo, Japan, June 9
GDD Brazil: Sao Paolo, Brazil, June 29

For more events near you, check out our Developer Events Calendar.

MarkerClusterer: A Solution to the Too Many Markers Problem

2009-04-23T13:26:00.000-07:00

Posted by Xiaoxi Wu, Community Developer

Hi, I'm Xiaoxi (Frank) Wu. I'm a software engineer working for Beyondsoft in Beijing China, where I'm currently working on Maps API applications. While I was learning the Google Maps API, I got a lot of help from the forum and the open-source library, so I've decided to give back to the community with some of my own code.

The first library that I'm releasing is MarkerClusterer. Once, a friend of mine encountered a problem with his application. Using the API, he developed a map and added thousands of markers on the map, and saw that it made his map un-usably slow. This was because every marker is a combination of several DOM elements, and it's a lot of work for a browser to create many thousands of DOM elements. I decided that clustering would be a good solution for his problem, and came up with MarkerClusterer. MarkerClusterer collects markers into different clusters and displays the number of markers in each cluster with a label, creating new clusters as the map zoom level changes. The clustering algorithm is simple; for each new marker it sees, it either puts it inside a pre-existing cluster, or it creates a new cluster if the marker doesn't lie within the bounds of any current cluster. Because the clusters have a fixed size in each zoom level there are almost the same number of clusters in viewport in average - so MarkerClusterer has a good max and average run time. The screenshot below shows the effect of using MarkerClusterer on an array of 1000 markers (and the live demo shows you the speed difference):

It's easy to use - just add your markers to an array, pass that and your map into the MarkerClusterer, and it'll take care of the rest. Check out the simple example and code snippet below:

var markers = [];
  for (var i = 0; i < 100; ++i) {
    var latlng = new GLatLng(data.photos[i].latitude, data.photos[i].longitude);
    var marker = new GMarker(latlng);
    markers.push(marker);
  }
var markerCluster = new MarkerClusterer(map, markers);

You can also set some options for the MarkerClusterer like the cluster icons and the size of the clusters. You can see those used in this advanced example. If you want to learn more, check out the class reference or the how-to.

For other clustering options for your markers, check out the Maptimize hosted service or read this article that compares other 3rd-party clustering extensions.

New Articles: JQuery, Heat Maps, Multi-Touch, Clustering, & More

2009-04-17T16:17:00.000-07:00

Posted by Pamela Fox, Maps API Team

Thanks to Google Alerts and Twitter search, I'm always finding articles and blog posts written by developers about using our various Maps APIs. On the assumption that not all developers are constantly monitoring the internet for occurences of "google maps api", I've made it easy for you to benefit from these articles as well by linking to them from the documentation.

On the articles page for the JavaScript API, you'll find externally hosted articles on topics like Using JQuery with the Maps API, Density Mapping with the HeatMapAPI, and Handling Large Amounts of Markers.

On the articles page for the Flash API, you'll find articles on topics like Thematic Mapping, Creating Custom Maps, and Using the API with Multi-Touch Technology.

Check out the articles pages for the full list, and let us know if you have an article that should be on the lists.

Introducing the Mapplets API Demo Gallery

2009-04-14T15:46:00.000-07:00

Posted by Pamela Fox, Maps API Team

Due to the popularity of the demo galleries for our JavaScript and Flash APIs, we've added a demo gallery to the Mapplets API documentation as well. The demo gallery shows Mapplets created by both Google engineers and 3rd party developers, and provides links so that you can easily view the XML or use the Mapplet in Google Maps. You can learn from the demos how to do things like display KML files, store user preferences, localize your gadget to many languages, render custom tile layers on top of the base map, and more. Many of the demos come straight out of Sterling Udell's fantastic book, "Beginning Google Maps Mashups with Mapplets, KML, and GeoRSS: From Novice to Professional".

Browse through the demo gallery, and post in our new dedicated Mapplets API forum if you have questions (or a demo to contribute!).

Tours in KML: animating the camera and content in Google Earth

2009-04-10T15:39:00.000-07:00

Posted by Dan Barcay, Google Earth Engineer

If you're reading this blog, there's a good chance that you've seen or made some awesome geographic data visualizations in KML. Which means you know all too well that it can be hard to grasp the full story behind a visualization, especially a 3D visualization, without being guided through it. If you're like me, you might even have created KML files with giant Placemarks labeled "Start Here" and "Now go Here" and "Great View -- click on me!" If you're like me, you also felt dirty after doing that. It feels kind of like writing Perl -- you do it sometimes, but you don't really like to talk about it.

With the launch of Google Earth 5.0, we tackled this problem by introducing the ability to record and play your own tours through the world. Tours are a bit like interactive videos inside of Google Earth. Like a video, you can guide people on narrated journeys around the world and through your data, and you can rewind and fast forward. But when you pause a tour, unlike video, you can wander around in 3D. We included a shiny user interface for creating simple tours from inside of Google Earth 5.0, but underneath the hood tours are encoded as a powerful set of extensions to the KML language, that are much more expressive than the current recording functionality in Google Earth 5.0. In brief, these KML elements specify the timeline of the tour... a sequence of actions that tells Google Earth how to move the user through the world. They also allow you to modify and interact with your data presentation. In developing this language, we wanted to give developers precise control over all aspects of a tour. Not only can you control the movement of the camera, but you can play sound files, pop open info balloons, toggle the visibility of features, manipulate the time slider, and even animate the position and styling of content.

Below is a snippet of an example KML file containing a placemark and a tour. In the tour, the camera first flies to a good viewing location for the placemark and opens the placemark's info balloon for a few seconds. Then it closes the balloon, and proceeds to animate the size of the placemark icon and the color of the label using the <gx:AnimatedUpdate> action. It's an easy-to-read example for KML developers, but don't expect it to win an Oscar any time soon. On the other hand, it does show off the structure of a basic tour pretty well...

    ... see full file for the entire example ...

<!-- Our tour. The Playlist inside contains the
   sequence of actions that compose the tour. -->
<gx:Tour>
<name>Example Tour</name>
<gx:Playlist>

  <!-- Fly to the view of the placemark in 5.2 seconds. -->
  <gx:FlyTo>
    <gx:flyToMode>bounce</gx:flyToMode>
    <gx:duration>5.2</gx:duration>
    <LookAt>
      <longitude>-78.19074499027175</longitude>
      <latitude>35.31730443852049</latitude>
      <altitude>0</altitude>
      <range>10704.41142132794</range>
      <tilt>58.57687432675979</tilt>
      <heading>-76.75532143327891</heading>
      <altitudeMode>relativeToGround</altitudeMode>
    </LookAt>
  </gx:FlyTo>

  <!-- Open the balloon of the placemark. -->
  <gx:AnimatedUpdate>
    <gx:duration>0.0</gx:duration>
    <Update>
      <targetHref/> <!-- Left empty to refer to the current file -->
      <Change>
        <Placemark targetid="pm1">
          <gx:balloonVisibility>1</gx:balloonVisibility>
        </Placemark>
      </Change>
    </Update>
  </gx:AnimatedUpdate>

    ... and so on ...

To get started learning the language, you can make tours in Google Earth and save them as KML, reading the source for inspiration. Or you can dive straight into our KML developer tutorial for touring. If you're planning on generating tours programmatically, be sure to check out our open source KML parsing and generating library, which added full support for reading and writing Touring KML on the same day that Google Earth 5.0 came out.

Additionally, we recently released tour support in the Google Earth Plugin version 5.0. With this, it's now easy to integrate cinematic Google Earth presentations directly into your web content, complete with sound! See the plugin tour API example for details. Or check out the new tour gallery and touring gadget for more examples and techniques for putting tours into web pages.

Tours can be as long and as complicated as you want, so just let creativity be your guide in telling your story. Whether you're following GPS traces, modeling the ocean currents, mapping city population over time, or simply showing the good restaurants in your neighborhood, if you're serious about sharing your geo-data with the world, consider making some tours to accompany your KML file. You already have great visualizations lying around, so now show them off in style with a tour!

Google Earth Plugin Five-O: Ocean, Touring, and More!

2009-04-02T09:00:00.000-07:00

Posted by Roman Nurik, Google Geo APIs team

Last month, the Google Earth team made a splash in the news (pun intended) with the release of Google Earth 5.0. The update included the ability to dive underwater to explore the world's oceans, record and play back narrated tours, view historical imagery, and explore Mars in 3D. Today, our team is happy to announce the 5.0 version of the Google Earth Plugin!

If you've already installed the plugin, you should see the new version automatically within the next day or two. If not, you can download the plugin for Windows or Mac OS X by visiting any Earth API web site, such as Monster Milktruck and clicking 'Get The Google Earth Plugin now'.

We've added many of Google Earth 5.0's new capabilities to the plugin and API, as well as a few other frequently requested features. Here is a list of major new features in the plugin and API:

Ocean: Underwater terrain and the ocean surface are now available, along with support for the clampToSeaFloor and relativeToSeaFloor altitude modes. In the Earth API, these are ALTITUDE_CLAMP_TO_SEA_FLOOR and ALTITUDE_RELATIVE_TO_SEA_FLOOR, respectively. (See example)
(Issue 180) Tour playback: This is via KmlTour and GETourPlayer in the API. To play tours, you must first either parseKml or fetchKml a file containing a <gx:Tour>, and then use GETourPlayer to play the tour. (See example)
(Issue 43) Programmatic photo overlay viewing: This is via KmlPhotoOverlay and GEPhotoOverlayViewer in the API. See the note on touring above for details on how to do this, or see the example page.
(Issue 181) Mars: On plugin startup, you can connect to the Mars dataset instead of Earth. (See example)
(Issue 7) Time slider: The standard Google Earth time slider UI will pop up upon loading KML containing time primitives such as <TimeSpan> and <TimeStamp> into the plugin. (See example)
(Issue 47) Gray buildings: You can now add the gray buildings layer to the plugin with the LAYER_BUILDINGS_LOW_RESOLUTION layer. (See example)

Along with these major new features, we've implemented the following feature requests from the public issue tracker: 10, 27, 42, 49, 99 and fixed these publicly reported defects: 75, 118, 131, 148. Check the Earth API release notes for more details.

The full list of a new samples for this release can be found at the Earth API demo gallery.

On our agenda for the not-too-distant future is:

Getting the other new Google Earth 5.0 features into the plugin
More complete API support for KML tours
Native API interfaces for time primitives

Lastly, if you're yearning for more Earth API goodness, make sure to catch my Google Earth API session at Google I/O on May 27th and 28th. Discounted early bird registration ends May 1st, so register now before time runs out!.

New Open-Source Tabs, Markers, and Controls Libraries

2009-03-29T23:59:00.000-07:00

Posted by Pamela Fox, Maps API Team

The JavaScript API utility library has been growing fast in the last 3 months, with nearly double the number of libraries now being worked on in the development project. We can always use more libraries or help prepping the current libraries for release (code reviews, documentation, examples) - if you're interested, email the group to introduce yourself and let us know how you'd like to help. In the meantime, check out the most recent releases:

	TabbedMaxContent 1.0: This library provides a max info window UI that's similar to the info window UI for local business results on Google Maps, and works in conjunction with the API's maxContent option. This comes courtesy of Nianwei, a developer who's also working on two upcoming libraries for a lightweight keyboard-triggered drag-to-zoom and an ArcGIS connection layer. Check out the examples or reference.
	PopUpMarker 1.0: This library displays a "popup" (mini infowindow) to the side of a marker. The popup can either embed HTML, or it can use the Google Charts API to show text and icons in custom color schemes. This comes courtesy of Masashi, a Maps API expert from Japan with a plethora of tutorials and examples (all in Japanese, of course). Check out the examples or reference.
	ExtLargeMapControl 1.1: This library creates a control that mimics the functionality and UI of GLargeMapControl3D, the current control on Google Maps, without the Street View integration. Developers can easily re-skin this control to match their own site, and use it in combination with a re-skinned ExtMapTypeControl for a full custom navigational UI. This also comes courtesy of Masashi, with help from Bjorn, author of SnapToRoute and ProgressBarControl. Check out the examples or reference.

Changes to the GoogleBar

2009-03-15T23:09:00.000-07:00

Posted by Daniel Nadasi, Maps API Team

As many of you already know, developers can use the GoogleBar control in the Maps API to allow users to search the map for local businesses, landmarks and points of interest. As part of Google's ongoing commitment to improve user and developer experience, we have some changes coming up for the humble GoogleBar. Most importantly, we are adding advertising targeted to the user's searches. We hope that this, as with all Google advertising, will improve the user experience by providing targeted and relevant sponsored results. You will benefit from this as well, as you can make money from these Google ads provided on Maps API sites (see below).

In addition, there are a number of smaller changes: The JavaScript underlying the GoogleBar has been completely rewritten and the UI has been updated to make it more accessible and easy to use. In its collapsed state, the original GoogleBar control was often missed as a functioning search bar, so we aimed to design a new GoogleBar that was as recognizable as the traditional, elegant Google search field (logo + field + button), while occupying minimal space on the map. You can see the new GoogleBar, together with ads, below:

As you can see, in addition to the ad, there have been several cosmetic improvements. For example, we've removed the magnifying glass so the control is open all the time. As a result, we are deprecating the showOnLoad argument within the GoogleBarOptions object. All other arguments continue to be supported. This is a substantial change to the experience, look and feel of the GoogleBar, so we are giving you the opportunity to try the new version and give us some feedback before it becomes the default setting. Starting today you can try out the new GoogleBar by passing the parameter style='new' as part of GoogleBarOptions, as long as you are using the latest version of the API.

For example:

var opts = {
 googleBarOptions : {
   style : 'new'
 }
}
map = new GMap2(document.getElementById("map"), opts);
map.setCenter(new GLatLng(33.956461,-118.396225), 13);
map.enableGoogleBar();

Full documentation of the GoogleBar's new features is available in the API documentation.

This new version of the GoogleBar will contain advertising, as shown above. If you want to profit from the advertising personally, then all you have to do is get a Google AdSense for Search (AFS) id and pass it into the GoogleBar constructor. If you don't yet have a Google 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 Search. Once you have an AdSense for Search account, you will receive an AFS client ID. Specify this client ID, as shown below, and you will begin receiving advertising revenue for any clicks on sponsored results within your API application.

var opts = {
 googleBarOptions : {
   style : 'new',
   adsOptions : {
     client : ####  // Your Google AdSense for Search (AFS) client id
   }
 }
}
map = new GMap2(document.getElementById("map"), opts);
map.setCenter(new GLatLng(33.956461,-118.396225), 13);
map.enableGoogleBar();

Optionally, you may also specify an AdSense for Search channel if you've set that up. More information on advertising channels is located in the AdSense Help Center. Additionally, you may also specify the Ad Safety Level to associate with your advertising and the language in which to display results. Please consult the Maps API Reference for specifics.

You can give us feedback by going to the Maps API Google Group. A month or so from today we are planning to change the default style of the GoogleBar to be the new and improved version, so stay tuned for further announcements.

Good, beta, best

2009-03-11T23:27:00.001-07:00

Posted by Mickey Kataria, Product Manager

With the recent announcement of Google Code Labs, we wanted to update you on what's happening with the Maps and Earth APIs. We're excited to tell you that none of the Maps APIs (JavaScript, Flash, Static, Mapplets) or the Earth API are in labs. Furthermore, we've taken the opportunity to remove the 'beta' label from the Maps and Earth APIs. The original Maps API has been around for more than three years. Thanks to the hard work of dozens of people, the APIs have been very stable and become mature products that are used by sites and applications of all sizes. Our stability and commitment to supporting the APIs shouldn't be a big surprise for most of you, but now you've got it in writing too. :)

While the overall APIs are not in labs, there is one recent feature that is still experimental: AIR support in the Maps API for Flash. From time to time, as we release new features that are more of an experimental nature, we may let them bake in labs for some time. As with Google Labs and Google Code Labs, we'd like to get early feedback and see how you use these experimental features before making a long term commitment to them.

As always, please continue sending your feedback in the appropriate forum:

We've also set up "notify" groups that you can sign up for if you just want to see the important updates, e.g. new releases. You can sign up from the home page of each API or use the links below:

Monkey see, monkey do

2009-02-24T20:55:00.000-08:00

Posted by Jez Fletcher, Maps API team

Ever wanted to be someone else? No, we're not offering a Being John Malkovich service, but we are offering Maps API developers the default look-and-feel of maps.google.com, all with one simple function call.

Now, you can get the standard UI elements you'd see on Google Maps (including the newer style "3D" map and zoom controls), along with other standard behaviour such as keyboard and mouse handling, just by adding one line of code.

  // Create a map.
  var map = new GMap2(myMapDiv);
  // Give it the maps.google.com experience.
  map.setUIToDefault();

What's more, this function will ensure that if the UI of maps.google.com changes, these changes will also be reflected in your site without you having to update anything.

The function will automatically adjust what controls the map gets based on the size of the map. For maps larger than 300 x 400, the default controls are:

GLargeMapControl3D
GMapTypeControl
GScaleControl

For maps 300 x 400 or smaller, the default controls are:

GSmallZoomControl3D
GMenuMapTypeControl

Both will also enable scroll wheel zoom, double click zoom and add a GKeyboardHandler to the map.

You can also tweak the appearance to your liking. If you mostly want the standard behaviour, but, for example, don't want scroll wheel zoom enabled, you can get an instance of the default GMapUIOptions object, and adjust the fields to your liking.

  // Get the default GMapUIOptions.
  var uiOptions = map.getDefaultUI();
  // Disable scroll wheel zoom.
  uiOptions.zoom.scrollwheel = false;
  // Now set the map's UI with the tweaked options.
  map.setUI(uiOptions);

Along with this change, you can now also get direct access to the new 3D controls used on maps.google.com:

GLargeMapControl3D, and
GSmallZoomControl3D

A full reference of the functions, the GMapUIOptions class and all the defaults are available on the Google Maps API Reference. As always, head over to the forum if you have any questions.

Sorry that puppeteering of John M is not included, but at least now your site can easily look and act like Google Maps!

One more thing: if you want to meet the Maps API team and hear about other exciting things we're working on, come to Google I/O in May.

Google New York City Geo APIs Hackathon

2009-02-23T08:32:00.000-08:00

Posted by Mano Marks, Geo APIs Team

March 5th, from 3-9pm, Google will be hosting a Google Geo APIs hackathon at our Manhattan offices, 111 8th Avenue at 15th street in Manhattan. Join us for some hacking around on Google Geo APIs. Work on our learning materials, or work on your own projects. There will presentations on new features in the APIs, and plenty of Geo Googlers around to help you with your technical questions. In particular, we will be helping people with the Google Maps API, the Google Earth API, and KML.

To register, click here. Space is limited, so you may want to register now.

Map Maker for Developers

2009-02-19T17:18:00.000-08:00

Posted by Lalitesh Katragadda and Lior Ron, Map Maker Team

Since June 2008, thousands of passionate users have been mapping their heart out in mapmaker.google.com. The maps made are some of the finest ever seen in these 160+ countries. In a developer day we did in Bangalore, the top request from developers was if we can get these fresh maps in the API so that their users can benefit from the community's effort. We responded by launching the tiles from Map Maker as new map types in both the Google JavaScript Maps API (v2.146) and the Static Maps API as new map types. So if you have a Google maps mashup that is primarily used in one of these countries or you simply want to embed a fresh map in your blog post or web page, you can use these maps that are updated every day by the map maker community. Google is committed to providing the best maps possible to users everywhere and this is just one more step in our quest to make maps from mapmaker as useful to users as possible.

Here is how you can use these new features.

JS API syntax
Use G_MAPMAKER_NORMAL_MAP and G_MAPMAKER_HYBRID_MAP in lieu of the normal map and hybrid types to show mapmaker map tiles and hybrid tiles respectively. Remember that these serve maps only for the countries being edited in mapmaker, not all the countries available in maps.google.com. If you're making a mashup with a global audience, you may want to add logic to switch between the map types, or offer the option to the users.

Static Maps API syntax
users can access mapmaker tiles using 'maptype' values of "mapmaker-roadmap" or "mapmaker-hybrid" e.g. http://maps.google.com/staticmap?center=31.494445,74.334011&zoom=15&size=512x512&maptype=mapmaker-roadmap&key=MAPS_API_KEY&sensor=false

See the comparison of this URL vs the same URL without the "maptype=mapmaker-roadmap" for Lahore, Pakistan.

If you have data that you want to update yourself - whether you're a city GIS expert, a company's webmaster or just a local expert, you can edit map maker and the new data will show on your mashup within a day. For more information read the latest developments on our Lat Long blog, visit Map Maker, interact with the map maker community, or go to our help site. And, as always, please follow up with your suggestions and questions in the forum.

Hola, Allo, Olá, Здравствуйте! Maps API Developers!

2009-02-05T19:00:00.000-08:00

Posted by Tom Manshreck, Maps API Team

Bom dia! добрый день!

(This post has been translated into Portuguese and Russian.)

During the past year, we've expanded translations of the Maps API documentation into more and more languages, making it easier for developers around the world to add Google Maps to their websites. Earlier in 2008, we provided Japanese and Simplified Chinese translations which we've recently updated.

Over the past few months, we've quietly released several more translations of the Maps API documentation, with Brazilian Portuguese and Russian being the latest to undergo a full translation. We previously added German and Spanish in September, 2008. Each of these translations can be found at the following URLs:

Additionally, you can change to translated documentation by selecting from the language selector in the top right portion of code.google.com's documentation pages. If a translation is available in that language, it will appear. (If no translation is available, default English will be shown.)

We've chosen these translations because they cover most of the non-English speaking readers of the Maps API documentation. We hope they will encourage a new group of developers to use the Google Maps APIs.

Note: although we will try to keep the translated documentation as up-to-date as possible, the English docs will often contain the latest information. (All developers should be sure to periodically check out the English Maps API Reference, which is updated every few weeks.)

***

Bom dia!

Ao longo do ano passado, nós expandimos os idiomas para os quais a documentação da Maps API é traduzida, facilitando que desenvolvedores ao redor do mundo adicionem Google Maps aos seus websites. No início de 2008, nós disponibilizamos traduções em japonês e chinês simplificado. Ambas as versões foram atualizadas recentemente.

Nos últimos meses, silenciosamente lançamos mais traduções completas da documentação da Maps API, com traduções para o alemão e o espanhol em setembro de 2008 e português (brasileiro) e russo, recentemente. Estas traduções podem ser encontradas nas seguintes URLs:

Você pode escolher entre as traduções utilizando o selecionador de idioma no canto superior direito da página de documentação do code.google.com. Se uma tradução estiver disponível naquele idioma, ela irá aparecer (caso contrário, a versão em inglês será exibida).

Nós escolhemos estes idiomas porque eles cobrem a maioria dos usuários da documentação da Maps API que não fala inglês. Esperamos que estas traduções encorajem um novo grupo de desenvolvedores a usar a Maps API da Google.

Nota: nós tentaremos manter as traduções tão atualizadas quanto possível. Porém, a versão em inglês irá, algumas vezes, conter informações mais recentes. (Desenvolvedores devem verificar periodicamente a documentação de referência da Maps API em inglês. Ela é atualizada há cada poucas semanas.)

***

Добрый день!

За последний год мы перевели документацию по API Карт на большое количество языков, и разработчикам по всему миру стало легче использовать Карты Google на своих сайтах. В начале 2008 года мы выпустили, а недавно обновили, переводы на японский и упрощённый китайский языки.

За несколько последних месяцев мы тихо и незаметно выпустили ещё несколько переводов документации по API карт. В сентябре появились немецкий и испанский переводы, а совсем недавно вышли переводы на бразильский, португальский и русский языки. Эти переводы можно найти здесь:

Вы можете переключиться на переведённую документацию, выбрав язык из выпадающего списка в правом верхнем углу страниц сайта code.google.com. Если перевод текста страницы для для выбранного языка существует, то он будет показан (если его нет, то будет показан текст на английском).

Мы выбрали именно эти языки, потому что большинство неанглоязычных читателей документации API Карт говорит именно на них. Надеемся, что переводы подтолкнут новых разработчиков к использованию API Карт Google.

Замечание: мы стараемся поддерживать переведённую документацию в актуальном состоянии, но часто англоязычная документация содержит наиболее свежую информацию. Всем разработчикам следует время от времени заглядывать в англоязычный справочник по API Карт, который обновляется раз в несколько недель.

Webmasters: Easily Embed Directions on Your Site

2009-02-04T03:30:00.000-08:00

Posted by Pamela Fox, Maps API Team

Back in December, Julie posted on the Google LatLong blog about a new directions gadget that webmasters can embed on their websites to make it super easy for people to find them. Check out that post for information on embedding and the diverse ways the gadget can be used (with coordinates, addresses, zip codes, and more).

The gadget uses the Google Maps API and jQuery, and does nifty things like display a "Did you mean..." when they've entered an ambiguous address and then animates the selected address flying into the form. For those of you developers who like the functionality but want the it more integrated more into your site, the good news is that you can easily copy, paste, and modify the code from the gadget XML spec.

Ocean, Time Machine, and Touring: New KML Extensions for Google Earth 5.0

2009-02-02T16:31:00.000-08:00

Posted by Mano Marks, Geo APIs team

You've probably already read about this week's release of Google Earth 5.0 and its exciting new features, including Historical Imagery, Touring, Ocean, and Mars. As is usually the case for new features in Earth, we wanted to add representations for some of them to KML. In the past this was done by simply adding new elements to the KML specification. But that's no longer an option for us, since KML is no longer controlled by Google, having been released as an open standard by the Open Geospatial Consortium.

So what's an application provider to do? Fortunately, both Google and the OGC had the foresight to anticipate that innovation would continue to drive the standard forward, so OGC KML includes a standardized mechanism that enables any group to extend KML within their own XML namespace. Google Earth 5.0 uses this extension mechanism to add to KML in a standards-compliant way. We've also added some new documentation to guide you in understanding these new KML constructs:

First, something mentioned no where else, Google Earth now supports close to the full range of HTML and JavaScript in the description balloon! This is something that developers have been asking for, and we were able to change the HTML rendering engine to include it. For more details, check out the KML Reference for the description element.
We added a new Developer Guide article on Touring. The KML representation of touring is much more expressive than the simple record button in Google Earth -- KML tour authors have very precise control over the camera, the time slider, and even 3D object animation.
We added another Developer Guide article on altitudeMode, which explains among other things the new ability to place Features below the water surface.
We've updated the Time and Animation article to take into account touring and time machine. In particular, KML authors can now control the time slider, both inside and outside of a tour.
We updated our KML reference to include entries on all the of the new extension elements. The new elements are carefully called out in the documentation as being part of Google's KML extension namespace, to distinguish them from the core OGC KML elements.
And finally, we updated libkml to version 0.9. libkml is a powerful open source library for use with applications that want to parse, generate and operate on KML. The new version provides support for the extensions, as well as Update/Delete.

For those who are interested in precise XML validation of the new elements, please see Google's new KML 2.2 extensions XSD, which is the formal standards-compliant description of their syntax.

As always, you can find out more information or ask questions in the KML Developer Forum.