More on Silverlight WMS Viewer

Silverlight MapControl OWS Viewer
Fig 1 – Silverlight WMS view of DRCOG

Exploring WMS services using my Silverlight MapControl viewer uncovered a few more areas worth exploring further.

spherical mercator support

The problem with coordinate systems resurfaced when looking at BLM WMS services. The only coordinates supported by BLM are EPSG:4326, which is unfortunate. All of the web map services use a spherical mercator tiled approach for better performance. This was not an arbitrary decision just to spite the bureaucrats at EPSG. Tile pyramids are best supported using a square quadtree as discussed here, which is why mercator was chosen. Using a spherical datum instead of an ellipsoid eases the transform calculations for faster map interaction. However, because the EPSG and OGC standards made their appearance late, many sites are stuck off the mainstream supporting only EPSG:4326.

The newer services, at least those using GeoServer or MapServer, have support for a large number of coordinate systems including the spherical mercator coordinate systems needed for Google, Virtual Earth, Open Street Maps, and Yahoo. Shown in the example above, DRCOG WMS service uses GeoServer and by default supports EPSG:900913. In contrast to BLM, DRCOG has support for all the features needed to make it useful to the web map services, including spherical mercator coordinates, transparent parameter, and cross domain access. Even though it is still lacking official EPSG:3785 support EPSG:900913 works just fine.

The BLM LSIS WMS appears to lack support for the “Transparent=True” parameter which makes stacking layers a bit cumbersome. Even though opacity can be adjusted, opaque fills are additive and eventually obscure lower level layers. However, the big problem is the lack of any spherical mercator coordinate system.

Silverlight MapControl OWS Viewer
Fig 2 – View of BLM LSIS misfit

crossdomain policy support

Both Flex and Silverlight restrict cross domain access. In other words access to site of origin is allowed, but not access to a url other than the site of origin. In Silverlight this is true even of image urls. The idea is to prevent url hijacking from client side code. Cross domain restrictions can be altered by including a crossdomain.xml or clientaccesspolicy.xml to grant access to a particular service, but these can only be added by the hosting service. So in the case of USGS Atlas, cross domain access seems to have been granted, but not by BLM LSIS.

You can see a summary of the Silverlight restrictions here:

Cross domain access doesn’t really need to be granted by the service host, since it is simple enough to use the Silverlight host server to proxy access and avoid the client side restrictions. In order to circumvent these restrictions it’s necessary to provide a proxy service on the Silverlight server that translates cross domain requests into a a site of origin proxy request. This approach was discussed for GetCapabilities and GetFeatureInfo requests with an example WCF. However, SOAP calls for producing an image would seem to add a good bit of overhead, and I switched to an .ashx service handler for my GetMap requests.

Peter Bromberg’s blog – Handling Cross-Domain Images gives an example which I adapted for use in the Silverlight WMS Viewer.

using System;
using System.Net;
using System.Web;
using System.Web.Services;

namespace VEOWS.Web
    [WebService(Namespace = "")]
    [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
    public class ImageHandler : IHttpHandler
        public void ProcessRequest(HttpContext context)
            string imageUrl = context.Request["url"].ToString();
            WebClient client = new WebClient();
            byte[] bytes = client.DownloadData(new Uri(imageUrl));
            context.Response.BufferOutput = false;

        public bool IsReusable
                return false;

Example of an .ashx proxy handler for GetMap image requests

Silverlight ProgressBar

Since there is a pause waiting for a WMS GetMap request I wanted to add a ProgressBar. In fact Silverlight 2.0 includes a ProgressBar Control

This seems like an easy solution, just add a ProgressBar control along with a ValueChanged event handler and I should be ready to go. However, it is not quite so easy as desribed here: Silverlight 2.0 Progressbar Control In the end I simplified life and instead of a real progress bar I just show a ProgressBar with IsIndeterminate=”True”. By toggling visibility I can provide a user hint to wait a moment on the GetMap request.

In order for this to be effective I need to set Visibility.Visible when starting and then Visibility.Collapsed when done. Using a WebClient Asynch call provides the framework for this:

WebClient imgLoader = new WebClient();
imgLoader.OpenReadCompleted += new OpenReadCompletedEventHandler(imgLoader_OpenReadCompleted);
imgLoader.OpenReadAsync(new Uri(imgUrl));

where imgUrl includes the .ashx url with the proxied url as a parameter for a GetMap request. This url parameter must be urlencoded with ‘%26′ replacing the ‘&’ :


Now I can set DownloadProgress.Visibility = Visibility.Visible; before imgLoader.OpenReadAsync(new Uri(imgUrl));. Then in the callback handler set DownloadProgress.Visibility = Visibility.Collapsed;. This is not ideal, but the GetMap requests are seldom more than a second so the more complicated threaded ProgressValueChanged handler isn’t really that necessary.


  1. WMS services such as BLM LSIS need to update their service with the newer EPSG:3785 and add a Transparent parameter to their GetMap requests if they wish to be useful to web map services.

    In contrast services such as DRCOG are all set for useful client development in Silverlight MapControl as well as Google, Yahoo, and OSM.

  2. Silverlight ProgressBar should be easy but not yet! Perhaps Silverlight 3.0?
  3. .ashx handler proxy is a simple way to get around cross domain restrictions for GetMap Image requests

Comments are closed.