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.

Posted by Thor Mitchell, Maps API Product Manager

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!

Challenges

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.

Enjoy!

Posted by Kevin MacDonald of ThinkWrap Solutions

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:

<Placemark>
<name>My  first  track</name>
<styleUrl>#mytrackstyle</styleUrl>
<gx:Track>
<altitudeMode>absolute</altitudeMode>
<when>2010-04-07T23:30:55Z</when>
<when>2010-04-07T23:31:13Z</when>
<when>2010-04-07T23:31:32Z</when>
<when>2010-04-07T23:31:52Z</when>
<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">
   ...
 <Link>
   <href>/Users/mmarks/Documents/track.kmz/files/mymodel.dae</href>
 </Link>
</Model>
</gx:Track>
</Placemark>

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.

Mano Marks, Geo APIs Team

Today is an important milestone here at Google and we’re all pretty excited - the Google Maps API turns 5! It was five years ago today that we posted a brief announcement to let the world know about the JavaScript Maps API and now 5 years later more than 350,000 active websites make use of it. Uses have ranged from tools that have made it easier to find an apartment, track the Gulf of Mexico oil spill and even make an Earth sandwich! Many, many more examples have been chronicled on sites like Mashable and the Google Maps Mania blog.

In 2005, Adrian Holovaty launched the first crime mashup that overlaid Chicago’s public crime data onto online maps providing Chicago’s citizens and journalists with a true picture of crime in their city. The site won the 2005 Batten Award for Innovations in Journalism and was named by The New York Times as one of 2005's best ideas.

In honor of this very special birthday, we took a chance to check back in with Adrian to see what he thought about the journey of the Google Maps API over the past 5 years:

Of my 11 years of doing Web development, Spring 2005 was the most interesting and exciting time. When Google Maps launched -- with maps assembled client-side, in JavaScript! -- I was one of the band of tinkerers around the globe who poked at Google's obfuscated code until we figured out how to embed their maps in our own pages. It was a ton of fun, not only doing the reverse engineering, but seeing the various discoveries and hacks other people were making: embedding multiple maps in a single page, swapping out the map tiles, using custom map markers, making markers move, loading real-time data onto maps... New discoveries were being made on a seemingly daily basis, and the best ones built on the other ones, which led to a sense of a community contributing to a greater understanding.

These days, it's hard to fathom a Web without embeddable maps. Wasn't it always that way? To Google's eternal credit, instead of shutting these hacks down, they recognized the demand and legitimized it in the form of their mapping API.

And the rest is... well, kind of boring in its simplicity, now that reverse engineering isn't involved. There was something raw and pure about those original hacks, like hunting and skinning your own food, living off the land, a digital self-sustainability. I feel like an old man yelling at kids to get off my lawn: ‘Back in my day, I had to reverse engineer Google's obfuscated JavaScript to get embeddable maps on my pages!’ You don't know how good you have it.”

The Google Maps API has seen some significant milestones of its own during the past five years. Some of the announcements we’re most proud of are the Maps API for Flash, Static Maps API, our Enterprise offering Maps API Premier, and the new Maps API v3, built with mobile use cases in mind and recently graduated from Code Labs.

The Google Maps API has established itself as the most popular Google API and the most deployed service-based API on the web. We continue to be amazed by how popular this API continues to be for web and mobile apps being developed today. This ProgrammableWeb dashboard shows that of the apps built and submitted over the past 2 weeks, a quarter of them make use of the Google Maps API. Click the 'All Time' tab and you'll see that nearly half of the almost 5000 cataloged mashups use it.

Today, on this 5 year milestone, we really have all of you to thank for this incredible chapter in web and mapping development. The remarkable levels of innovation, creativity and interest have come from all of you. You saw the possibilities the Google Maps API held and what it could be combined with to create, and you built it. Now join us to celebrate! Keir Clarke from Google Maps Mania has created a mashup that we want all of you to contribute to. Since we can’t all share a giant cake, I think it’s fitting that we all build a giant mashup of mashups to mark this special API birthday. Please tag your Google Maps mashup or tool to the map wherever you are:

We’re looking forward to the next 5 years of mapping innovation together with all of you!

Posted by Mike Pegg

Last year, we launched the Google Qualified JS Maps Developer Program. This qualification, and your inclusion in the directory, will help interested parties contract with you for their geo development projects. Hot on the heels of the Maps API V3 graduation we are now announcing an update to the program which now includes JS Maps API V3 Developer Qualification. What does this entail, exactly?

The Google Qualified Developer program uses a version release and points threshold strategy rather than setting an absolute term on earned qualifications. Instead of picking an arbitrary duration such as one year, developers have the opportunity to continuously earn points towards their qualification by resubmitting assignments and assisting with exam updates and testing.

Current JS Maps API developers earned a minimum of 3000 out of a possible 5000 points in order to become qualified. To earn these points, they submitted practical evidence of their programming capabilities by writing applications, demonstrated their commitment to the developer community, supplied professional references, and passed the JS Maps API Exam.

Now that JS Maps V3 has been released, the developers who did not participate in early testing have been notified of potential points expiration. Developers will have 30 days to take the new V3 exam, and submit new applications using the V3 API. To read more about the program, take a look at our site. We look forward to expanding our API support and growing the Developer Qualification program. Please reach out to us with questions and feedback at devqual-proctors@google.com.

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

(Cross posted from the Google Code Blog)

Thanks from the Geo API team for a making Google I/O a great event yet again! We really look at I/O as being for developers by developers, so each year our API engineering team makes the pilgrimage from Sydney, Australia to personally present the new APIs and features they’ve spent most of their time working on. These features and new APIs are, in most cases, requested by the Maps API community so it’s a real thrill for us to deliver on these requests in person.

For those that were unable to make it, we’ve got you covered! The following is a summary of the key Geo API announcements that were made, along with a link to each session page that (as of today) now includes full videos and presentation materials. To bookmark all Geo sessions, use this YouTube playlist. Refill the coffee and get comfy!

• Stepping up: Porting v2 JavaScript Maps API applications to v3 - We got right to it with this lead off session by Dan Lee who steps you through the ease of converting your Version 2 Maps API implementation to V3. In this session we also officially graduated V3 from Code Labs to make it our default Maps API version!


• Where you at? Connecting your users with the places around them - This session saw the official launch of the Latitude API and the preview of our forthcoming Places API Web Service. Places API launch partner Booyah even took the stage to demonstrate how they are implementing this new API into their geo-social gaming app.


• Moving beyond markers: Advanced Maps API customization - Prepare to be entertained as Jez Fletcher and Dave Day introduce you to our brand new Styled Maps feature which lets you customize the look and feel of the base Google map tiles!


• Fireside chat introduces Directions Web Service - The fireside chat format is a great chance to engage directly with geo developers and discuss the issues that are most important to them. We thought this was a great setting to deliver on our #1 most requested feature according to our request tracker: The new Directions Web Service!


• Mapping in 3D: Tips and tricks for Google Earth API and KML - Our resident KML and Earth API experts Josh Livni and Mano Marks took the stage in this talk to go deep on ways to integrate large datasets efficiently. They also announced several new features for the API including a very popular Google Earth feature: Historical Imagery! Take a look at these new features in the Earth API Developer Channel.


• Map once, map anywhere: Developing geospatial applications for both desktop and mobile - The days of maintaining several geospatial applications for several mobile and desktop platforms are gone! Mano Marks explains how to standardize with one implementation for both mobile and desktop, using the Maps API v3.


• Unleash your map data: Cloud computing for geospatial applications - Tom Manshreck takes you on a full tour of the Maps Data API to explain how this Geo API can be used to store and search against your geospatial data in the cloud (efficiently).


• The SketchUp 3D API: Working with 3D geospatial data - In this session Matt Lowrie shows you how to extend one of the most popular 3d modelling applications in the world using the SketchUp 3D API.


• How Maps API v3 came to be: Tips, tricks, and lessons learned in developing a cross platform desktop and mobile API - The Maps API v3 was a theme of our Geo track at I/O this year. We ended the event the same way we opened it, by giving developers a chance to learn from our experience in creating a fast, efficient Maps API v3 built for speed and mobile use cases.

As our new and existing Maps APIs continue to evolve we would love to stay connected with you. Be sure to join our Google Group, check out the Geo Developers Blog or follow @GoogleMapsAPI on Twitter!

Posted by Mike Pegg, Google Geo API Team