The Google Earth COM API is being phased out

One of the neat things included as part of SketchUp 8 was the new way that it pulled in imagery from Google Earth. Rather than using the Google Earth COM API, as it had for years (Frank covered it in 2006), it pulls in imagery via Google Maps which results in color imagery instead of the black and white that you’re used to.
While the color imagery is certainly a great feature, it appears there is another reason for the change as well — Google is eliminating the COM API.
Instead, Google is encouraging developers to take advantage of the powerful JavaScript API that was released in 2008 along side the Google Earth Plug-in. This allowed for a wide variety of applications, like the popular “monster milktruck!” demo.

monster-milktruck.jpg

It’s worth noting that current and all past versions of Google Earth (5.2 and earlier) will continue to support the COM API, but future versions will not.
If you’re a developer, what do you think of this news? Have you moved on to the JavaScript API already and this is a non-event? Or does this have you scrambling to make sure your app will work with future versions of Google Earth?

About Mickey Mellen

Mickey has been using Google Earth since it was released in 2005, and has created a variety of geo-related sites including Google Earth Hacks. He runs a web design firm in Marietta, GA, where he lives with his wife and two kids.



Comments

  1. middle-island says:

    “future versions of GoogleEarth”
    was wondering if there was ever going to be a 6.0

  2. I don’t have any specific information about future versions, but I kind of assume we’ll see a version 6.0 at some point.
    The way things are currently going, I fully expect we’ll see version 7.0 and 8.0 in the years ahead. At least, I sure hope we do!

  3. I’m going to be really pissed if they remove the AppleScript API from GE on OS X. Years after I made that little GeoTagger script people are still downloading it. I heard someone was reporting it had gone in 5.2 but it’s still working for me.

  4. Paul van Dinther says:

    I wish that Google would maintain a COM interface to the plugin as well documented as the JavaScript API.
    JavaScript in a sand boxed environment as a browser is extremely limited in what it can do.
    Real-time debugging tools in browsers are seriously substandard to those found in well evolved programmers IDE’s although they are getting better. (Hint: why can I not edit in the Chrome JavaScript Debugger? )
    For security reasons, JavaScript won’t let you access the local file system or local devices. This makes it impossible to write your own joystick implementation or custom HID device. Not to mention the ability to capture screenshots or do render your own video footage.
    Processing intensive tasks just won’t work in JavaScript. JavaScript on browsers has gotten faster but it is by not capable to do things like real-time physics simulation. For Planetinaction.com , I find myself writing JavaScript like I did 20 Basic years ago, trying to shave off every instruction and keeping the results of a cosine calculation in a variable and share it around routines that might need it. (Check out http://www.planetinaction.com/library/globals.js )
    There is a demand for COM access as the various lopsided attempts illustrate. Without COM programmers need to create a browser object in their application that loads a page that loads the plugin. Programmers then need to generate javascript statements in their applications, pass that to the browser object that then on turn passes it to the plugin api that in turn executes the instruction. It feels like leaping back a decade or two while letting all this modern processing power go to waste.
    Finally, JavaScript is simply a functional language with a thin OO veneer on top as anyone who tried to use setTimeOut() will know. It is not possible to write solid independent library classes nor can you copy protect your work properly in JavaScript.
    It is clear that the age of fat clients is drawing to a close and stuff moves onto the web. But until the tools have caught up and the JavaScript API is capable enough (Hint: screen-capture and HID support) , I want to see full COM interface implemented. It’ can’t be that hard to offer that kind of support in addition to the JavaScript API.

  5. Leonardo Daniel Leidi says:

    Does anybody know why the “colonias” name of Mexican cities (neighbourhoods) does not appear any more?

  6. While I understand that COM is something of a proprietary Windows-only unpleasantness I really wish Google would keep the API around in Earth. This is going to kill off a photo geotagger and some other applications I’ve made:
    http://code.google.com/p/googleearth-autohotkey/
    Without the COM API I don’t think there’s any really handy way to capture the current viewport coordinates from Google Earth, which is extremely useful to be able to do when making KML files.

  7. It’s the API’s dependence on javascript that causes most heartache, but as we’ve discovered, we can access the API directly from .NET adding a reference to the “GEPlugin Type Library” in Visual
    Studio. It looks like all our dependence on js can be put behind us…
    However (and it’s a big however) there are serious pitfalls here as your .NET app, developed with one GEAPI version won’t run with a later, or earlier version – at all. Means you can’t ever distribute your app!
    Also, the exposed interface is missing some significant methods (parseKml for one)
    And it’s is not well documented at all – hard to know which of the similarly named but subtly different methods to use.
    After many, many hours of trial’n'error talking to the API from .NET, I have decided to continue interfacing with the API via javascript for the present.
    I do all the file handling, complex processing and UI in the VB code.
    It works surprisingly well and I’m getting some amazingly fast and smooth animations out of a relatively modest desktop PC.

  8. Hi,
    I have developed a number of controls that allow you to work with the Google Earth Api from managed code. Most of the issues expressed in the other comments here are addressed (local file access, events, etc)
    Check it out if you are interested.
    http://code.google.com/p/winforms-geplugin-control-library/

  9. @David T
    “we can access the API directly from .NET adding a reference to the “GEPlugin Type Library” in Visual”
    Just to note, the controls I have developed use a late binging model, so they are fully version independent of the Google Earth Plugin Type Library.
    http://code.google.com/p/winforms-geplugin-control-library/
    F.

  10. shahrukh says:

    how can i connect database in visual basic 6.0???

Leave a Reply