This project is read-only.

GeoServer WMS TileSource

Nov 5, 2009 at 11:29 PM


First off, thanks to anyone involved in this project!  This is really an amazing piece of OSS.

I have recently been testing the DeepEarth control using a WMS provider, and it works great.  My goal in the very near future is to run my own WMS server and to make calls to it from DeepEarth.  I could use some assistance with creating the TilePath string for a GeoServer WMS Server though.  It looks like the format is mostly the same between the various strings in the file, but I've noticed a few variations, such as the "EXCEPTIONS=" section of the string.

Any assistance will be greatly appreciated!



Nov 6, 2009 at 1:38 AM

The MSI control (deepzoom core) is very tile hungry and with a bunch of clients you will saturate your WMS very quickly. What is worse is that the MSI in Silverlight only request 2 tiles at a time, if they take a long time to return it slows the whole interface.

We have built a WMS cache storing the tiles in SQL2008 for easy storage and fast retrieval. The trick is we decouple the tile request from the actual processing. If we don't have the tile cached we return a 504 (Gateway timeout) to the MSI so it just puts the request at the end of its queue. We also have it setup to request larger 1024x1024 images from the WMS and cut it up.

See a demo here (on my server so I'll have to relocate it as it will use too much bandwidth):

Zoom into Canberra or Sydney in Australia.

I'm working on a cloud based solution to make this easier to deploy and infinately scalable. With geolocated servers we could reduce the latency serving tiles from your nearest datacenter.

In terms of added the layer to map I'm just using the quadkey concept from Bing and directing the request to my tilehandler. The trick with getting an ultra smooth experience is to always return a responce for a tile request as fast as possible, I serve a blank png for tile request out of bounds. Fiddler is an awesome tool to see what is going on.

Nov 6, 2009 at 8:05 AM

You can have a look at GWC (DeepEarth.Client.Services.GWC) for reading tiles from GeoServer, ie. http://[geoserverPath/gwc. In short we can provide live examples showing this.


Nov 10, 2009 at 6:10 PM

Sorry for the delay in replying.  I've downloaded the current source from SVN and have been playing with GWC implementation.  I appreciate the help and examples. 

All I need now is time to play with the project! :)


Jan 4, 2010 at 10:13 AM


Regarding the suggestion by soulsolutions to return 504 (gateway timeout) from the tile-server while queing the requested tile to be rendered by a separate worker thread on the server. I've tried this with our project and it works, except that I've found that the Silverlight app doesn't always retry for the failed image tile.

Adding trace messages to the server ashx handler that serves tiles reveals that the tile request from Silverlight is sometimes retried too quickly, before the missing tile has been rendered and added to the cache. If I return a second 504 it then seems to give up, so the tile is not displayed, even though the server has by then rendered it and added it to the cache.

I've tried delaying the return of the 504 to give more time for the tile rendering thread to provide the tile, and that sort of works though not perfectly and seems like a poor solution. I'd rather be able to control the Silverlight client's retries. Id like to control the number of retries and the delay between them.

I tried intercepting the MultiScaleImage ImageFailed event in the Silverlight app, but it doesn't seem to give any useful information such as the url of the tile request that failed, or the ability to re-queue the request. Is there a way to control the retry of tile-image requests that fail from the Silverlight code?


Jan 20, 2010 at 11:11 PM

Even worst, the 504 solution cause a high cpu bug with the MultiScaleImage control so don't use it. It seems that you have to return a valid image or else occurs (60% cpu on my machine).

Our latest prototype still decouples the request for a tile from the processing to create it, instead of returning a 504 we return a very tranparent tile with "processing" message with an immmediate cahce expiry. I've enhance the tilelayer to poll a seperate web service when the user stops moving the map after a good 5s delay. If tiles were processing and are now complete I refresh the layer (remove and add again). This intrim solution (until the MSI is fixed) gives us a 0% cpu usage on idle, a fast loading of all tiles and a reasonable experience for on demand tiles. We're doing final testing here this week and I'll post an example of it.

Feb 13, 2010 at 8:44 PM

Thanks for the helpful suggestions.

I note from your alert at that there is now supposed to be an MS fix for this. I checked my Windows Update history and found that this fix (KB979202) had been installed on my system on 20th January. However, I'm still seeing high CPU usage when using Silverlight 3 with DeepZoom. 

Admittedly, I haven't yet got around to implementing your advice and so I'm still returning 504 from the tile-server. Maybe the fix still can't handle this? The Silverlight client is running on Vista Business 64-bit.

Has anyone had success with KB979202 in eliminating the high-CPU problem and does it have any existing limitations that need to be observed?


Mar 18, 2010 at 12:32 PM

Sorry for interrupting the thread!

We are trying to implement WMS cache storing the tiles in SQL2008 as Soulsolutions explained. We would appreciate some guidlines about how to do this (codesample). Will this be included in a future release?

Thank you in advance