The Anatomy of Web Map Services This article originally appeared in Geospatial Solutions Magazine's Net Results column of September 1, 2002. Other Net Results articles about the role of emerging technologies in the exchange of spatial information are also online.

1. Introduction and Glossary   2. Services, Standards, CGI   3. Dissecting WMS   4. Cascading services

Transparent Brain Tissue

Was our operation a success? If this anatomical exploration of Web map services still hasn't convinced you to join the effort, consider one last capability -- the one that ties our planetary nervous system together as a collective organism. When requesting maps of equal bounding box dimensions, map projection, and output size from two or more Web map servers, the result can be a single composite map! This capability is surprising considering that most Web map services return images rather than vectors, and images (or rasters or bitmaps) are opaque grids of pixels. How can several opaque images be unified into a composite map? Today's PNG, JPEG, and GIF formats support transparent backgrounds, so the servers can overlay many transparent images and retain partial views of the bottom layers, just as with vector data stacks. (Cascading the output of different Web map servers happens not as a URL parameter, but within the construction of a server, so some layers listed by one server may in fact originate in another.)

As an aside, Web map servers are not required to broadcast maps as images; vector streaming or XML data output is also considered in the specification; though, it's less developed than the image option thus far. The specification also describes the way to add on-the-fly features to map server output by putting the coordinates of a point, line, or polygon into the URL itself. The textually described feature then appears on top of the map image like a remora riding along on a shark.

Combining Web servers. Taking the composite mapping idea to a community level, combining the output of many separate distributed Web map servers by capturing and stacking their images is also possible. Today's online spatial data holdings are often, to quote the OGC spec, "vertically-integrated" sites, each with referential basemap data and overlying domain-specific layers. In contrast, the Web map server concept encourages data stewards to focus on their own particular data collections, and cascade the collections of others into their composite maps as needed. Because all data in this vision are supplied the moment they are requested, the most current views result. Of course, the more services in the list to be combined, the longer it takes to generate a composite image. Consequently, the issue of detailed local data generalization when requested at global scales is one of the hot discussion topics among the Web map services community.

The ability to combine disparate but standard Web map server output has sparked various distributed data projects. A noteworthy Canadian project clearly understands the nervous system concept. As documented by Robin Quenet, Rick Morrison, Brian Low, and Jim Wood, for example,

The Canadian Forest Service (www.nrcan.gc.ca/cfs-scf/index_e.html) is building a system to address key science and policy issues in support of Canada's commitments in such areas as climate change, biodiversity, criteria and indicators of sustainable development, trade and its national and international reporting obligations. The system is designed to provide and integrate timely, accurate and spatially explicit forest resources information by identifying, analyzing and portraying the available data.
The project relies on a combination of one central heavy-duty Cubewerx server and many remote University of Minnesota MapServer servers.

Sharing data from Web map servers also raises discussion about credibility. Knowing about a map server's layer list is one thing. Knowing when the layers' data were last updated is another. The OGC specification devotes a detailed appendix to the subject of dates and times as metadata elements. Commercial image service providers like GlobeXplorer (www. globexplorer.com) and Pixxures (www.pixxures.com) have already recognized the importance of providing temporal metadata to their customers. For instance, when mosaicking multiple images into a single composite image, Pixxures retains the flight time for each pixel in the patchwork so that hovering the mouse over any area can return metadata about when the plane or satellite captured that individual pixel.

Equally important to temporal data is the reliability of the provider. If our industry continues its trend toward ever more open data sharing, the importance of branding and establishing a good reputation as a reliable data provider can only increase in parallel.

A case of nerves

So ends our dissection of the framework that Dangermond envisions as a planetary spatial nervous system. Is he on the right track? As one of many standards, Web mapping services could become just another waste product of our industry's gastrointestinal system if not adopted by the majority of spatial professionals. My opinion, for what it's worth, is that Web mapping services, whether a source of profit or a gift to the community, are well worth the implementation investment in Earth's long-term health.

Consider conducting a Web map services operation of your own. Two free products, the Apache (www.apache.org) Web server in conjunction with University of Minnesota's MapServer, can become a WMS server or client (or both at once!). Online documentation appears at the MapServer site (http://mapserver.gis.umn.edu).



1. Introduction and Glossary   2. Services, Standards, CGI   3. Dissecting WMS   4. Cascading services