Posted:

From the earliest days of Google Earth, (and even back when it was still called Keyhole,) developers have wanted control over the globe to create their own 3D Earth applications. In response to this need, the Keyhole team added a COM API to the Keyhole app, to allow further customization of users’ Google Earth experience. When Keyhole became Google Earth in 2005, this API was carried over. Though we never provided much support, developers discovered the COM bindings and a few intrepid developers sorted through the vagaries of COM programming. Eventually we had a small but committed development community demanding documentation, which we released in 2007. We saw some interesting uses for the COM API, particularly by Enterprise users and broadcasters. Mostly, though, people wanted to put Earth in their web applications.

In 2008, we released the Google Earth API and browser plug-in. This robust JavaScript API is more powerful than the COM API, and can be used on a variety of platforms to deliver compelling 3D applications over the web based on the Google Earth technology. At the same time, we stopped development on the COM API and began encouraging developers to migrate to the Earth API instead. Today, more and more apps are being written in JavaScript, and COM itself is no longer a widely used technology, so the time has come to retire the Google Earth COM API.

Today we’re announcing that the Google Earth 5.2 client will be the last version that supports the COM API. Earth 5.2 and older clients will continue to support the COM API while these versions are supported. Future releases will no longer have COM API bindings. We believe that the JavaScript API provides the best mechanism for reaching the most developers.

We realize that a few of you will be disappointed by this news, however we are happy to work with you to transition off of COM onto JavaScript. Please see the documentation for more information on how to work with the Earth API, and visit our active developer forum for support. Enterprise customers can also contact Enterprise support with any questions. If you have a feature from COM that you can’t live without, please let us know about it by adding it as a feature request in our issue tracker, and starring other requests.

Posted:
The following guest blog post was written by Albert Sun of the Wall Street Journal. He takes us behind the scenes in the creation of a recent news graphic titled: "Going the Distance: Comparing Marathons".

The Google Maps API has been a great boon for news websites and a great help in creating all kinds of interactive graphics involving maps. Here at the WSJ we're big fans of the API and happy that Google continues to improve it and roll out new features.

 We got the idea to map out the routes of Marathons from a story by Kevin Helliker about how despite the beautiful scenic route of the race, the San Francisco marathon was still very unpopular. The difficulty and the hilly terrain kept people from attempting it. To help people see this better, we decided to compare the San Francisco marathon to the big three US marathons: Boston, New York and Chicago.

The code for our marathons graphic grew out of a similar graphic we did for our coverage of the Tour De France. In this one, we managed to incorporate many improvements. Two new features of the Google Maps API played a big role in this graphic. The Elevation API let us quickly and easily get a comparison between the different routes.

Styled Maps let us give the map more of a distinctive WSJ look. We have a distinctive style for our maps in print, and there is some reluctance to run maps online that deviate from that style. Styled Maps lets us get close enough for what we're trying to show. When Styled Maps first becomes available we used the Styled Map Wizard to create a set of different looks for different types of maps, trying to recreate our own maps style.

Along with the Google Maps API, we used jQuery for its wealth of convenience functions and how much easier it makes writing programs in JavaScript. The core of the graphic is a basic Polyline drawn in Google Maps showing the route.

If your path is simple enough, (fewer than 300 or so points) you can take that and directly request elevations along it using an ElevationService object. The elevations are handily returned at equidistant intervals along the path. If a path is more complicated than that, like ours were, you can either break it up into multiple requests, or send a simpler path. We decided to pre-simplify the paths with a Ramer-Douglas-Peucker algorithm (a very useful algorithm for GIS applications) and sent the simplified path off to get elevations.

Taking the array of elevations returned by the API, we used Flot (http://code.google.com/p/flot/) to draw a chart. The result of an Elevation API request retains the LatLng points and elevation for each point along the path in order, so from there it was easy enough to detect the x position of the mouse over the chart and use that as an index for the array of results.

This worked at first, until we noticed that in places where the marathon route was going over bridges, the elevation API was returning negative values. As it turns out, if given a point over water, the elevation API will return the depth of the sea bed. That might be useful for some applications, but was clearly unsuitable for this map. We ended up saving the results from the elevation API and splicing in the elevations of bridges by hand, an inelegant solution, but manageable since we were only doing four paths.

Now, the final feature was Street View, and it really surprised me how easily Street View could be integrated. After registering a Street View panorama object and assigning it a div, it's literally as simple as passing it a LatLng to place the pegman on the map. Because the Street View API responds super speedily to requests, it can mostly keep up with the rapid fire requests from dragging the mouse across the chart.

As newspapers' Web sites continue to draw a larger and larger share of overall readership, its important to keep moving forward in finding and creating great tools for making informative and beautiful graphics.

So, thanks Google for creating such a useful API!