WMS: The Standard That Isn’t
When you think of the words “Web Map Service,” you might think of something that generally defines all maps that are out there on the internet. You might think it could refer to getting directions to Grandma’s house on a Google Map, or you might think of a New York Times map of entitlement program use. In both cases, you’d be wrong.
A Web Map Service (WMS) is an Open Geospatial Consortium (OGC) specification that “defines a common interface for disseminating digital maps, rendered from spatial data, across the Internet. WMS supports the networked interchange of web based map layers, which are generally rendered in a digital image such as JPEG, GIF, PNG, etc.”1
In English, a WMS is computer language (script) that tells a server, “gimme your map!” The server then responds by sending an image file to your (the client’s) browser (e.g., Firefox, etc.). It is important to note that a WMS is _not _a map mash-up or a slippy map, which are increasingly the norm of interactive web maps made for public consumption.
WMS was the first standard put forward by the OGC to define how map servers should communicate with client computers. It is still used by a lot of folks. But the thing about standards is that they are recommendations, not laws. And some people–in this case, those that control the majority of the web map market–like to play by their own rules. But first understanding how WMS works can be helpful to understanding those rules as well.
A Web Map Service _is a _script. A WMS server _is the piece of software that actually responds to the script and sends you your requested image. Examples of this software include MapServer (open source) and ArcIMS (proprietary). The term _server _is commonly used to also mean the physical computer running the server software, but technically, the computer is the _host. The server is the software program that serves clients from the host.
<figcaption class="wp-caption-text">A metaphorical diagram of server-client architecture</figcaption></figure>
The first request, GetCapabilities, asks the server for information about what it has to offer. It’s like asking to see the menu at a restaurant where everything is a-la-carte. The server gives you an answer in XML: I have these data layers and can give you this many tiles at once in these styles, etc.
The next thing that has to happen to make your map work is a GetMap request. This is like giving the waiter your order. The request includes a list of parameters that include the layer names, styles, a coordinate reference system, bounding coordinates of the map to be returned, the width and height of the map, and some other optional ones.3
The third type of request, GetFeatureInfo, is optional, and only works on layers that are queryable, meaning that it contains features with data you can access. This is something that is often set up to be triggered by clicking on a feature on the map, and the info that gets returned is shown in some kind of pop-up window or panel.
1Wright, D., Dwyer, N., Cummins, V., eds. 2011. Coastal Infomatics: Web Atlas Design and Implementation.New York: Information Science Reference.
2de La Beaujardiere, J. (ed.) 2005. Web Map Service. OGC 04-024, version 1.3. Open Geospatial Consortium Inc.
32012. Web Map Service. Wikipedia. Accessed June 21, 2012. <http://en.wikipedia.org/wiki/Web_map_service>
42012. Web Mapping. Wikipedia. Accessed June 25, 2012. http://en.wikipedia.org/wiki/Web_cartography