Cesium 2013 - Ease of use


Part of our mission is ease of use. We’ve had lots of positive comments in this area, but we’ve also had some justified less-positive comments, especially bridging the gap between running Sandcastle and building a first Cesium app.

Fortunately, we have several improvements already in the works or on our short-term radar:

  • New release packaging that makes it easy to get up and running with the minimal amount of Cesium JavaScript files and assets.
  • A CDN-hosted Cesium.js so users can use Cesium without having to download or host it. We’re currently considering cdnjs.com. Other suggestions are welcome.
  • A new widget architecture (also mentioned here) that
  • Allows creating a Cesium app with a single line of code.
  • Makes it clear that Cesium does not require Dojo or any other UI frameworks, but some Cesium widgets integrate with these frameworks.
  • Tutorials as previously mentioned, including one on deploying with AMD.
  • Make the website automatically deploy.
    In addition, we should continue to require reference doc (with example code!) for all new code, and fill-in DOC_TBA comments in older code as time permits.

What else should we do to help ease of use for users, especially novice users, and for contributors? What are the hardest parts of Cesium to use? What is the most painful part of developing for Cesium?



For me, the main things are:

  • Breaking out of Sandcastle (I still haven’t figured out how)

  • Decoupling from Dojo (I use JQuery and don’t want Dojo anywhere near me)

  • Escape from AMD (I am philosophically opposed to its existence)

  • Single file to load. If it’s good enough for JQuery, OpenLayers and a host of other frameworks, it’s good enough for Cesium.

  • Single initialization function capable of re-defining terrain providers, imagery providers, URLs, proxies, colors, re-branding, etc – see OpenLayers.



Hi Peter,

Thanks for the input. I think we have 1 through 4 covered. As for 5, can you point us to an example?



Also, some sort of way to easily implement new file handlers. e.g. I tell Cesium that I know how to handle KML files, and it asks me (client-side) for an associated CZML object when loading, etc.

Here is an example from my user of OpenLayers:

this.map = new OpenLayers.Map({div: this.element.attr(“id”),

projection: “EPSG:900913”,

numZoomLevels: 17,

controls: [

//new OpenLayers.Control.ScaleLine(),

new OpenLayers.Control.KeyboardDefaults({ autoActivate: true,

defaultKeyPress: function(e) {

self._keyPress(e, self);


new OpenLayers.Control.Navigation()],

layers: [

new OpenLayers.Layer.XYZ(



{transitionEffect: ‘resize’}



Initialization can get pretty extensive. I can imagine something similar were I construct a widget and set its terrain provider, imagery providers, scene background, maybe some of the keyboard and mouse control options, button visibility, etc, all in one place.


Thanks for the input Peter and Justin.


Just throwing out a couple of thoughts…

I happen to like AMD but it does introduce a certain barrier to Cesium entry as it can be very particular about script locations, relative paths, etc.

Introducing a Cesium “plugin” architecture would be pretty sweet; sort of along the lines of Justin’s examples…where you want to override or re-direct Cesium functionality to a custom defined component.

  • Chris


Thanks for the comments. We’re in agreement about AMD. With the planned release packaging, most users will not start with AMD, instead they will have as close as we can get to a single Cesium.js (given web workers, assets, etc.). An AMD version will be available to more advanced users. The CDN-hosted version will also be great for folks that just want to add a script tag and start coding. Unfortunately, a lot of our users are on closed networks so they still have to download it.



While there’s a bunch of API reference doc, I found the biggest barrier to entry conceptual. What’s a central body? How do I use the camera? What’s the correct way to put text labels into the 3D scene? I’m looking forward to seeing your tutorials on these.

For using in my own code, I’d like to be abIe to use just the bits of Cesium I need. It seems Require.js would be useful here but I haven’t used it; I don’t “get” AMD yet.

I like the idea of using a CDN for Cesium.js and presume you’d have different versions at unique URLs. Of course if I don’t want all of Cesium, I’ll probably want to roll my own, and I’m OK with that once I figure out how.


Thanks for the input. I think we have you covered on all accounts. We are actually working on a camera tutorial now. We plan to have one for AMD eventually too. As for CDN hosting, these will be the entire minified standalone Cesium.js, and there will be different urls for different versions.



I noticed there are still some sandcastle examples --like CZML, & Imagery Adjustment-- that are difficult to replicate, I think due to their dojo dependencies. Any chance they will be "cleaned up" like the other sandcastle examples?

Hi Paul,

Yes. The direction Sandcastle is going is (1) to still have these larger showcase examples that show a part of Cesium pretty deeply and (2) to also include simple small examples for copying and pasting. For example, the Geometry and Appearances showcase creates lots of different geometry types in one large example, and the examples in the Geometries and Appearances tabs are much smaller showing an just an individual feature.