| Nurse, pass the scalpel
OGC published version 1.1.1 of its WMS Implementation Specification in mid-January 2002, and it continues to advance the standard today. At its throbbing heart, the specification requires that conformant Web map servers respond to two URL-based requests, namely, GetMap and GetCapabilities.
When encountering a URL containing the parameter pair "REQUEST= GetMap," a standard Web map service will return its default map image (see Figure 2). An imaginary URL structure for this most basic of standard requests is as simple as "http://my.domain.com/directory/program.cgi?REQUEST=GetMap." To satisfy this request, the server would have to predefine the extent of the map view, the map projection, the image format (JPEG, PNG, or GIF), and the list of spatial data layers to include in the reply. |
 |
Figure 2: A default census and reference map is returned by an imaginary Web map service in response to "http://my.domain.com/directory/program.cgi?REQUEST=Get Map".
|
| Suppose a server has several data layers, but only one or two are important to a particular user s need? The OGC specification defines additional optional parameter pairs which, when added to the basic URL, tell the server what to send, or what image size and map extent to draw, for instance (see Figures 3 and 4). Though textual rather than graphic, this approach sounds strangely similar to the traditional desktop GIS s table of contents GUI. On the GIS desktop, to see a layer, one just activates its checkbox. A Web map server recognizes URLrequest checkboxes when digesting a parameter pair such as "LAYERS=streets+parcels+hydrants." Adding other parameters that control the drawing style of each layer is part of the ongoing evolution of the specification. Turning a user-friendly graphic table of contents into a long and complicated URL may seem like a step backward, but it gives access to custom map images to anyone capable of creating a simple HTML document. Web site designers not interested in building interactive online GIS interfaces, but who just need current, static map images, can incorporate the output of Web map services seamlessly into their sites and always be assured of the most current content.
|
 |
Figure 3: A custom imaginary map service response including only the data listed in the LAYERS parameter: "http://my.domain.com/directory/program.cgi? REQUEST=GetMap&LAYERS=water+streets+parks".
|
 |
Figure 4: A custom imaginary map service response with projection specified: "http://my.domain.com/directory/program.cgi? REQUEST=GetMap&LAYERS=water+streets&SR S=epsg:4326".
|
| What's up, doc?
But wait a minute! When sending a URL to somebody else's Web map server, how is the URL's author supposed to know what layers exist in the first place, their names, or their maximum extents? Picking specific layers depends on knowing the list of layer choices. OGC anticipated the need for server metadata by requiring that conformant Web map servers also be able to answer the GetCapabilities request. Sending any conforming server a URL such as "http://my.domain.com/directory/program.cgi?REQUEST= GetCapabilities" should make the server spill its guts, fully disclosing its dataset names, extents, supported map projections, and other such metadata.
The response to a GetCapabilities URL request is an XML document (see Figure 5). If looking for hurricane positions during storm season, for example, an automatic program could poll each of a collection of Web services, drawing only those that listed "hurricanes" in their XML layer listings. |
 |
Figure 5: Text editor view of partial XML output from a GetCapabilities request, showing the water layer's details. |
| What s in a name? While automatic access to service data listings is wonderful, the content itself remains problematically arbitrary. First of all, a unified worldwide nervous system that pivots on text names requires a standard language. At the moment, that seems to be English. But even assuming the use of the English language, what's to stop one service from calling its street centerlines the roads layer or the pavement layer rather than the streets layer? Efforts to standardize thematic terminology by industries such as surveying, planning, hydrology, and others may eventually reach the Web mapping services community as well.
In the meantime, XML is providing structured data, and the OGC Web Map Services specification standardizes that structure. In combination, this data stream and its metadata enable plug-and-play Internet GIS interfaces that load all the layers from any compliant Web map service into the familiar GUI of a traditional GIS table of contents and map view. These envelopes of usability surrounding Web map servers' data streams are known as WMS clients. A simple WMS client example by Refractions Research appears at http://mapserver.refractions.net/phpwms/phpwms-rel/. For a complex example, visit the Cubewerx site at http://www.cubewerx.com/demo/cubeview/cubeview.cgi. To test either one as a client to a real Web map server, try entering the URL http://arbutus.gis.umn.edu/cgi-bin/wmsserv.cgi? into the text box at the bottom of either site's opening Web page (see Figure 6). Simple or complex, WMS clients usually offer basic pan and zoom functionality, but most efforts are recent and experimentation still follows the evolving OGC specification. (A third part of the OGC specification recommends but does not require a GetFeatureInfo request that returns information about a particular map feature rather than the service's overall capabilities. If and when this third request becomes a requirement, then "identify" tools will likely become common functions of WMS Clients). |
|
