Difference between revisions of "WMS Tile Caching"

From OSGeo
Jump to navigation Jump to search
Line 27: Line 27:
 
== Possible Tile Scheme Parameters ==
 
== Possible Tile Scheme Parameters ==
  
* Maximal extent (typically, the entire world)
+
* '''Variable''' (i.e. likely to be different from one server to the next)
* Projection (typically, ''EPSG 4326'')
+
** Maximal extent (typically, the entire world... but not always!)
* Number of horizontal and vertical tiles at the maximal extent
+
** Number of horizontal and vertical tiles at the maximal extent
* Tile size in pixels
+
** Tile size in pixels
* Scale quantization factor (typically, powers of 2)
+
** Minimum scale (i.e., the number of zoom levels)
* Minimum scale (i.e., the number of zoom levels)
+
* '''Fixed''' (i.e. maybe we don't even want to complicate a proposal by including these things)
 +
** Projection (typically, ''EPSG 4326'')
 +
** Scale quantization factor (typically, powers of 2)
  
 
== Related Projects ==
 
== Related Projects ==

Revision as of 14:42, 29 March 2006

Goal

The goal of a WMS Tile Caching proposal, perhaps WMS-C for short, is to find a way to optimize the generation of map imagery for transmission across the Internet. The proposal needs to offer ideally a single means by which map clients can fetch tiles from existing servers, in such a way that map tiles can be cached on the server, or at an intermediate location, or even be completely pre-generated, if desired. The proposal should leverage the existing investment in OGC-compliant WMS servers on the 'Net.

Proposal

WMS-C as WMS Profile

One approach to take might be to define WMS-C (as in Web Mapping Service - Cached) as a constrained profile of OGC WMS that permits servers to optimize their image generation, and allows tiles to be cached at intermediate points. The basic idea is that, unlike with WMS, two different requests for a given WMS-C tile should form the exact same request URL. This invites several constraints on WMS:

  1. Minimal query string arguments
  2. Fixed query string argument ordering
  3. Fixed range of possible bounding boxes, computed from the WMS-C profile parameters
  4. Fixed precision on bounding box values
  5. Fixed tile size in pixels
  6. Fixed layer name and/or layer name ordering

Some means of identifying these constraints programmatically on a per-server basis, a la GetCapabilities might be desirable.

A WMS-C proxy or server should be free to return an error or a redirect, if it receives a WMS request that is not WMS-C compliant.

Existing Tiling Schemes

Possible Tile Scheme Parameters

  • Variable (i.e. likely to be different from one server to the next)
    • Maximal extent (typically, the entire world... but not always!)
    • Number of horizontal and vertical tiles at the maximal extent
    • Tile size in pixels
    • Minimum scale (i.e., the number of zoom levels)
  • Fixed (i.e. maybe we don't even want to complicate a proposal by including these things)
    • Projection (typically, EPSG 4326)
    • Scale quantization factor (typically, powers of 2)

Related Projects

Interested Parties