In Defense of the WMS

Earlier this week James Fee, celebrity GIS blogger (seriously, how many other GIS bloggers can you name), posted a blog about the death of the WMS.  He was commenting on a blog from Sophia Parafina, who was discussing the difficulties of working with the WMS URL.  Surprisingly enough, this isn’t the first time someone has shared their  “love” of the WMS standard.

If you have programmed using a WMS you probably have become frustrated when trying to understand what each component of the URL means, the differences between the different versions, and how different GIS server software handles the WMS.  I don’t think the WMS is dead, but its use may need to be reevaluated.  For example,  the WMS servers that I take advantage of tend to have few datasets (less than 30) served from them, and I only use raster datasets, such as historical maps, or aerial photography, in my applications.  I try to avoid large WMS servers with 100s of layers, and I rarely use vector from them, because I don’t like wait times with large WMS servers, and vector data renders poorly.

I like to use WMS data from a number of different sources as base maps for use in Google map mash-ups.  I’ve found that using the WMS for this purpose equals fast response times in an easy to use interface.  Now, what about decoding the URL?  Well, it took a couple of hours of trial and error but a few lines of javascript can read the WMS URL pretty easily.  I didn’t create the code myself, but like any programmer, I definitely had help from a number of different online sources.

Here are a few Google Maps V3 API examples running WMS data:

ArcGIS Server WMS in Google Maps

Open Layers WMS in Google Maps

Cadcorp WMS Google Maps

Microsoft Research Maps in Google Maps

Multiple WMS Service in a Single Site

Large Aerial Photography Datasets

That’s all for today!  Hooray weekend!

p.s., For my next post I’ll try to have a couple of pictures.  People hate reading.