[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.
Posted by Thor Mitchell, Maps API Product Manager
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.
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.
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".
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.
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.
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.
Posted by Mano Marks, Geo APIs Team
Give us feedback in our Product Forums.
Follow