Guest post by Bob Hitching, Director of Technology for Xumii, recently acquired by Myriad (Myriad Group AG), Europe's largest mobile technology company with software in over 2 billion phones.Bob also writes about mobile + geo + social on his blog and tweets as @hitching.

GeoMeme is a pet project of mine. It's a web app, and also a mobile web app for iPhone and Android, that measures real-time local twitter trends to work out what's happening where.

Visitors to GeoMeme choose a location on the map, and two search terms to compare. GeoMeme then measures and compares the number of matching tweets within the bounds of the map. Tweets are located using Twitter's brand new geotagging feature, and public data from a number of mobile twitter apps.

As an example, GeoMeme can work out that 'love' beats 'hate' in New York:

GeoMeme is packed full of geo goodness, and I am excited to share some details on how it all works in the following articles. I hope these are useful to those of you building your own geo apps.

Location-aware mobile web apps using Google Maps v3 + geolocation

This article explains how location-aware mobile web apps such as GeoMeme Mobile are now becoming a viable alternative to native mobile apps for iPhone &/or Android.

Also covered is how to combine various geolocation techniques to work out where on earth a mobile phone is located, and how to dynamically retrieve content local to the user for display on a mobile map.

Sample code is provided in the form of a 'Here I Am' location-aware mobile web app that combines geolocation techniques, and retrieves local photos from Panoramio for sharing on Twitter or Facebook.

Fast map re-location using Google Static Maps v2 + geocoder

As well as offering users the normal pan and zoom controls to move the map around, GeoMeme also adds an innovative geo-autocomplete control which provides a refreshingly quick way for users to re-position the map anywhere on the planet.

This article explains how the geo-autocomplete control uses the geocoder service from Google Maps v3 API to match location names as they are being typed, and then the new Static Maps v2 API to present the results as a menu of map thumbnails to choose from.

Sample code is provided in the form of a jQuery plugin for you to build your own geo-autocomplete controls.

Scalable, fast, accurate geo apps using Google App Engine + geohash + faultline correction

GeoMeme generates a large amount of geo-data, and so arises a need shared by many geo apps: scalable, fast, and accurate spatial queries, to select a subset of geo-data for display as markers on a map.

This article is all about using Google App Engine to host scalable and fast geo apps, and using an optimised version of the geohash algorithm to perform your spatial queries.

There's a fun demo showing the effect of geohash faultlines, and the relative accuracy of spatial queries with or without faultline correction

Sample code is provided as a python module to handle faultline-friendly geo search, if you want to use this technique on your own geo apps.

Ever since the release of Google Street View in 2007, we have been thinking about how we could enhance it. It wasn't until Street View arrived in New Zealand in December 2008 that we finally decided to build a prototype called Mapsicle (Maps meets Popsicle).

The prototype showed how you could easily overlay content such as markers and InfoWindows onto Street View. We showed Mapsicle to a few people including the Google Maps API team who were excited about what it could do. We asked Google if we could submit Mapsicle into the Maps Util library to ensure that we accelerate the development of Street View as a maps application platform. After a couple of months of testing and bug fixing, we are happy to announce that Mapsicle v1.0 is now live.

What can Mapsicle do ?

Using Mapsicle library, you can do a lot of interesting things:

• Create and show markers at various locations on Street View such as Disneyland Paris

• Show markers that are outside of the field of view such as the NZ flag marker above.

• Create InfoWindows at locations.

Getting Started

To try it out yourself, read through the developer's guide and reference, and check out the examples that show how to implement custom infowindows, markers, and map integration.

The world of possibilities

Now that Street View is being extended via the Street View partner program, Mapsicle could be used to create a whole range of maps applications…

• Advanced Store locators: Create store locators that show exactly how to get to your store from the user's current location.
• Interactive tours: Combine Street View with content to give tours of the streets of the world.
• Digital signage: Create interactive advertising on Street View using video and images.
• Interactive kiosk: Build a touch screen information kiosk for visitors.
• Games: Build a treasure hunt application or a racing game to drive around Thunderhill raceway.

As one example of the possibilities, we created a fun little mashup called StreetTag.

Thanks to the team

Kudos to the entire team at ProjectX, in particular:

• Stephen Davis, who created and named the Mapsicle prototype.
• Cameron Prebble, who has been working on building lots of demos and the front end experience.
• Thong Kuah, for managing the project and pushing us to open source.
• Raja Bhadhury, who has been helping us test and refine Mapsicle over the last few months.

We've had a lot of fun building Mapsicle and we're really excited to see what cool things geo developers are going to do with it. We'd love your help to build out Mapsicle and add more features. You can contribute to the project by joining the Google Maps API Utility Library, and you can let us know how you're using the library by posting in the forum. Enjoy!

We've also made a few improvements from Polylines and Polygons in Maps API v2.

1. You can send in multiple paths for one Polygon, and use that to render holes inside your poly, like in this Pentagon example.
   
2. When you give us a set of vertices, we assign a level of detail to each vertex, showing only the necessary amount of vertices per zoom level. This is how we show complex routes in driving directions on Google Maps, and now you can benefit from that optimization with no extra work. Zoom in on the fractal snowflake poly example to see how it looks.
   

Adding a polyline or polygon to a map is easy, as shown in this snippet from the documentation:

 
  var flightPlanCoordinates = [
    new google.maps.LatLng(37.772323, -122.214897),
    new google.maps.LatLng(21.291982, -157.821856),
    new google.maps.LatLng(-18.142599, 178.431),
    new google.maps.LatLng(-27.46758, 153.027892)
  ];
  var flightPath = new google.maps.Polyline({
    path: flightPlanCoordinates,
    strokeColor: "#FF0000",
    strokeOpacity: 1.0,
    strokeWeight: 2
  });
  flightPath.setMap(map);

We wanted to launch early and get feedback, so there are still some features to come:

• Support for the 'mouseover' event
• Further rendering optimizations
• Built-in editing like in Google My Maps

That said, here's a simple demo of polygon editing to show what you can do.

As always, please provide feedback in the Google Maps JS API v3 Group.

Today, I'm annoucing my newest contribution: SnapshotControl. This control makes it easy to generate an image "snapshot" of your interactive map, using the recently released Google Static Maps API v2.

The default behavior of the control is to add a button on the map, and that button pops up a snapshot when clicked. However, the control can be hidden and the generated snapshot URLs can be programmatically retrieved, so that the library may be used in a more flexible manner. Check out this demo to play with different options and see the generated URL.

This control also knows how to encode polylines, using the Douglas-Peucker algorithm, which means that it can be used on maps with very long paths. For example, the control can create static maps for driving direction routes, as shown in the this demo.

To learn more about this control, check out the reference and more examples. Enjoy!

When a user right-clicks on Google Maps, a context menu appears with options like getting directions, zooming in, or finding the address of the center point (reverse geocoding). Since I wanted this helpful feature in my own maps, and the core API does not provide it, I decided to implement a fully open-source version and release it in the utility library: ContextMenuControl.

This control includes all the same items as the native Google Maps control, but I've implemented the directions functionality in a different way. Instead of requiring the developer to provide a panel and inserting the directions steps there, I create infowindows that the user can step through. Now, any developer can use this control and not worry about having to allocate space on their page for the directions steps. The directions functionality also includes the ability to add, remove, and drag points, so that the user can easily customize their query.

The result is a control that's easy for users and easy for developers, and is probably the fastest way to add reverse geocoding and directions functionality to your map (especially if it's a small map). Just include the script tag for the source code, insert this line in your map init function, and you'll get a right-click menu like the screenshot shows below:

  map.addControl(new ContextMenuControl());

For more information, read through the reference and developer's guide. For other open-source extensions that can enhance your mashup, check out the utility library. Enjoy giving your users the power of right-click!

I was once asked what I thought the next frontier in maps mashups was, and I responded: "time". Why? It's tricky figuring out how to display layers of data on top of a map, but it's even trickier to squeeze in one more dimension and display time-based data, and I admire those developers that take on the challenge. Here are some examples:

	NYC Homicides Map Displays 10 years of homicide data in New York City, including as recent as the last 2 weeks (eerie!). They give users a slider to quickly slide through the years and see how the density changes, and also give them different options for coloring the data. It's a great, simple combination of two different ways of visualizing data.
	RozTracker Shows the voyage of a woman that's in the middle of rowing across the Pacific. The user can see how many oar strokes she's done, and zoom in to see her tweets, blog posts, and videos from the voyage so far.
	WW2 TimeMap Displays WW2 events using TimeMap, the open-source project combining the SIMILE Timeline with the Google Maps API. It's a rich timeline that's able to show long-running events as well as single-time events, and deals with overlapping events. It means that the developer can open the map up to user contributions, and not worry about the usability of the interface being compromised.
	Manhattan Map Shows what Manhattan looked like hundreds of years ago (a whole lot greener), and gives the user a slider to change the transparency of the 1609 imagery, giving the illusion of the modern-day landscape fading in. The user can also hover over individual city blocks for information on what that block was like back then.
	TimeSpace Clusters the top news stories on the map, and gives the user a time slider to pan through the day's events. The graph underlaid beneath the slider shows how the news density varies during the day, and a search box lets the user filter the news displayed. It's a much more fun way to browse the news, and a good way to encourage readers to be interested in news all over the world.

As you can see, there are a lot of ways to show time-based data on maps, and each of them suit different needs. The important thing is that developers are pushing the envelope and experimenting with different interfaces, and putting it out there for all of us to enjoy. For more examples like these, check out the "Timeline" label in the Google Maps Mania directory. Tune in next week to hear about more of our favorites! :)

• "Creating a Mobile Store Locator" shows how to query a database for stores near a user's location, and how to present that in a nice mobile-friendly webpage.
• "Using PHP/MySQL with Google Maps" shows how to pull data from a SQL database as XML and display that on the map.
• "From InfoWindows to a Database: Saving User-Added Form Data" shows you how to enable users to add geo-tagged information to a database via your map application.

We've also added links to articles from developer Gabriel Svennerberg, who has started a series on Maps API v3 and is in the process of writing a book.

If you have written an article about using any of our APIs, please let us know using this form. We love to see developers adding knowledge to the community.

A few weeks ago, Google announced 3D/perspective capability in the Flash API. If you would like to try out this functionality, but you're not ready to fully commit to AS3 yet, you may find this open source library helpful: Map Bridge.

The concept is very simple: programing a flash component with JavaScript, similar to what you do with GStreetViewPanorama. This library exposes all core classes in the Flash API and packages them in an easy to use way. You can write a simple Map3D application like this:

 
var map;
function init() {
  MapBridge.createMap(document.getElementById('map_canvas'), function(mp, brg) {
    map = mp;
    map.addEventListener('mapevent_mappreinitialize', onMapPreinitialize);
    map.addEventListener('mapevent_mapready', onMapReady);
  });
}
            
function onMapPreinitialize(e) {
  var myMapOptions = new MapOptions({
    zoom: 12,
    center: new LatLng(40.756054, -73.986951),
    mapType: MapType.NORMAL_MAP_TYPE(),
    viewMode: View.VIEWMODE_PERSPECTIVE(),
    attitude: new Attitude(20, 30, 0)
  });
  map.setInitOptions(myMapOptions);
}
            
function onMapReady(e) {
  map.enableContinuousZoom();
  map.enableScrollWheelZoom();
  map.addControl(new NavigationControl());
  map.addControl(new MapTypeControl());
}
       

Here is an example that uses Map3D and driving directions for a fly-over.

For more information, check out more examples, how-to, and reference.

Now, in order to support the top requested features and to make it easy to fulfill future requests, we've rewritten the API and are launching the new interface as Static Maps API v2. The main new features are:

• Paths can be specified as encoded polylines. (Issue 205)
• Paths can be filled and rendered as polygons. (Issue 792)
• Locations (in center, markers, or path parameters) can now be specified as addresses instead of latitude/longitude coordinates.
• Colors can now be specified as any 24-bit or 32-bit color.

To show off the new stuff (and my recent vacation in Japan), I've developed a Secret Treasures of Kyoto" mobile-friendly website. You can use it to visit a park where monkeys roam free in Arashiyama (using a filled path), to walk from our hotel to a restaurant with the most delicious deep fried roast beef sandwiches (using a path), or to stalk a creepy looking soft-shelled turtle (using a turtle-colored marker). Check out the iframed website below, or in your mobile browser:

All of the old features are supported in the new API but some of the URL parameters have changed, so if you're a developer that's already using the old API, please refer to the upgrade guide. (That also means that Static Maps v1 is being deprecated - but don't worry, there's plenty of time to upgrade).

If you're a developer that wants to take advantage of the new features, read through our developer guide. To play around with everything right now, try the new Static Maps v2 Wizard.

Google APIs made most of the map creation tasks quite easy, but fine-tuning thematic maps still required a lot of work. I wanted to load a dataset and make a single library call to calculate the color gradients, but at the same time I wanted to be able to express complex rules, like "draw all negative values with a red-yellow gradient, then draw the bottom 50% of the positive values with a yellow-orange gradient, and the rest with a orange-red gradient".

Developer Bjørn Sandvik created the great Thematic Mapping library using the Google Earth API and Google Visualization APIs in JavaScript, but while it supports a large number of thematic map types, it can only draw a gradient between two colors. So, to satisfy my needs for multi-colored gradients and more control, I wrote a library for the Maps API for Flash called GradientControl.

Here's a simple example of using GradientControl, with just a three-color gradient, from green to yellow to red:

You can drag the slider under the map to change the position of the middle color and immediately see the results. Click on a country to see the value associated with it. You can also try out a larger version of this example, with two middle colors and three sliders.

The color gradient configuration can be either constructed with Actionscript function calls, or moved into an external XML file. The complex example that I wanted to write would look like this:

<gradientRuleList> 
  <gradientRule> 
    <gradient> 
      <minColor>0x0000ff</maxColor> 
      <maxValue>0</minValue> 
    </gradient> 
   </gradientRule> 
   <gradientRule> 
     <gradientRuleList> 
       <gradientRule> 
         <gradient> 
           <minColor>0xff0000</minColor>     
           <maxColor>0xff8000</maxColor> 
           <maxPercent>50</maxPercent> 
         </gradient> 
       </gradientRule> 
       <gradientRule> 
         <gradient> 
           <minColor>0xffff00</minColor>
           <maxColor>0x00ff00</maxColor> 
         </gradient> 
      </gradientRule> 
    </gradientRuleList> 
  </gradientRule> 
 </gradientRuleList>

This is verbose, of course, but still much easier than writing custom code.

To get started using the library, check out the source, read the documentation, and post in the forum if you're having issues (or simply to show off what you've made). If you're interested in improving this control or making it work better with existing standards or APIs, please join the utility library forum. Enjoy!

My name is XIAO Juguang - just call me Juguang. I am a freelance software developer based in Beijing, China. Technically speaking, I'm double sided. On one side, I specialize in knowledge management and business modeling, traditionally using LAMP and now experimenting with offerings like Google App Engine. On the other side, I love visualization in time and space, with charts, trees, graphs, and maps, always using the power of ActionScript/Flex, with the help of open-source projects like Degrafa, Axiis, and Birdeye, and of course, APIs like the Google Maps API for Flash.

A few month ago, Xiaoxi Wu (also from China!) created the MarkerClusterer library for the Google Maps JavaScript API v2 and released it in their open source utility library. This library did automatic clustering of markers placed on a map, so that a large amount of markers wouldn't overcrowd the map or overwhelm the user. This is a great technique for having a better performing map (see this talk for more tips on improving map performance), and the Flash map community immediately rushed to port the code to ActionScript. Developer Sean Toru posted the first port, a version that was only Flash-compatible, Ian Watkins modified that port to use Flex packages, and then I refactored the code to be more ActionScript-friendly and released it into the open-source library. It's great when random strangers can collaborate together on a common code goal. :)

To see how the AS3 MarkerClusterer works, try out the demo (shown above). As you zoom and pan the map, you can witness how the markers are clustered and re-clustered. To learn how to use MarkerClusterer on your own map, view the source code of the demo. To use the library, check out the source code and import it into your project.

The current algorithm is quite simple, just clustering markers in a grid and using static images for the cluster markers. Future extensions could include support for regional clustering or using arbitrary DisplayObjects for the cluster markers. If you're interested in extending the library, join the project.

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.

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.

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.

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!

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).

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.
  

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.

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!

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.

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.

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.

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.

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.

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!).

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.

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.

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.

Hi, I'm Nick Rabinowitz, guest poster. I'm a grad student at the UC Berkeley School of Information and the creator of TimeMap, a Javascript library that helps the Google Maps API play nicely with the SIMILE Timeline API to create maps and timelines that work together. Readers of the Google LatLong blog may have seen TimeMap in action already, in the Maps API's 3rd birthday post. That post promised an eventual technical explanation of how to make such map-timeline mashups. Well, exhale your bated breath: Here it is!

The basic idea of TimeMap is to wrap both the Google Maps API and SIMILE Timeline in a third API in order to control interactions between a map and a timeline on the page. The "wrapping" happens via a set of Javascript objects that hold references:

• TimeMap: The TimeMap object has references to the GMap2 object (as "map") and the Timeline object (as "timeline"), which you can access directly (e.g. myTimeMap.map.zoomIn()). It also has an array of TimeMapDataset objects.
• TimeMapDataset: A TimeMapDataset object holds an array of TimeMapItems.
• TimeMapItem: A TimeMapItem has references to a placemark (on the map) and an event (on the timeline). Calling methods on the item allows it to control the placemark and event so they work in sync.

This tiered structure of references means we can set functions or event listeners on one object that make things happen in another - e.g. hiding placemarks on the map when their associated event scrolls out of view on the timeline, or opening a map info window when the corresponding timeline item is clicked. It also means that you can set cascading options on the whole TimeMap, a single dataset, or a single item - for example, you can set a theme on a dataset so that all its items display the same way.

The other big thing the library does is handle initialization. The timemapInit() function lets you create your TimeMap and load your data in a single function call, setting all the parameters in JSON. To make this really flexible, it supports a bunch of pluggable function hooks. For example, there's a default openInfoWindow() function called when you click the placemark or the event - but you can write your own function (e.g. to use ExtInfoWindow) and set it on a per-dataset or per-item basis.

The library includes a lot of helper functions to help you set up your own TimeMap. You can load data as inline JSON, remote JSON, or KML (with TimeStamp and TimeSpan elements). Click the screenshots below for examples of each of those:

• Post-Election Violence in Kenya (using KML data)
  
• Simple Three-Item Dataset (using inline JSON data)
  
• Google Events TimeMap (JSON Calendar Feed + transformFunction)
  

If all this piques your interest, check out the BasicUsage wiki, svn checkout the code, and get started making your own TimeMap. Happy coding!

You know what's awesome about open-source code written in one language? It's fairly easy to port it over to a similar language, and suddenly it's useful for a completely new audience. That's what's happening in our open-source JavaScript/AS3 Maps API utility libraries, and I'm loving it. Check out the most recent ports:

	DragZoomControl: This custom control lets user drag a rectangle on the map to zoom in to just that area, and it's one of my personal favorite ways of drilling down on a map (particularly since I'm usually on a laptop, without a scroll-wheel mouse). The port comes courtesy of developer Brian Richardson. Check out the demo or the reference.
	MarkerTracker: This class lets you assign "trackers" to markers, so that when a marker moves out of the visible viewport, a ghost marker and arrow points in the direction of the tracked marker. For maps where there's one very important marker/POI, it's a great way of showing the user how to get back to the original marker. This port comes courtesy of developer Michael Menzel. Check out the demo or reference.
	KMLParser: The KML parsing classes, which were a minimal port of the C++ libkml library, now have support for KML styles. This enhancement comes from developer Cecil Reid. Check out the demo or reference.

Thanks to all the developers helping to grow the library! If you're a developer with some code to contribute, just follow the steps in the wiki to get involved.

The Geo and the Google Web Toolkit teams are pleased to announce the public release of the Maps API library for Google Web Toolkit. Google Web Toolkit (GWT) provides a framework for writing web applications using the Java language. The Maps API library for GWT provides Java classes which are designed to provide a familiar paradigm for Java users to access the Google Maps JavaScript API.

 // Open a map centered on the equator/prime meridian
 map = new MapWidget(LatLng.newInstance(0, 0), 2);
 map.setSize("100%", "100%");

 // Add some controls
 map.addControl(new SmallMapControl());
 map.addControl(new SearchControl());

The GWT compiler translates your Java code into JavaScript for deployment to end users. No Java runtime is needed in the browser.

Using the library, you can freely mix Maps into a GWT application, or you can add GWT Widgets in with Map constructs, like Controls and InfoWindows. The demo below combines the DecoratorPanel, StackPanel, and SuggestBox widgets with a Map widget that uses Markers, Directions, Geocoding, and Geodesic Polylines.

There is online documentation, samples, tutorials, and a support forum.

The library has been released previously in milestone and release candidate forms, and it supports most Maps features up to version 2.113. We would like to thank the hundreds of developers that have tried the library and provided feedback.

In 2007, we wrapped up the year with a bulleted list of our various accomplishments from this year. In 2008, a few LIs and a UL just won't do. So we're celebrating the year in typical New Years fashion: fireworks, baby. Watch the show below, and click any headline it leaves behind to read the relevant blog post. If it went too fast for you or you just can't get enough of it, then you can watch again by clicking the button below the map. Happy New Years, all!

P.S. Five bucks if you can find a way to name-drop the Google Geo APIs in your midnight toast (or New Years' post?) and send me proof.

For the second year in a row, Google partnered with NORAD to provide an online map-based interface for tracking Santa's Dec. 24th sleigh ride across the world. Last year, the map was powered with the JavaScript Maps API. As the programmer for this year's map, I made the decision to use the Maps API for Flash instead. Why? I desperately wanted a glittery "comet trail" to follow Santa's path, and those kinds of effects are easier to pull off in Flash. (One might argue that decisions shouldn't be based on glitter, but one could counter that by pointing out the entire 1970s decade was based on glitter).

While converting the map over to Flash, I wrote code that may be helpful to other Flex developers out there. Instead of just open-sourcing the Santa Tracker map code* and forcing you to sort through it all, I've created standalone demos and descriptions for each of the features:

• Comet Trail: The purpose of the trail was to show Santa's recent trajectory, and give the flight more movement. The cloudy trail effect was achieved by creating a custom overlay that drew a line of increasing width through the 7 most recent markers, and then applying a BlurFilter to that line. To achieve the glitter effect on top of that, I create invisible circles of increasing radius around the markers, and then dynamically load in a sparkle SWF at random points within those circles. To get a twinkle instead of a strobe effect, each sparkle SWF is started at a different random frame in its timeline.
  Check out the demo or source code.
• Embedded Youtube: The real highlight of Santa's ride are the 23 locations where we have "Santa Cams" (Youtube videos), so it was important that we were able to view those Youtube videos on the map. It's a surprisingly difficult task, due to the facts that: 1) the embedded Youtube video player is an AS2 SWF, 2) the Santa map is an AS3 SWF, 3) the Youtube SWF has to be "destroyed" before a new Youtube SWF can play, and 4) AS3 SWFs cannot call methods inside an AS2 SWF. With help from the Youtube team and the AS3 Chromeless player library code, I was finally able to get Youtube + Flex to cooperate. The solution involves the creation of a "bridge" SWF in AS2 that communicates via LocalConnection to the AS3 SWF to load/unload videos, and it also involved a whole lot of random numbers.
  Check out the demo or source code.
• Smart Info Windows: To show all the locations, the map's default zoom was a viewport showing the whole world. Using the standard infowindows, this meant that when the user clicked on a location in the Northern hemisphere like the North Pole, the infowindow would pop up above the marker and pan the map so that the user just saw a whole lot of grey. Since I hate grey (it's the antithesis of glitter) and wanted a better user experience, Flash API engineer Dmitri Abramov wrote a "smart" info window for me that automatically opens in the direction (top, bottom, left, right) that minimizes panning.
  Check out the demo or source code.
• JavaScript <-> Flex: Though the map was coded in Flex, many pages on the NORAD site were just JS/HTML. The "RADAR" data was stored as JSON, and common JavaScript functions were used for figuring out the current time and then calculating the current location and phase from that information. So, to avoid replicating all the same logic and data in AS3, we instead used ExternalInterface to send information from the JavaScript to the map, along with some open-source libraries for encoding JSON objects into strings and decoding the strings into AS3 objects.
  Check out the demo or source code.
• Full Screen: A day before the map was set to go live, I realized that I'd been debugging the map SWF at 100% width/height all the time, when it was in fact going to be embedded inside a 500*450px space on the NORAD site. It depressed me that users wouldn't get to experience the map at the same size, so I searched Google for information on enabling full-screen on Flex apps, and happily discovered it was ridiculously easy to do - just a few lines of code, an "allowFullScreen" param in the HTML, and a toggle-able Flex Image control.
  Check out the demo or source code.

* Okay, yeah, I open-sourced the whole code as well, mostly because I've developed an unhealthy dependence on Google Code's nifty subversion repositories and issue trackers. Finding the NORAD repository is left as an exercise to the reader.

Hi, my name is Björn Brala! In the last 2 years, I've been working on GeoStart, a framework based on the Maps API. In that time the community has been an invaluable source of information and help. While getting help is nice, helping is even nicer - so I've decided to properly release and document the code for two helper libraries into the open-source utility library project.

ProgressbarControl

When loading hundreds of markers into a viewport, you should communicate this to the user, and this class will help you do so. The progress bar is a custom GControl with a few basic commands to start, update and stop the loader. The general idea is that you set the amount of operations the map will plan to do and then once in a while send an update command to the control.

The example below uses the control to show the progress of markers being added and removed from the map. Click the "loadMarkers()" button to start it up:

If that interests you, check out the reference and developer's guide for the ProgressbarControl.

SnapToRoute

In our framework, we wanted to enable administrators to not only create routes, but also plot different POIs along a route - so I created the SnapToRoute class based on one of Marcelo's examples. This class lets you snap a marker to the closest point on a polyline, ensuring that the marker is always somewhere on the line.

There are numerous ways to use this tool. The example below uses the class to let you zoom into segments of a polyline:

If that interests you, check out the reference and developer's guide for SnapToRoute.

Hope everyone likes the little additions, and don't forget to check out the other classes in the utility library!

Just a little over six months ago our team announced the release of the Google Maps API for Flash. Flash developers around the world welcomed this new API with excitement... and a barrage of feature requests. By far the most popular one in the past six months has been the compatibility with Adobe AIR.

Throughout its three years of existence, the Google Maps API has become one of the most popular online APIs for creating web mapping applications at a time when web was the hot new thing. Well, in the past year, Adobe has taken web apps back to the desktop, with their innovative AIR product.

There were both technical and legal challenges blocking AIR support in our API. AIR has a different security model, which required a number of changes to the "internal plumbing" of the API in order to implement our delayed-loading model, where the actual implementation of the map's functionality loads dynamically from Google's servers once the application launches. Also, our Terms of Service used to specify that the Maps API could only be used for online web applications.

Now that both the API and Terms of Service have undergone a facelift, we are releasing the first version of the API that will allow Flash/Flex developers to bring Google Maps to the AIR runtime.

Developers who are already familiar with creating online applications with the Google Maps API for Flash will find it easy to start using the API for their AIR apps. Just about the only difference is the use of the url parameter of the map class. Developers creating normal online applications sign up for a key corresponding to the URL of the SWF, but developers creating AIR applications must sign up for a key corresponding to the URL of the page that the application can be downloaded from. While instantiating a map, AIR developers will need to provide both the key and that url in the key and url parameters of the map, respectively. For more information (and screenshots!), read through our snazzy new tutorial on developing AIR apps in Flex Builder.

For a few examples of using the API with AIR, check out the demo gallery. One example is the "Map CSV Parser", which is based on the great text-file editor example from the Adobe docs. This AIR app lets you open or drag a CSV file, and then it parses it into draggable markers on to the map. The new positions of the markers can be saved into the same or new CSV file on the file system. It's just a few lines of code, but should give you an idea of the kind of powerful interaction possible between a Map and a Desktop. Click the screenshot or here to view and download the source for that example.

We are looking forward to seeing your ideas and your AIR apps! As always, please follow up with your suggestions and questions in the forum.

There are two recently released additions to the articles section of the documentation, for two completely different audiences. Check them out below:

Using PHP/MySQL with the Google Maps API for Flash By Pamela Fox Are you a developer accustomed to developing mySQL-driven websites with PHP? Do you want to learn how to use the Google Maps API for Flash with dynamically loaded data? This article goes through the steps of creating a mySQL table, populating the table with data, using PHP to generate XML from that mySQL table, and finally, writing the AS3 code to dynamically load in the PHP-generated XML and display a map with multiple markers and custom icons. After going through this tutorial, you should be ready to extend what you've learned to your own databases. Click here to read!

Creating Custom Google Maps API Icons By Pamela Fox Are you a Photoshop junkie who wants to create the perfect GIcon for your map mashup? Are you struggling to figure out the best settings for the shadow and print images? This screencast (Flash player required) goes through the process of creating icons, covering each of the GIcon properties in detail. You can also download all the sample files (PSD/JPG/PNG/GIF) used in the screencast. After going through this screencast, you should be ready to extend what you've learned to your own crazy unique icons (Hello Kitty, anyone?). Click here to read!

The articles section now also includes links to a few external articles that we found really useful: Thematic Mapping with the Google Maps API for Flash, and Creating Custom Campus Maps using the Google Maps API. If you've written an article about the Google Maps API that you think would benefit developers reading our documentation, please let us know.

One of the first concepts I explain to developers that are new to mapping APIs is geocoding: the process of converting an address into a latitude/longitude pair. Approximately 99.9% of developers will have to use a geocoder before they can get their data onto a map, and to let users of their map locate themselves. Thankfully, we offer both the HTTP Geocoding service for server-side geocoding (the former), and the GClientGeocoder class for client-side geocoding (the latter).

Now, let me introduce the more advanced topic of reverse geocoding: the process of converting a latitude/longitude pair into an address. A much smaller (but important) percentage of developers will want to use a reverse geocoder to let their map users know the address for a particular point on the map, perhaps to help them fill in a form faster (why type when you can click?!). For those developers, we're now pleased to offer address-level reverse geocoding support to both our HTTP service and the GClientGeocoder class. To make it super easy to use, the interface for reverse geocoding is nearly the same as forward geocoding - the only difference is sending in a lat/lng instead of an address. Here's a code snippet for doing client-side reverse geocoding, taken from this sample:

geocoder.getLocations(latlng, function(addresses) {
  if(addresses.Status.code != 200) {
    alert("reverse geocoder failed to find an address for " + latlng.toUrlValue());
  } else { 
    var result = addresses.Placemark[0];
    map.openInfoWindow(latlng, result.address);
  }
});

As a live demo of the reverse geocoder, check out MeetWays, a site that mashes up the Google AJAX Local Search API with the Google Maps API and just a bit of math. It calculates the point between two addresses on the map, uses the reverse geocoder to find out the address for that point, and then does a local search near that address to find places to meet that are halfway between. Since reverse geocoding works in all the places that forward geocoding works, then you should be able to meet up with your friends in more than 70 countries.

For more information on this new service, read through the reference and sample code. We'd love to see the ways that developers will use the reverse geocoder, so please post a link to your reverse geocoding demo or website in the forum. Now go forth and reversify!

Back when we announced the "Google Maps API for Flash" in May, there were a large amount of Flash CS3 developers who were miffed at our lack of support for using the API in their favorite program, and quickly made "Flash CS3 Support" the second most starred feature request -- and there was even one developer named Vincent who managed to get our SWC running in CS3 who quickly became a one-man support desk for his hack. Well, Vincent, it's time to take a vacation, and CS3 Developers, it's time to get to work. The 1.7 SWC can now officially be used as a Flash CS3 Component, and the documentation now includes a snazzy screenshot-filled tutorial about creating your first map in Flash CS3.

To show that off, I made the kind of demo that one can only truly be done in Flash - a Google-ified re-envisionment of a scene from my all-time favorite movie, Puff the Magic Dragon. Click the screenshot to check it out. Warning: Watch this scene (5:20) first if you've never seen the movie, or you'll think I'm a bit crazy. I mean, you might think so anyway. But still.

Now — before Flex developers think that we've forgotten about them — I've got more news. The 1.7 SDK now includes a special SWC for Flex developers, and the documentation includes tutorials for creating your first Map with this SWC in both Flex SDK and Flex Builder. Using this SWC means that you can set up the map as a custom Flex component, and then use any Flex components on the map in controls, info windows, markers, etc (something that was previously not possible). To show that off, I made a demo that embeds a TabNavigator inside an info window to make tabbed info windows. Click the screenshot to check it out.

And there are a few extra features for everyone, like TileLayerOverlay, ScaleControl, Geodesic Polylines, Walking Directions. Check out the demo gallery for examples of those, and read the docs for more information. Enjoy 1.7, and let us know in the forum how you're using the API or if you have questions.

Back in May, we released a feature in Google Maps that let users toggle on additional "layers" of information on top of the map, starting with Panoramio and Wikipedia options. Both of these layers display thousands of variably sized icons on top of the map, and open info windows with more information about the clicked icon. So the user might click a large "W" in New York to read a snippet from Wikipedia's article about the Empire State Building, or they might click on a thumbnail in Black Rock City to see a photo of a Burning Man Temple.

Now, for those of you who want to easily enable these layers on your map (or through a custom control), you can create a new Layer object with the specified layer ID, and then add that to the map as an overlay. Check out the sample code and demo below, and read through the docs for more info:

map.addOverlay(new GLayer("com.panoramio.all"));
map.addOverlay(new GLayer("org.wikipedia.en"));

Note: There are localized versions of the Wikipedia layers available in many languages. These will not be automatically served to users based on browser setting, so you should explicitly add those if your map is targeted at a local audience. See this spreadsheet for a full list of IDs.

For those of you developers wondering how these layers are able to display so many icons without slowing the browser down, here's some inside info for you. The layers are actually implemented as GTileLayerOverlays, where the tiles are just transparent PNGs with icons baked into them. The clickability of the layer is achieved by passing information about the clickable pixel bounds of each tile to the client, then doing a client-side check to figure out which bounds the cursor is inside on the map mousemove and click events, and changing the cursor or popping up the appropriate info window. If you're interested in implementing a similar solution for your own thousand-markered mashups, check out John Coryat's clickable tilelayer demo in the demo gallery, or the various presentations on creating custom maps.

Back when I was attending high school in Syracuse, NY, I did the typical teenager thing and learned how to drive a car. Syracuse is a (relatively) large city in the middle of upstate NY, so getting from point A to point B could either mean driving down winding country roads and passing by Llama Farms (true story) or driving on multiple highways to get to our nearly-biggest-mall-in-America/most-polluted-lake-in-NY (yep, its at the same location.. go city planners!).

I quickly learned that I loved country roads (who doesn't like llamas??) and hated highways, but since everyone around me were highway-lovers, it was near impossible to get directions to places that didn't involve highways. So that's where Google Maps, and now the Google Maps API, becomes my new best friend. By specifying avoidHighways in GDirectionsOptions, I can find a route that avoids highways. Click the screenshot below to check it out.

Fast forward 5 years: I've moved to the bay area to start my job at Google, and I realize that there aren't really many country roads left, and pretty much all routes involve either a highway or intersections. I should probably mention that I eventually learned in Syracuse that I hate intersections: left turns, right turns, they all freak the gajeezus out of me. So I decided that I'd walk everywhere possible, and seek housing in highly walkable areas. So once again, that's where Google Maps and the API help me out. By specifying G_TRAVEL_MODE_WALKING in GDirectionsOptions, I can get walking directions from my apartment to the nearest "beverage" store. Click the screenshot below to check it out.

Note: Since walking directions may sometimes not include clear pedestrian paths, we need to make sure that your users take caution when using them. So, walking directions are only supported if you have supplied a <div> in the GDirections constructor; this <div> is used to display a warning to the user in the turn-by-turn textual directions.

If that piqued your interest, read through the updated Developer's Guide and API Reference. As always, post in the forum with any questions you may have.

Sometimes there's functionality that's ridiculously useful for a niche group of developers, and completely unnecessary for others. That's the kind of functionality that's now available in our brand spanking new "Google Maps API for Flash Utility Library" open-source project, and is ready for developers to use, modify, and even improve.

Our 3 inaugural libraries are:

	MarkerManager: This library is an AS3 port of the MarkerManager in the JS open-source library. It enables developers to easily manage markers per zoom level/viewport, and is commonly combined with clustering. Though Flash is natively better at rendering large amounts of markers, developers have reported increased performance when using the MarkerManager with thousands of markers.
	KML Parser: This library parses a KML file into objects representing the KML DOM, and includes helper code for turning them into map objects (Marker, Polygon, GroundOverlay, etc) and creating a sidebar using the Tree list Flex component. Note that this class ignores elements and attributes that can't be rendered in the Maps API for Flash.
	Planetary MapTypes: This library contains map types for Mars, Sky, and Moon, and is a port of all the non-earth map types available in the JS API. This will help you make your maps application out of this world.

To check out the docs and demos for each library, visit our Libraries wiki. If you end up using any of the libraries for your own projects, please let us know in the forum.

For information on contributing patches or libraries to the project, visit our FAQ. To all of you talented AS3 developers (I know you're out there; I've seen you in the group!), I hope that you consider adding to our central repository of helpful add-ons for the Maps API for Flash.

So, it appears that a few thousand of you developers were sending our static map server requests with "&maptype=satellite" in them. Why would you do that? Did you think that we'd see all the requests and just decide to start returning satellite imagery to you? Well, fine. You were right. Here you go:

And just to anticipate those of you who are thinking to yourself about what a mighty fine plan that was, and how you're going to start sending "&maptype=hybrid" and "&maptype=terrain", here, have those map types too:

Okay? Happy now?? Statistically, many developers should be — since "add other map types" has been our top starred static maps feature request in the public issue tracker since the launch of the Static Maps API.

So check out the documentation and start using the new map types for your thumbnail maps, mobile maps, or any of the other reasons we mentioned in our last static maps post. You can also check out the other goodies in this release in the Static Maps API changelog. Enjoy, and let us know in the forum if you have any questions (or just nifty examples to share with us).

In the first release of MapIconMaker, we gave developers the ability to create dynamically resized and colored marker-shaped icons. Now with the second version, we're adding two entirely new types of customizable icons. The table below (stolen blatantly from the documentation) compares the three available functions. To get more of a feel for everything that's possible with all the icons, play around with the updated wizard.

createFlatIcon	The icons can be dynamically sized and colored, can be either circular or rectangular in shape, and can have text overlaid on them. They will appear to lie 'flat' on the map because of their shape. View example (createflaticon-simple.html).
createLabeledMarkerIcon	The icons can be dynamically colored and can have text overlaid on them, but can only be one shape and size (marker-shape, 32*32). They can optionally have a dynamically colored star attached to the corner. View example (createlabeledmarkericon-simple.html).
createMarkerIcon	The icons can be dynamically sized and colored, but cannot have any text overlaid on them. View example (createmarkericon-simple.html).

As a demo of what kind of maps are possible with the new icons, I've created a gadget that uses the Visualization API to pull rows of U.S. address data from a Google Spreadsheet, clusters the rows based on what state code I find in the address (yay for RegEx!), and then creates icons for each state cluster that are dynamically sized and labeled according to the size of the cluster. As an added touch, I overlay a transparent state polygon on marker mouseover, and I change the color of the marker and polygon on marker click. Much thanks to the 2008 Election Trends map for inspiring the UI and making its code and states data available.

Check out the demo map below, and if you're inspired yourself, read through the MapIconMaker reference and documentation (or code - it's open source!).

A lot of map mashups out there have country-wide or world-wide content. That's awesome because it means there's something for everyone. What's not so awesome is that it means that when I get to the map, I often have to spend some time panning and zooming until I'm in my hometown and seeing the local content I'm most interested in. And as you know from previous posts, I'm inherently lazy and get bored whenever I'm forced to engage in unnecessary mouse movement. Wouldn't it be better if the map could automatically center to my location without me lifting one of my precious fingers? The answer is yes, and now it's easier to do than ever with the introduction of IP-based location information in the AJAX APIs framework.

To add user-based centering to your map mashup, follow the steps below.

1. If not using it already, include a <script> tag for the AJAX APIs common loader. Call google.load("maps", "2").
2. Once the Maps API has loaded, check if the google.loader.ClientLocation object has been defined. If so, you can use the latitude/longitude and city/state/country information from it to center the map and display the sensed location to the user.
3. If the ClientLocation object is null, just center your map as always. Not all IPs can be located, so you'll want a good fallback behavior.

Check out the example implementation below, but feel free to make your own implementation snazzier (perhaps by adding a GControl to let the user easily jump to their location):

For more information, read the docs on using the AJAX Loader and using ClientLocation, or post in the AJAX APIs group with questions. If you're developing a mobile website and want a more precise location for your users, check out the GeoLocation module in Gears.

Before we release a new version of the Maps API, we always run it through a huge bank of tests to make sure standard functionality is working. But one thing we've realized since releasing the Maps API and watching its adoption is that it can be used in ways that we never imagined - and subsequently, ways we never thought to test.

So we figured the best solution would just be to let you, the creative developers, tell us exactly what functionality you want tested - by adding your own tests. We've open sourced our integration tests and are now ready to accept contributions. Our infrastructure allows us to run these tests on the stable, current, and bleeding edge versions of the API, so that potential problems can be discovered long before they are out in the wild.

The tests we have released use Selenium. Selenium is an open source tool for automating tests of human-browser interaction. It runs in a range of browsers, so by its very nature it takes into account browser discrepancies. As an added benefit, developers can run tests by simply going to a url and clicking a 'run' button!

The screenshot below shows our basic test running (and passing, whee!):

Note that we have hundreds of non-Selenium unit tests for expected functionality, but we're not releasing those just yet as they're more tightly coupled with Google infrastructure.

For information on running and contributing tests, read the project wiki. Thanks for reading, and we look forward to your contributions.

Good arvo from Sydney, Australia, where it's beautiful even in the dead of winter and the people use contrived abbreviations for literally everything. I kid, I kid. Australia is great, and the vegemite is even greater. I've spent my winter internship (also called a "summer internship" for my compatriots above the Equator) working on the Google Maps API for Flash, which was released back in May. If you're like me, you might think that Flash is a tool for creating amateur cartoons of questionable legality after school. Friends, I assure you -- it's so much more.

JavaScript developers have reaped the benefits of driving directions in the Google Maps API for over a year now, but without them Flash developers have endured three long months of repeatedly getting lost. As someone who accidentally drove into Oklahoma for well over an hour before realizing that his roadtrip only involved Texas, I feel your pain, Flash folk. But worry no longer, for I bring good news. It has been my pleasure to rectify this disorientation dilemma and bring the enormous utility of driving directions to our Maps API for Flash, starting with version 1.6.

The interface for the Flash API's Directions class closely resembles that of the JS API's GDirections class. You still create a Directions object, optionally listen for load/fail events on it, and then call the load() method with a directions query. The Directions object contains all the response information as Route and Step objects, also like the JS API. The awesome thing about Flash is that you can then include all sorts of animations and movie clips to complement the directions in your application. Consider the following application which uses a penguin to show you how to get from the Alamo Drafthouse movie theater to Waterloo Records in Austin:

Sure you could probably whip that up in a JavaScript application, but envision this scenario: an animated car traverses the route of your roadtrip; your videos are overlaid onto the map at their original shooting locations; and your meticulously selected playlist of driving music plays chronologically in the background. And that, my friends, is the power of Flash.

Hi, I’m Sterling Quinn and I work on the development team for server-based GIS technologies at ESRI in Redlands, California. We’re happy to report that ESRI software users can now expose their GIS in Google Maps through the recently-released ArcGIS JavaScript Extension for the Google Maps API. The extension is built on the Google Maps API and is designed to communicate with ArcGIS Server, ESRI’s product for serving GIS functionality on the Web.

The ArcGIS JavaScript Extension for the Google Maps API allows you to maintain the user-friendly front end of Google Maps while tapping into an advanced GIS on the back end. You can use the extension to display your own maps on top of Google’s, query features in your database and display them on the map, or expose tasks that run GIS analysis models on the server. You can display your results using the Google Maps API’s native graphics engine and info windows.

To learn how to use the ArcGIS JavaScript Extension for the Google Maps API, use the online SDK, which contains basic concepts, an API reference, and examples of how to create custom maps and Mapplets. The examples contain detailed descriptions on how to do things like adding an ArcGIS Server map type button, displaying query results as KML, or running a task on the server to return a route and elevation profile.

Following are some quick links to example Mapplets built with the ArcGIS JavaScript Extension for the Google Maps API. For those of you who don't know, Mapplets are mini applications that you can add to Google Maps in the “My Maps” tab and are nifty because a user can enable multiple Mapplets at a time.

	Cached Map Service Displays an ArcGIS tiled map service over the Google base map. Add this Mapplet to Google Maps Learn how this Mapplet was created
	Census Block Query Retrieves US Census data from an ArcGIS map service at a point you click and displays it in a series of charts created with the Google Chart API. Add this Mapplet to Google Maps Learn how this Mapplet was created
	Message in a Bottle Uses an ArcGIS geoprocessing service to tell you where a bottle would drift if you dropped it in the ocean. Add this Mapplet to Google Maps Learn how this Mapplet was created
	Service Area Analysis Uses an ArcGIS geoprocessing service to display drive time polygons from a point you click. Add this Mapplet to Google Maps Learn how this Mapplet was created

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.

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 = "http://maps.google.com/staticmap?key={$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 = "http://maps.google.com/staticmap?key={$key}&size={$w}x{$h}¢er={$north},{$lng}&zoom={$z}";
$south = "http://maps.google.com/staticmap?key={$key}&size={$w}x{$h}¢er={$south},{$lng}&zoom={$z}";
$east = "http://maps.google.com/staticmap?key={$key}&size={$w}x{$h}¢er={$lat},{$east}&zoom={$z}";
$west = "http://maps.google.com/staticmap?key={$key}&size={$w}x{$h}¢er={$lat},{$west}&zoom={$z}";

To see the site in action, go to http://m.lonelyplanet.com 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 developer.lonelyplanet.com 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?).

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: Booking.com (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 Opt.be (this one links to a maps.google.com 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).

The Panoramio API lets you specify a bounding box query, sort by popularity, and output its data in JSON format. The MarkerManager lets you specify marker batches per zoom level ranges, and only displays the markers for the current viewport. Using these features, we can then do the following:

1. Create an empty MarkerManager.
2. Create an empty hash table to store photo ids.
3. Assign a listener to the map "moveend" event. This function calls the Panoramio API, sends in the current bounding box, and asks for the 10 most popular photos. The query looks like this:

   http://www.panoramio.com/map/get_panoramas.php?
   order=popularity&set=public&from=0&to=10&
   minx=-124.29382324218749&miny=36.089060460282006&
   maxx=-119.8773193359375&maxy=38.724090458956965&
   callback=MyCallback
   

4. When the query responds, iterate through the results, and for each result whose ID isn't already in the hash table, add it to the MarkerManager for the current zoom level, and add it to the hash table.

The effect to the user is that additional photos stream in and populate the map as they zoom in - check it out below or here. You can use this technique whenever you have a database that can be queried by bounding box and rank the results.

But if you want to just put a Panoramio button on your site, you can copy the code & scripts from this example. If you're a Panoramio user yourself, you can actually restrict the layer to only your photos by passing in your user ID to the API call. Developer Ade is experimenting with this on his ibizaA-Z site in order to just display his Ibiza photos.

Until then, you can watch all the I/O presentations in full Youtube glory. The Maps API and KML presentations are in the player below, and the full list of the 70+ presentations (with some links to slides) is here. You can also check out our photo album from the event (I've never felt so dwarfed by a marker before), and the panoramas that Jeffrey took at the event (I've never met a chocolate fountain I didn't like :).

They also happen to take advantage of almost every Geo API that we have! We were fortunate enough to have them at Google I/O last week, so we could sit with them and discuss how they do what they do.

To cut to the chase, you can watch the entire set of interviews and demos in one go, or you can jump around using the playlist custom viewer below. I happen to be a huge fan of their use of the new Flash API as they "flip things inside out":

We talked about a really varied set of topics. Not only did we discuss their usage of the APIs, but we got into how they manage to deal with these huge images, how they stitch them together, and how they even manage to get so many of them.

You will see the process, how their data center started in a closet in Boston, how Lurch from the Adams family is one of their photographers, and the importance of the BBC Model B.

Thanks so much to Jeffrey and David Martin for joining us. A real pleasure.

2D Driving Simulator on Google Maps is a personal project of mine. With the power of Google Maps, you can drive around the world without having to worry about spending money on expensive gas. And it is using the brand-new Flash API which Google released two weeks ago.

My original 2D Driving Simulator is a Flash toy that simulates car parking and trailer movement. In my second release of the toy, I added in wide courses to make it a bit more fun (and less crash-prone). When I tried to add in more natural courses and realized how difficult it was, I decided to test out using the real roads of Google Maps as a backdrop.

At the time of that decision, the Google Maps API was only available in Javascript - so I actually had to find a way to overlay the Flash toy on top of a Javascript map and synchronize them. Amazingly, it actually somewhat worked. Unfortunately, it's 'success' relied on the troublesome wmode=transparent Flash parameter, and on having to call JavaScript from Flash 20 times a second (certainly not a typical thing to do).

So, the release of the Google Maps API for Flash was truly happy news for me. I implemented it right away. It was easy to replace the JS API; it only took a few hours. All I had to do was to add a com.google.maps.Map child on the main Sprite, copy the JavaScript functions to ActionScript, and adapt them according to the API's minor differences.

The result is very impressive: there is both an increased frame rate (from 15-20 fps to 40 fps) *and* a decreased CPU usage. Moreover, the map perfectly follows the vehicle's movement. Quite natural!

The Google Maps API for Flash has enabled us developers to create real-time Google Maps applications. I believe this excellent API has unlimited potential and look forward to using more of it in the future.