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.
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 http://geoserver.org/ 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?
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 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? 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.
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.
Conversion server downloads KMZ, unzips it, converts to chosen format.
I was attempting to do this using geoserver.org, 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.
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.
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.