Difference between revisions of "WMS Tile Caching"

From OSGeo
Jump to navigation Jump to search
 
(80 intermediate revisions by 29 users not shown)
Line 1: Line 1:
 +
This is an old page (2006/2007), check the History tab.
 +
 +
WMS-C has been superceded by the OSGEO [[Tile Map Service Specification]] (TMS)  and the OGC [http://www.opengeospatial.org/standards/wmts Web Map Tile Service Standard] (WMTS).
 +
 +
WMS-C is supported still but if you are writing new applications you should look at TMS and WMTS.
 +
 
== Goal ==
 
== 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.
+
The goal of a '''WMS Tile Caching''' proposal, perhaps ''WMS-C'' for short, is to find a way to optimize the delivery of map imagery across the Internet. The proposal needs to offer ideally some means by which map clients can fetch tiles from existing servers, in such a way that the images can be cached on the server, or at an intermediate location, or even be completely pre-generated, if desired. Further, the proposal needs to offer a way of advertising that a cached tile set is available for a given layer from a particular WMS or WMS proxy. The proposal should leverage the existing investment in OGC-compliant WMS servers on the 'Net.
 +
 
 +
The two main questions to be addressed are:
 +
# How does a server advertise its cacheable image tiles?
 +
# How does a client request possibly cached image tiles?
  
 
== Proposal ==
 
== Proposal ==
Line 7: Line 17:
 
=== WMS-C as WMS Profile ===
 
=== 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 [http://www.opengeospatial.org/docs/01-068r2.pdf 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 HTTP GET request. This invites several constraints on WMS ''GetMap'' requests:
+
One approach to take might be to define ''WMS-C'' (as in ''Web Mapping Service - Cached'') as a constrained profile of [http://www.opengeospatial.org/docs/01-068r2.pdf OGC WMS] that permits servers to optimize their image generation, and allows tiles to be cached at intermediate points. A WMS-C service would likely only deliver images for bounding boxes aligned to a given rectangular origin and grid, and only at particular scale levels.
 +
 
 +
The basic idea is that, unlike with WMS, two different requests for a given WMS-C tile should form the exact same HTTP GET request. This invites several constraints on WMS ''GetMap'' requests:
  
 
# Minimal query string arguments (i.e. no optional arguments permitted, versus §7.2)
 
# Minimal query string arguments (i.e. no optional arguments permitted, versus §7.2)
Line 20: Line 32:
 
Some means of identifying these constraints programmatically on a per-server basis, a la ''GetCapabilities'' might be desirable. From the table below, it appears that minimum/maximum scale (and scale quantization factor, which should probably never be other than 2) are the only suggested tiling regime parameters that would be difficult to directly express in a WMS GetCapabilities document. Is there some existing way to add custom parameters to a GetCapabilities declaration?
 
Some means of identifying these constraints programmatically on a per-server basis, a la ''GetCapabilities'' might be desirable. From the table below, it appears that minimum/maximum scale (and scale quantization factor, which should probably never be other than 2) are the only suggested tiling regime parameters that would be difficult to directly express in a WMS GetCapabilities document. Is there some existing way to add custom parameters to a GetCapabilities declaration?
  
−
Note that the ''LAYERS'', ''STYLES'', ''SRS'', ''HEIGHT'', ''WIDTH'', and ''FORMAT'' arguments to a ''GetMap'' request would become fixed for a particular WMS-C tile service, but the WMS specification would still require their inclusion in a WMS-C request (§ 7.2).
+
Note that the ''LAYERS'', ''STYLES'', ''SRS'', ''HEIGHT'', ''WIDTH'', and ''FORMAT'' arguments to a ''GetMap'' request would become fixed for a particular WMS-C tiled layer, but the WMS specification would still require the inclusion of these arguments in every WMS-C request (§ 7.2).
  
−
A WMS-C proxy or server should be free to return an exception or a redirect, if it receives a WMS request that is not WMS-C compliant.
+
A WMS-C proxy or server should be free to return an exception or a redirect, if it receives a WMS request that is not WMS-C compliant, or involves a bounding box that does not correspond to a single tile in the cache.
 +
 
 +
=== Calculating Valid Tile Extents for a Given Request ===
 +
 
 +
WMS tile caching implies fixed scale or zoom levels. Typically, each valid scale level would be half that of the next larger scale. It would be worth writing reference code to help developers figure out which tiles they need to load to cover a given bounding box at a given scale.
  
 
=== Possible Tile Scheme Parameters ===
 
=== Possible Tile Scheme Parameters ===
Line 28: Line 44:
 
{| cellpadding="5" cellspacing="1" border="1"
 
{| cellpadding="5" cellspacing="1" border="1"
 
| '''Parameter''' || '''Default value''' || '''Specifiable in WMS GetCapabilities?'''
 
| '''Parameter''' || '''Default value''' || '''Specifiable in WMS GetCapabilities?'''
 +
|-
 +
| "This service suppports tiling." || ''none'' || ''<KeywordList>'' contains the string 'tiled', perhaps? (§7.1.4.5.3)
 
|-
 
|-
 
| Projection || EPSG:4326 || ''<SRS>''  
 
| Projection || EPSG:4326 || ''<SRS>''  
Line 33: Line 51:
 
| Maximal extent || (-180,-90,180,90) || ''<BoundingBox>'' (§7.1.4.5.7)
 
| Maximal extent || (-180,-90,180,90) || ''<BoundingBox>'' (§7.1.4.5.7)
 
|-
 
|-
−
| Number of horizontal and vertical tiles at the maximal extent || ''none'' || Could be implied by ''<ScaleHint>'' (§7.1.4.5.8, but note that the format is weakly specified)
+
| Number of horizontal and vertical tiles at the maximal extent || ''none'' || Could be implied by ''<ScaleHint>'' (§7.1.4.5.8, but note that the format is weakly specified)... Alternately, could use ''<DataURL>'' (§7.1.4.5.14)
 
|-
 
|-
 
| Tile size in pixels || some power of 2 || <Layer> attribute ''fixedWidth'', ''fixedHeight'' (§7.1.4.6)
 
| Tile size in pixels || some power of 2 || <Layer> attribute ''fixedWidth'', ''fixedHeight'' (§7.1.4.6)
 
|-
 
|-
−
| Minimum scale || ''none'' || ''<ScaleHint>'' (see note, above)
+
| Minimum scale || ''none'' || ''<ScaleHint>'' or ''<DataURL>'' (see note, above)
 
|-
 
|-
−
| Scale quantization factor || 2 || ?
+
| Scale quantization factor || 2 || ''<DataURL>''
 
|}
 
|}
  
 
----
 
----
 +
 +
== Other Considerations ==
 +
 +
* Would non-rectangular tessellations yield more efficient results? If so, which tessellations to consider? Also, are the processing and bandwidth advantages of a non-rectangular tessellation outweighed by the potential implementation complexity?
 +
* Norm Vine rightly points out that a tile request basically boils (or should boil down to) Layer + Zoom Level + Row + Column. Can we define an even simpler method for requesting tiles from servers in the know? How are those capabilities advertised, if not shoehorned into WMS? Note that WorldWind basically already has a mechanism for this. Their tiling requests basically look like:
 +
 +
http://domain.tld/service?L=0&X=1&Y=2
 +
* Like all caching schemes, WMS-C caches would need to be cognizant of expiration. Easy with using the proper HTTP headers. There is a wide range of freshness/staleness, with OpenStreetMap being highly volatile, and Landsat being pretty stable (until the ice caps melt ;).
 +
* Several people (particularly Paul Spencer and Chris Schmidt) have argued that a separate ''GetTile'' request should be used. This topic probably warrants discussion.
 +
 +
== Distributed Caching ==
 +
 +
* A WMS-C standard would permit tile caching through [http://www.coralcdn.org/ Coral]. However, the World Wind community's experience has been that using Coral to serve tiles results in frustratingly high latency.
 +
* Alternately, one could do (distributed) [[Distributed Tile Caching|peer-to-peer tile caching]] optimized specifically for geographic space, which might still suffer the latency issues associated with P2P networks.
  
 
== Existing Tiling Schemes ==
 
== Existing Tiling Schemes ==
  
 
* Mikel Maron's description of [http://lists.eogeo.org/pipermail/tiling/2006-March/000017.html OnEarth's LandSat tiling scheme]
 
* Mikel Maron's description of [http://lists.eogeo.org/pipermail/tiling/2006-March/000017.html OnEarth's LandSat tiling scheme]
−
* World Wind's tiling scheme: [http://www.ceteranet.com/nww-tile-struct.pdf PDF], [http://www.worldwindcentral.com/wiki/Making_Layers wiki]
+
* World Wind's LandSat tiling scheme: [http://www.ceteranet.com/nww-tile-struct.pdf PDF], [http://www.worldwindcentral.com/wiki/Making_Layers wiki]
 +
* World Wind ''QuadTileSet'' [http://rafb.net/paste/results/S3I8Zr92.html sample description], [http://forum.worldwind.arc.nasa.gov/lofiversion/index.php?t2965.html forum discussion], [http://rafb.net/paste/results/z2dQKa54.html sample PHP code] to fetch WW tiles for a given WMS GetMap request
 +
* osgPlanet's C++ code for [http://www.remotesensing.org/cgi-bin/cvsweb.cgi/osgPlanet/src/osgPlanet/osgPlanetGridUtility.cpp?rev=HEAD;content-type=text%2Fx-cvsweb-markup tiling the Earth]
 +
* WorldWind Example code for tiling the Earth (needs Proj.4 and GDAL libraries)[http://download.worldwindcentral.com/dstile-0.2.tar.gz DSTile and Tilepack]
 +
* OnEarth's code for intercepting WW requests and converting into WMS requests and caching them [http://www.twobeds.com/upload/userfiles/adamhill/lucians%20code%20-%20cache_1_1.gz?PHPSESSID=f485cf3fd66cd30ad7a4f814a127d2cb from Lucian Plesa]
 +
* Casey Chestnut explains Microsoft Virtual Earth's tiling scheme + code to experiment with the URL's [http://www.brains-n-brawn.com/veWorldWind/]
 +
* GeoOdyssey's [http://www.geodyssey.com/tileshare/index.html TileShare scheme]
 +
* Chuck Stein's [http://www.geongrid.org/workshops/geonvis2005/Presentations/ChuckStein/GeoFusion.ppt GeoFusion presentation] from GEON (warning: PowerPoint)
 +
* [http://globe.sintef.no/documentation/projection.html The Finite Nearly-Conformal Normal Cylindrical Projection] (Aasgaard's map projection)
 +
 
 +
Note: WW and OnEarth's schemes are pretty much identical, the WW client just allows you to specify arbitrary tile sizes, coverages and number of levels to accomodate a given client.
  
 
== Related Projects ==
 
== Related Projects ==
  
−
* [http://www.ossim.org/tiki-read_article.php?articleId=3 osgPlanet]
+
* [http://www.ossim.org/osgPlanet.html osgPlanet]
 
* [http://worldwind.arc.nasa.gov/ NASA WorldWind] ([http://www.worldwindcentral.com/wiki/Main_page wiki])
 
* [http://worldwind.arc.nasa.gov/ NASA WorldWind] ([http://www.worldwindcentral.com/wiki/Main_page wiki])
−
* [http://mapbuilder.sf.net/ Community MapBuilder]
+
* [http://worldkit.org/ worldKit]
 +
* [http://communitymapbuilder.org/ Community MapBuilder]
 +
* [http://ka-map.maptools.org/ ka-Map!]
 +
* [http://openlayers.org/ OpenLayers]
 +
* [http://www.geomoose.org/moose/ GeoMoose]
 
* other AJAX map clients, presumably
 
* other AJAX map clients, presumably
  
 
== Interested Parties ==
 
== Interested Parties ==
 +
 +
There is a mailing list on tiling, [http://lists.osgeo.org/mailman/listinfo/tiling OSGEO Tiling]
 +
but it looks pretty moribund (no activity since 2011)
 +
 
* [[User:SchuylerErle|Schuyler Erle]]
 
* [[User:SchuylerErle|Schuyler Erle]]
 
* [[User"Adoyle"|Allan Doyle]]
 
* [[User"Adoyle"|Allan Doyle]]
 +
* [[user"Nhv"|Norman Vine]]
 +
* [[user"Joshli"|Josh Lieberman]]
 +
* [[user"Adamhill"|Adam Hill]]
 +
* [[user"bitner"|David Bitner]]
 +
* [[user:Mikel|Mikel Maron]]
 +
* [[user:mpg|Michael P. Gerlek]]
 +
* [[user:stvn|Steven M. Ottens]]
 +
* [[user:Pagameba|Paul Spencer]]
 +
* [[user:hallkbrdz|Bryan Hall]]
 +
* [[user:tschaub|Tim Schaub]]
 +
* [[user:dmorissette|Daniel Morissette]]
 +
* [[user:dpatton|Dave Patton]]
 +
* [[user:cholmes|Chris Holmes]]
 +
* [[user:pwramsey3|Paul Ramsey]]
 +
* [[user:luisw|Luis W. Sevilla]]
 +
* [[user:ominiverdi|Lorenzo Becchi]]
 +
* [[user:wilfred|Wilfred Springer]]
 +
* [[user:fpurcell|Frank Purcell]]
 +
* [[user:Pauldendulk|Paul den Dulk]]
 +
* [[user:Schpidi|Stephan Meißl]]
 +
* [[user:Mornsunrain|Xi Chen]]
 +
* [[user:blammo|Bob Basques]]
 +
* [[user:Woodbri|Stephen Woodbridge]]
 
* ''add yourself''
 
* ''add yourself''
 +
 +
[[Category:Standards]]
 +
[[Category:Tiling]]

Latest revision as of 12:14, 24 December 2012

This is an old page (2006/2007), check the History tab.

WMS-C has been superceded by the OSGEO Tile Map Service Specification (TMS) and the OGC Web Map Tile Service Standard (WMTS).

WMS-C is supported still but if you are writing new applications you should look at TMS and WMTS.

Goal

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

The two main questions to be addressed are:

  1. How does a server advertise its cacheable image tiles?
  2. How does a client request possibly cached image tiles?

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. A WMS-C service would likely only deliver images for bounding boxes aligned to a given rectangular origin and grid, and only at particular scale levels.

The basic idea is that, unlike with WMS, two different requests for a given WMS-C tile should form the exact same HTTP GET request. This invites several constraints on WMS GetMap requests:

  1. Minimal query string arguments (i.e. no optional arguments permitted, versus §7.2)
  2. Fixed query string argument ordering and case (versus §6.4.1; q.v. also §7.2.2, Table 8)
  3. Fixed range of possible bounding boxes, computed from the WMS-C profile parameters
  4. Fixed precision on bounding box values (clarifying §6.5.6)
  5. Fixed tile size in pixels
  6. Fixed layer name and/or layer name ordering
  7. Fixed styling
  8. Fixed output format

Some means of identifying these constraints programmatically on a per-server basis, a la GetCapabilities might be desirable. From the table below, it appears that minimum/maximum scale (and scale quantization factor, which should probably never be other than 2) are the only suggested tiling regime parameters that would be difficult to directly express in a WMS GetCapabilities document. Is there some existing way to add custom parameters to a GetCapabilities declaration?

Note that the LAYERS, STYLES, SRS, HEIGHT, WIDTH, and FORMAT arguments to a GetMap request would become fixed for a particular WMS-C tiled layer, but the WMS specification would still require the inclusion of these arguments in every WMS-C request (§ 7.2).

A WMS-C proxy or server should be free to return an exception or a redirect, if it receives a WMS request that is not WMS-C compliant, or involves a bounding box that does not correspond to a single tile in the cache.

Calculating Valid Tile Extents for a Given Request

WMS tile caching implies fixed scale or zoom levels. Typically, each valid scale level would be half that of the next larger scale. It would be worth writing reference code to help developers figure out which tiles they need to load to cover a given bounding box at a given scale.

Possible Tile Scheme Parameters

Parameter Default value Specifiable in WMS GetCapabilities?
"This service suppports tiling." none <KeywordList> contains the string 'tiled', perhaps? (§7.1.4.5.3)
Projection EPSG:4326 <SRS>
Maximal extent (-180,-90,180,90) <BoundingBox> (§7.1.4.5.7)
Number of horizontal and vertical tiles at the maximal extent none Could be implied by <ScaleHint> (§7.1.4.5.8, but note that the format is weakly specified)... Alternately, could use <DataURL> (§7.1.4.5.14)
Tile size in pixels some power of 2 <Layer> attribute fixedWidth, fixedHeight (§7.1.4.6)
Minimum scale none <ScaleHint> or <DataURL> (see note, above)
Scale quantization factor 2 <DataURL>

Other Considerations

  • Would non-rectangular tessellations yield more efficient results? If so, which tessellations to consider? Also, are the processing and bandwidth advantages of a non-rectangular tessellation outweighed by the potential implementation complexity?
  • Norm Vine rightly points out that a tile request basically boils (or should boil down to) Layer + Zoom Level + Row + Column. Can we define an even simpler method for requesting tiles from servers in the know? How are those capabilities advertised, if not shoehorned into WMS? Note that WorldWind basically already has a mechanism for this. Their tiling requests basically look like:
http://domain.tld/service?L=0&X=1&Y=2
  • Like all caching schemes, WMS-C caches would need to be cognizant of expiration. Easy with using the proper HTTP headers. There is a wide range of freshness/staleness, with OpenStreetMap being highly volatile, and Landsat being pretty stable (until the ice caps melt ;).
  • Several people (particularly Paul Spencer and Chris Schmidt) have argued that a separate GetTile request should be used. This topic probably warrants discussion.

Distributed Caching

  • A WMS-C standard would permit tile caching through Coral. However, the World Wind community's experience has been that using Coral to serve tiles results in frustratingly high latency.
  • Alternately, one could do (distributed) peer-to-peer tile caching optimized specifically for geographic space, which might still suffer the latency issues associated with P2P networks.

Existing Tiling Schemes

Note: WW and OnEarth's schemes are pretty much identical, the WW client just allows you to specify arbitrary tile sizes, coverages and number of levels to accomodate a given client.

Related Projects

Interested Parties

There is a mailing list on tiling, OSGEO Tiling but it looks pretty moribund (no activity since 2011)

Retrieved from "http://wiki.osgeo.org/w/index.php?title=WMS_Tile_Caching&oldid=68003"