Google deprecates the GE Plugin API

Understandable, but still a bit surprising to see this announcement:

I’m guessing we’ll start seeing a number of people trying to port their applications to Cesium in the near future. There isn’t yet any sort of GE->Cesium translation guide, is there? Might be a good time to get one started.

Hi Mark,

So far, we have Part I in what will be a series of “Cesium for Google Earth Developers.”

Do you or anyone else have ideas to make the transition as easy as possible for current Google Earth users?


Hmm. Looking at that post, it’s a pretty good quick overview of Cesium itself, but not much related to Google Earth. The last paragraph does say “the next tutorial in this series will introduce the major concepts in Cesium and how they differ from the GE plugin”, but obviously that next post doesn’t exist yet.

Off the top of my head, I would suggest a feature comparison table to give a high-level overview of the differences, followed by a more detailed API/task equivalence mapping (ie, “If you were using a LineString to draw a line, try using a PolylineCollection”). Beyond that, perhaps something like Cesium translations of the Developer’s Guide and the Samples sections of the GE API site. Also, finishing up KML support would obviously be a huge deal.

I’m still scratching my head as to how I am going to convert all my local KML files to CZML or GeoJSON, and how it might by possible to use the millions of KML Network Links available on the web.
I’m trying to match and Cesium to serve layers. I was thinking of ingesting KML with Geoserver, then serve it to Cesium. Is there a better way to do this?

Here are the sources I’m working with in Google Earth:

Any help would be greatly appreciated, I really want to make our Cesium powered app shine. Keep up the great work Patrick and company.


Climate Viewer 3D

Mark - thanks for the ideas.

Jim - are you familiar with the czml-writer project for writing CZML? It could be of interest. I have not used GeoServer so I can’t speak to it. We are also going to support KML directly in Cesium. Check out the branch and roadmap items: #873 and #2179.

What other ideas for tutorials, examples, features, etc. do folks have to help developers successfully move from the GE plugin to Cesium?


Is it worth (and possible) writing an adpater? ie a bit of code that would emulate the GoogleEarth plugin API but talking to Cesium instead.

Just thinking out loud here :wink: trying to understand if it is an option, if there is interest and if it makes sense.

I can see that kind of adapters poping out, eg OL3, Leaflet… I’ve done my own for my map library and it’s not necessarily a huge amount of work, although I must say the GE API is quite feature packed but so is Cesium, it depends if there’s a good match between the two.

Are you volunteering to contribute the wrapper? :slight_smile: A wrapper creates a very low barrier-to-entry to move to Cesium, but do you think developers would want to base their app on it given the future of the GE API itself is unclear? These users would most likely have to dip into the Cesium API as new features become available.

Do you know if the utility API is popular or if most folks use the API directly:


Per my previous comment, I’d say that correlating equivalent features and filling in “missing” functionality is a better approach than trying to create a wrapper for an API that’s about to go away. No point in trying to perfectly emulate an API, particularly when we don’t know everyone’s use case.

Patrick, Mark, very good points. I can still see the wrapper filling a temporary gap, for example people that are unsure about moving to Cesium or don’t have the immediate financial resources to hire a developer to do the work. But I agree with you, at some point you would still have to bite the bullet and make the full port. A wrapper is not a long term solution, just a temporary plug.

I think a simple reflection server would be best, that’s what Google was doing anyways. Server does this:“”&output=“CZML”

Conversion server downloads KMZ, unzips it, converts to chosen format.

I was attempting to do this using, however I am only a novice developer.

The reason this is preferable is Cesium will be able to take advantage of dynamically generated KML on old systems and allow display of any KMZ/KML on the web using a network link.

My 2 cents.

Patrick I am going to give the converter another shot, been almost a year since I did.

~ Jim

FYI, ogr2ogr is a great open-source tool for converting between Shapefiles, KML and GeoJSON. CZML is not a common standard (yet?) however, so it’s not going to be as straightforward a solution.

Thanks for all the ideas. Not that I’m advocating it, but an alternative to a wrapper could be a converter that translates the GE calls to the Cesium API. I suspect this would be hard to do well in practice, but would have the benefit of moving the app’s code to a supported API. Instead, just providing side-by-side code examples would help users ease into Cesium instead of just trusting a converter or wrapper.

Jim - we are adding native KML support to Cesium in the kml branch I mentioned previously so you could also use this to load KML directly in Cesium instead of converting it to CZML first. CZML does have a lot of benefits though like the time-dynamic features.


Thanks Patrick,
We tried the KML branch and had multiple issues, it has a lot of dev work needed apparently.

We are actually working up a completely new framework that imports KML to an Elasticsearch DB then regurgitates GeoJSON files to Leaflet and Cesium.

It’s already working, we just need to fix icon styling and we’re golden. I hope to be able to contribute some of the code to your project when we finalize.

Also, ANY DEVELOPER is welcome to help out, we could really use it.

~ Jim Lee

We ported 30 Google Earth API examples to Cesium. Check out this thread:!topic/cesium-dev/piux2QQqo3k