Landsat WorldWind WMS

CesiumJS
1

Hi,

I started reviewing Cesium today and really like what I see. Unfortunately, though, I can't get my first Cesium experiment to work. I tried plugging the following code into the Hello World Sandcastle test environment:

var widget = new Cesium.CesiumWidget(‘cesiumContainer’);
var layers = widget.centralBody.getImageryLayers();
var landsat = layers.addImageryProvider(
new Cesium.WebMapServiceImageryProvider({
    url : ‘http://data.worldwind.arc.nasa.gov/wms’,
    parameters : {
        transparent : ‘true’,
        format : ‘image/png’,
        width: 512,
        height: 512,
        version: ‘1.3’
    },
    proxy : new Cesium.DefaultProxy(’/proxy/’),
    layers: ‘esat’
})
);

No matter what variation I try, I get:

An error occurred in "WebMapServiceImageryProvider": Failed to obtain image tile

I've run this example locally so I could see the WMS URL that is being generated. The URL looks good and generates tiles if I hit it from outside Cesium.

Any thoughts on why this doesn't work?

Thanks,

- Mark

2

Hi Mark,

The proxy has a whitelist of sites that it will proxy for, and data.worldwind.arc.nasa.gov isn’t on the list. You can add it by editing the runServer.allowedHosts property in build.xml, and restartig the server. This is assuming that you’re using Cesium’s jetty-based web server as described in the Contributor’s Guide.

If you the World Wind server supports CORS, you can also remove the proxy entirely. I don’t know offhand if it does.

Kevin

3

Hi Kevin,

Just got back around to this a few days ago and as you suggested, using the contributor Jetty and the white list solved the initial problems. Thanks!

Follow on questions/background:

Our current web GIS viewer is an applet based on NASA Worldwind. We had been relatively happy with the solution until earlier this year when applets were demonized by the blogosphere and Oracle/Safari/Firefox et. al. subsequently made them really unappealing to use from a security standpoint.

We have been following HTML/Javascript based solutions for a few years, but have not found a compelling reason to switch from our applet until now. Cesium, I believe, gets us closest to the experience we currently have with the Worldwind applet. The main deficiencies for our purposes are as follows:

1. WMS performance. I have loaded our standard WMS layers into Cesium and, although it works, the view takes quite a long time to load (30 seconds or so). My initial debugging points toward two potential performance issues: a) Cesium seems to load a lot more tiles than is necessary for the current view port. b) Tiles are not cached.
2. No support for editing polygons.
3. Periodically memory/CPU usage goes through the roof.
4. To support some of our views and animations, WMS tiles need to be pre-cached.

The purposes of this post are two fold: 1. To get your opinion and/or validation as to whether my findings are correct and 2. to get your opinion as to how much effort it would be to enhance Cesium to mitigate these issues.

With respect to point 2, I have gotten approval from my management to assign developers to contribute to this project if it is possible to improve Cesium to better meet our requirements.

Let me know what you think….

Thanks,

- Mark

4

Hey Mark,

Glad to hear you were able to getting it working before.

Let me address each of your bullets:

1. WMS performance. I have loaded our standard WMS layers into Cesium and, although it works, the view takes quite a long time to load (30 seconds or so). My initial debugging points toward two potential performance issues: a) Cesium seems to load a lot more tiles than is necessary for the current view port. b) Tiles are not cached.

One thing that jumps out at me is how you’re setting up the WebMapServiceImageryProvider. You’re forcing it to load 512x512 images, while Cesium expects the images to be only 256x256. Since Cesium selects the LOD based on the smaller image size, it’s going to load a lot more images than it needs. The 256x256 expectation is built into the WMS provider here:

https://github.com/AnalyticalGraphicsInc/cesium/blob/master/Source/Scene/WebMapServiceImageryProvider.js#L91

This should be an easy change.

Another reason Cesium may be loading more tiles than we’d like is because it currently determines which tiles are in view by computing a simple bounding sphere to wrap each tile, and determining which spheres are in view. There’s quite a bit of error in this, so I suspect we could reduce the number of tiles by ~20% (made up number, but probably in the ball park) by using tighter-fitting bounding volumes, at the cost of a bit more time to compute which tiles are visible. We’d welcome pull requests from anyone that experiments with this and gets good results.

This is just speculation, but one thing to check… The World Wind WMS server might be optimized for a particular pattern of requests, or may have certain classes of requests cached. If Cesium isn’t generating the same pattern, the server may simply be taking a long time to serve images. If you confirm that this is the case, and can determine what pattern is cached, it’s probably possible to make Cesium use the same pattern.

Regarding caching… there actually is caching, in two places. One is that the browser automatically caches downloaded images. The other is that Cesium itself caches loaded tiles in memory. The problem with this second cache is that it’s small - 100 tiles or the number of tiles rendered last frame, whichever is greater. The number is easily changed, so it might be worth experimenting with:

https://github.com/AnalyticalGraphicsInc/cesium/blob/master/Source/Scene/CentralBodySurface.js#L89

Unfortunately WebGL doesn’t give us any way (to my knowledge) to determine the amount of GPU or system memory available, which makes it hard to pick a good cache size. 100 is definitely conservative.

2. No support for editing polygons.

I know of several groups that have implemented this feature on top of Cesium. For example, check out Raytheon’s Vega: http://cesiumjs.org/demos/vega.html

Unfortunately none have been so kind as to contribute it back to core Cesium yet. I suspect it’s not terribly difficult to do, though.

3. Periodically memory/CPU usage goes through the roof.

Can you tell me more about when you see this? The memory usage could be this:

https://groups.google.com/d/topic/cesium-dev/b7iV7ni2dmA/discussion

Regarding CPU usage, Cesium currently tries to render as fast as it can, only limited by the browser’s maximum requestAnimationFrame rate and possibly by vsync. Partially this is because Cesium is tuned for dynamic data visualization, where it’s reasonable to assume something is changing every frame, but also in part just because we haven’t gotten around to doing anything better, yet.

4. To support some of our views and animations, WMS tiles need to be pre-cached.

5

Hi Mark

Have you tried to install CORS on the WWJ server to allow Cesium to get contents by this server?
If yes, could you explain me how do you install CORS on the WWJ server?

Thanks,
Umberto

6

Hi,

Regarding 2. I started a very simple shape editor for my own needs. It also includes circle and extents. Check the thread on Polygon editing, a few days ago, https://groups.google.com/forum/#!topic/cesium-dev/nxlNP-DEw2s

Have a look and let me know if this is the kind of functionality you would need. I am happy to have it included in Cesium one way or another. But I would need some level of guidance. I doubt my quick coding for that one is up to Cesium standard.