[Note: The Places API is now generally available to all developers for use in any app. For more information please see the launch blog post - May 10th 2011]

At the Google I/O developer conference earlier this year we previewed the Places API, a new service that will allow applications to search for Places, and obtain detailed information about individual places selected by users. At that time we posted documentation and provided an Application Form that developers can use to indicate their interest in using the API.

We have been delighted with the enthusiasm we have seen for the Places API, and the innovative ways in which developers would like to use it. We have seen applications that offer check-in to places and need to identify an individual place at which a user is currently located, applications looking to show a user Places around them, and applications looking to offer a search and browse experience for Places similar to that offered on Google Maps.

We are going to focus initially on check-in applications. These are the applications that we feel the API currently caters to well, and we are excited to work with developers building these applications to understand their requirements, and ensure that we are offering them the best possible experience.

When we previewed the Places API back in May we indicated that we planned to begin processing applications in July. I’m happy to say that we have now begun reaching out to developers who have expressed an interest in building check-in applications using the API, including those working on client applications for the Buzz API.

If you have already applied to use the Places API and you feel that your use case fits this initial focus, please log back in to the Application Form and ensure that your description makes this clear. To manage usage we will be issuing credentials to developers in stages, so please do not worry if you do not hear from us immediately.

If your requirements extend beyond the check-in use case, please bear with us and we will be in touch once we are confident that the API can effectively meet your needs.

The following is a guest blog post by Kevin MacDonald of ThinkWrap Solutions

We're coming to you live from the Michigan International Speedway, where the Progressive Insurance Automotive X PRIZE (PIAXP) competition is underway.

This competition will award $10 million in prizes to the teams that win a rigorous stage competition for clean, production-capable vehicles that exceed 100 MPG energy equivalent (MPGe).

Vehicles are equipped with telemetry sensors and a GPS that together capture the following key performance indicators (KPI): fuel consumption, CO2 emissions, carbon footprint, speed, distance travelled and location.

ThinkWrap Solutions partnered with PIAXP to build a web experience that lets you monitor these KPI -- second-by-second -- from the comfort of your web browser.

The web-based experience is centered around a dashboard, a Flash application that embeds a number of telemetry gadgets, each responsible for the display of one KPI.

A Google Map is central to this experience, which uses a combination of location and horizontal dilution of precision (HDOP) to show the vehicle's movement around the track.

It's quite a novelty to be present at the Speedway, to watch the vehicle's icon round a turn on the map -- and then look away from the browser and to the track to see the actual vehicle approach and pass by.

To enjoy this experience, visit the official website, to meet the teams and their vehicles. (Check this video to see the map and telemetry data in action.)

Race times and vehicles are updated daily and posted at this page. Click on one of the vehicle photos on this page to view its telemetry data, and track its progress as it races around the racetrack, live on a Google Map!


Our first challenge was to make sure that the map accurately tracks the vehicle's movement around the track. Although a GPS reports latitude and longitude coordinates to a precision of a few feet, availability of GPS satellite signals and atmospheric conditions can affect coordinate accuracy. Without concern for this accuracy, the map might show a vehicle hopping around the track, up on to the stands, over the stands and into a nearby farmers field!

We all know that GPS coordinates include latitude and longitude. GPS also measure the accuracy of these horizontal coordinates through a metric called Horizontal Dilution of Precision (HDOP) which for us, varies from 1 to 50 (1 is best and 50 is worst).

The map plots the coordinates on the map only if HDOP is 3 or less. If it's greater, the vehicle icon does not move. After 30 seconds, the icon is removed from the map.

Another challenge was to economically satisfy the clients' real-time demand for data, especially under conditions where a media blitz attracts tens or hundreds of thousands of visitors. Data flow -- from vehicle to website -- involves many intermediate stages: each vehicle independently broadcasts its KPI through a Sprint cellular connection, second-by-second, to a central server. Every second, this server batches KPI records across all reporting vehicles, and pushes, as a POST request, through a REST interface to a Java-based server running on Google App Engine. This server then caches the data in memory, and stores a copy in Datastore.

Client applications, which display the dashboard, poll for new data from Google App Engine through another REST interface. If the request hit the servlet that originally received the KPI from the vehicles, the request is serviced from a cache. Otherwise, the servlet needs to query the Datastore, cache the data and then reply to the client.

The client receives a batch of KPI data for the last 10 or so seconds, which it plays back through the dashboard, one record per second. When the client's buffer is nearly empty, it requests another batch of new data and continues, rinse-cycle-repeat.

Although the clients play back KPI data from a few seconds ago, collectively, they place much less burden on the server, and maintain sufficient buffer so as to minimize interruptions when updating the map.

We built our map on the Google Maps API for Flash platform, primarily due to the maturity of its software development kit (Flex Builder), relative ease of development, and cross-browser support.



The release of Google Earth 5.2 had a lot of new features, so many that we had to write three different blog posts just to cover it all. Well, OK, four with this one. One of the most exciting features from a developer standpoint is the new KML extension, <gx:Track>.

We wanted a better way to represent movement on and above the globe. Time animation works well, but from a KML standpoint it required very bulky files. In order to “move” a <Point>, you created a new <Placemark> for each time segment. Your <Point> didn’t actually move, it merely was replicated at a different place. This made animating your path rather cumbersome. Instead, we wanted a smoother experience, and one that allowed you to truly animate a <Geometry>. So, we created <Track>. To get a real sense of the power of <Track>, check out this video.

As you can see, a <Model> (a <Model> is a <Geometry> in KML) of an airplane moves smoothly along the <Track>. Let’s take a look at some KML:

<name>My  first  track</name>
<when>2010-04-07T23:32:11Z</when>        ...      <gx:coord>-83.671639  1.675732  7.827881000000001</gx:coord>
<gx:coord>-83.67233299999999  1.675678  4.943848000000001</gx:coord>
<gx:coord>-83.672904  1.67574  3.982666</gx:coord>
<gx:coord>-83.67346499999999  1.675781  4.463257</gx:coord>
<gx:coord>-83.67400600000001  1.675855  3.501953</gx:coord>
<Model  id="model_2">

Track is a parallel array. The first <when> element matches the first <gx:coord> element, the second with the second, and so forth. The <when> element identifies the point on the time slider, and the <gx:coord> the matching location. Google Earth draws a line between each position visible in the time slider. Track also supports <gx:angles>, which allows you to define the heading of a model at any point along the way. If not defined in <gx:angles>, Google Earth will change the orientation of the Model based on the direction between the current position and the one previous.

Since you’re only creating one Track element, instead of re-creating a bunch of <LineString> elements for every time segment, your KML files will be much smaller. In fact, the more coordinates you have, the more benefit you’ll see from it.

One more feature that is really compelling is that you can add <gx:SimpleArrayData> elements to <SchemaData>. <gx:SimpleArrayData> allows you to add a matching array of your own data. In the sample posted here heart rate, cadence and power are added to each point, and when Elevation Profile is turned on in Google Earth, it allows you to view that data as well, as you can see below.

For more information, check out the session Josh Livni and I did at Google I/O, and the KML reference for <Track> and <MultiTrack>.

Mano Marks, Geo APIs Team


Six months ago, we released a bevy of new articles to help with your coding through the dark winter months. OK, they were not so dark South of the equator, but here in Mountain View, well, it rained a few times. Anyway, now that it’s winter South of the equator, and for all of you developers in the North who can’t go out in the sun, we have released your summer reading list. These articles are hot off the digital presses, so enjoy them while they’re fresh.

Fun with MVC Objects

This article presents a basic introduction to using MVC objects within V3. You will learn how to use the Maps Javascript API V3 MVC framework to create objects that automatically respond to state changes. You will build a resizable distance widget and by the end, you'll have a greater understanding on what MVC objects are, how to use them, and why they're just so "awesome".

Geocoding Strategies

Ever wondered whether you should use client-side or server-side geocoding? Actually, if you haven’t, you should and this article is for you. In it, you’ll learn why client-side geocoding is so cool, and when and even if you should ever use server-side geocoding.

Using Google Sites to Host Your KML

A couple of years ago, we released an article on hosting KML on Google Pages. Well, Pages is no more, and has become Google Sites. This is an article for a beginning developer who just wants to put their KML up on the web.

External Article: Google Maps API v3: Developing for Mobile Devices

Chad Killingsworth, who presented with me at Google I/O in our Map once, map anywhere session, has a great article up summarizing some of the lessons he has learned about developing Google Maps API applications for V3. We added a link to his article on our articles page for the Google Maps API.

So enjoy your summer reading! We’re doing our best to prevent your sun burn.