WMS Tiling Client Recommendation

Introduction

This document details extensions to and constraints on the OGC WMS 1.1.1 specification for the purpose of (a) improving the quality and scalability of tiled maps, particularly on the Web, and (b) making it possible to cache the results of tiled WMS requests.

This recommendation relies on two basic concepts to support this purpose: First, we posit that the optimal way to deliver map imagery on the Web is in the form of image tiles of fixed width and height, referenced to some fixed geographic grid at fixed scales. A "valid" tile request is one that conforms to the specification of fixed image parameters and geographic grid(s) for a given layer. By analogy, an "invalid" tile request is one that does not.

Second, we observe that caching of HTTP GET requests is made possible by constraining the URL parameters used in the request. This recommendation identifies the WMS GetMap parameters minimally needed for a client to request a valid tile.

For more information and further background, please refer to the TilingStandard and Tile Map Service Specification documents on this wiki.

Tiling Profiles

WMS servers that support tiling should publish a profile as part of their GetCapabilities advertisement, which specifies all of the information needed to request valid tiles from the tile server. The required information comes in two varieties: (1) WMS request parameters which must be supplied to the server verbatim, and (2) a tile grid definition, which a client can use to calculate the extents of valid tiles.

Verbatim Request Parameters

Each tiling profile needs to establish verbatim values for the following WMS request parameters:

• SRS
• HEIGHT
• WIDTH
• FORMAT

Additionally, each tiled layer is defined in terms of verbatim values for:

• LAYERS
• STYLES

Tile Grid Definition

Rather than rely on the much-overloaded concept of "scale," this recommendation instead will describe scales or zoom levels in terms of "resolution," defined in terms of map units (typically degrees or meters) per pixel.

In order to be cacheable, requested tiles must have bounding boxes aligned to a set of consistent grids at successively larger map resolutions in geographic space. Tile grids originate in the lower left corner of the tiled layer's BoundingBox.

A tiling profile must supply a list of supported resolutions, corresponding to the different "zoom levels" it may be used to serve.

The bounding box for a valid tile request must align to the grid given by the layer's tiling profile. In practical terms, this means the BBOX coordinates must be equal to the grid origin, plus some non-negative integer multiple of the tile size in pixels, multiplied by one of the supported resolutions listed in the layer's tiling profile.

Global Profiles

The following pre-defined global profiles use resolution values that are related by powers of two. Servers may offer tiles at as many resolution levels as are appropriate to the data represented.

Profile #0 (Unprojected)

All tiling WMS servers should be able to deliver tiles in a generic global profile, referred to here as "Profile #0". Profile #0 specifies the following tiling parameters:

• Width: 256 px
• Height: 256 px
• Format: image/png
• SRS: EPSG:4326
• BoundingBox: -180 -90, 180 90
• Resolutions: 0.703125, 0.3515625 ...

There are two tiles at the highest resolution of Profile #0.

Mercator Profile

• Width: 256 px
• Height: 256 px
• Format: image/png
• SRS: OSGEO:41001
• BoundingBox: -20037508.34 -20037508.34 20037508.34 20037508.34
• Resolutions: 156543.03390625 78271.516953125 ...

There is one tile at the highest resolution of the basic Mercator profile.

GetCapabilities Responses

Internal DTD

Tiling WMS servers should include the following internal DTD to advertise the presence of tiling metadata, as recommended by the OGC WMS 1.1.1 specification:

<!DOCTYPE WMT_MS_Capabilities SYSTEM
  "http://schemas.opengeospatial.net/wms/1.1.1/WMS_MS_Capabilities.dtd" [
  <!ELEMENT VendorSpecificCapabilities (TileSet*) >
  <!ELEMENT TileSet (SRS, Width, Height, Format, BoundingBox?, Layers*, Styles*) >
  <!ELEMENT Width (#PCDATA) >
  <!ELEMENT Height (#PCDATA) >
  <!ELEMENT Layers (#PCDATA) >
  <!ELEMENT Styles (#PCDATA) >
 ]>

Example VendorSpecificCapabilities

A suitable tiling WMS GetCapabilities response might look like this:

VendorSpecificCapabilities>
  <TileSet>
    <SRS>EPSG:4326</SRS>
    <LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
    <Width>256</Width>
    <Height>256</Height>
    <Format>image/png</Format>
    <Layers>coastline</Layers>
    <Styles></Styles>
  </TileSet>
  <TileSet>
    <SRS>OSGEO:41001</SRS>
    <LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
    <Width>256</Width>
    <Height>256</Height>
    <Format>image/png</Format>
    <Layers>coastline</Layers>
    <Styles></Styles>
  </TileSet>
 </VendorSpecificCapabilities>

This declaration asserts that our hypothetical tiling WMS server supports tiling in the two basic global profiles for the coastline layer defined elsewhere in the capabilities response.

Tile Requests

Requests for map tiles from a WMS server should include the vendor-specific parameter tiled=true.

Verbatim request parameters must be given in a tiled WMS request exactly as specified in the tiling profile / layer definition.

Valid tile requests should omit any optional WMS request parameters, except those required in practice by the server in question.

All decimal values given in a tiled WMS request (e.g. in the BBOX parameter) should be rounded to six places, with trailing zeros omitted.

By convention, the non-standard SRS codes proposed by the associated [[Tile Map Service Specification]] are recommended for use in tiled WMS requests as well.

Invalid Requests

If a request is made with tiled=true, a tiling WMS server may respond with HTTP 404 or 500 to indicate that a request fails to meet the recommendations given here.

Miscellany

This recommendation is based on discussion at the FOSS4G Birds of a Feather Session on Web Map Tiling in Lausanne, Switzerland on 12 Sep 2006.

By consensus of that meeting, the recommendation is published under a Creative Commons Attribution-ShareAlike license.