The Open Geospatial Consortium (OGC) Web Map Service (WMS) specification provides a pattern for serving maps through web services. The WMS receives a request detailing the bounding box (or extent) of the map, the layers to include, the projection to use, and other parameters. It returns a rasterized map image in a common format such as JPG, GIF, or PNG. It does not return any actual GIS data, although an optional part of the specification describes how a user can query any pixel of the service to retrieve attribute information.
WMS has been around since the year 2000 and was supported by some of the earliest FOSS GIS servers. It is still widely supported today in FOSS and proprietary GIS software. Although it has been sometimes criticized as clunky, WMS has enabled a greater degree of interoperability in the world of online mapping.
Consider WMS as an option if you do need a high level of interoperability and you don't require lightning fast performance or the ability to handle dozens of concurrent users. If you need greater performance and scalability, you should consider tiled maps, including the OGC-endorsed WMTS (Web Map Tile Service) specification. Tiled map services are described in the next lesson.
Requesting a map from a WMS using the GetMap operation
The best way to get familiar with WMSs is to look at a real one. Therefore, make a close examination of the following URL and then open the link in a web browser:
This request uses the WMS's GetMap operation to retrieve a map with a land cover classification based on imagery and LiDAR data for the State College area. If you are familiar with the campus, you may recognize some buildings and roads in the image. This WMS is provided by the PASDA web portal (http://www.pasda.psu.edu/uci/DataSummary.aspx?dataset=3155).
Although a WMS can perform several types of operations, GetMap is the most common. It's the one that sends you back a map image.
The root piece of a WMS URL (in this case https://imagery.pasda.psu.edu/arcgis/services/.../MapServer/WmsServer?) can be formed in various ways (often it will end in 'wms?' rather than 'WmsServer?'), but the parameters following the ? must be formatted according to the WMS specification. Let's examine the parameters used in the above URL.
|SERVICE||WMS||Indicates that a WMS is being called.|
|VERSION||1.1.1||The version of the WMS specification that this WMS can be expected to comply with|
|REQUEST||GetMap||This is the operation being requested from the WMS. The GetMap method is the most common operation called on a WMS and is the one that actually returns a map image. The GetCapabilities method is another common operation that returns you some XML metadata describing what the WMS can do.|
|LAYERS||9||A comma-delimited list of layers that the WMS should include when it draws the map. Some WMSs (like this one) are treated as collections of separate layers that are not intended to be drawn together. Other WMSs have the layers designed to be overlayed or drawn in groups. In this WMS, the layers have numbers as names but these can also be real names like "landcover_2006_statecollege".|
|STYLES||In this parameter, you can define your own styles to apply to the WMS when it is drawn. We did not submit this parameter, therefore we get the default styling defined on the server.|
|SRS||EPSG:4326||The coordinate system that the WMS will use when it draws the map. Here it is specified using an EPSG code (which you saw in previous lessons). Clients can request the WMS to be drawn in WGS 84 (EPSG:4326) or any coordinate system that the WMS publisher has explicitly enabled on the WMS. If you're not sure what coordinate systems the WMS publisher has enabled, then you could use the GetCapabilities method to find out before requesting a map image.|
|BBOX||-77.87304,40.78975,-77.85828, 40.80228,-77.85828,40.80228||The rectangular extent of the map to be returned by the WMS. This is given by specifying the coordinates of the lower left corner and the upper right corner in a comma delimited fashion.|
|FORMAT||image/png||The image format that should be returned by the WMS. In this case, the server will return a PNG. Your choice can affect the performance of your service. For remotely sensed imagery, a format like image/jpeg might result in less data being transferred between the server and the client (and therefore a faster draw time).|
|WIDTH||1200||The width, in pixels, of the image to be returned.|
|HEIGHT||900||The height, in pixels, of the image to be returned.|
When you request a map from a WMS, there are some required parameters that you must supply and some optional parameters that you may decide to supply if the WMS publisher has implemented them. All the parameters in the above table are required. Optional parameters can display things like time and elevation dimensions. Table 8 in Section 7.3.2 of the Version 1.3.0 WMS Specification shows all parameters for the GetMap request and whether they are required or optional. If you have questions about how to format the parameters, you can always refer to the specification; however, most GIS software gives you user-friendly interfaces for interacting with WMSs so that you don't have to formulate the URLs yourself.
Other WMS operations
Besides the GetMap request, WMS supports one other required operation (GetCapabilities) and an optional operation (GetFeatureInfo).
The GetCapabilities request returns metadata about the service, which you can use as a guide when making other types of requests. Here's what a GetCapabilities request would look like for ourland cover WMS:
Take a look through the XML response returned in your web browser when you hit the above URL
Notice that you can see information about each layer in the WMS, which is helpful when you are making a GetMap request and you want to know the appropriate names to specify for the LAYERS parameter.
<Layer queryable="1"> <Name>9</Name> <Title> <![CDATA[ LandCover_UTC_2006_StateCollege ]]> </Title> <Abstract> <![CDATA[ ]]> </Abstract> ... </Layer>
You can also see a list of the spatial reference systems that the service publisher has decided to support for the layer.
<CRS>CRS:84</CRS> <CRS>EPSG:4326</CRS> <CRS>CRS:4269</CRS>
GetFeatureInfo is an optional method that the service publisher can enable, allowing users to query the attribute data of a WMS layer at a specific location. This makes it possible to add interactive elements such as informational popups without enlisting the help of a second web service.
When you make a GetFeatureInfo request, you supply many of the same parameters as the GetMap request, with the addition of the screen coordinates of the pixel you want to query.
The land cover example says that the layer 9 is queryable, so try the following query URL to query for the feature at coordinates x=600 and y=300 within the map image with width=1200 and height=900:
The returned plain text response in this case will tell you that there that the pixel value for these coordinates is 5 which according to the description at http://www.pasda.psu.edu/uci/DataSummary.aspx?dataset=3155 means 'building':
@9 PixelValue;OBJECTID;COUNT; 5;5;1378041;
GetFeatureInfo is somewhat of a wildcard, because the WMS specification does not mandate any particular structure or format for the returned information. If you don't know who published the service, you must make a request and examine the response in order to understand how to work with the returned information. The GetCapabilities response can show you the supported INFO_FORMATs you can request:
<GetFeatureInfo> <Format>application/vnd.esri.wms_raw_xml</Format> <Format>application/vnd.esri.wms_featureinfo_xml</Format> <Format>application/vnd.ogc.wms_xml</Format> <Format>text/xml</Format> <Format>text/html</Format> <Format>text/plain</Format> ... </GetFeatureInfo>