Difference between revisions of "TilingStandard"
| Line 33: | Line 33: | ||
==See also== | ==See also== | ||
* [[Tiled imagery layer]] | * [[Tiled imagery layer]] | ||
| + | * [http://openlayers.org/pipermail/users/2006-November/000102.html on caching WMS via HTTP proxy versus WMS-C] | ||
Revision as of 07:21, 10 November 2006
Preamble
Tile-based web mapping is taking the world by storm. Tile-based web map clients are already a huge category of software, running from completely browser-based Javascript implementations like OpenLayers or the Google Maps API, to 100% desktop-based 3D worlds like Worldwind and Google Earth. What they all have in common is that they access map images from servers as fixed-size image tiles, and they expect high performance response to tile requests.
Thus far, most tiled map systems have been implemented as bound client-server pairs, with a particular protocol for describing tiles and an implicit understanding of a number of parameters like scales, projections, formats and so on. Some recent clients have been implemented that speak all the different tile server dialects and can consume from multiple servers.
In an ideal world, tile-based clients would be able to swap tile sources on the fly and use many different sources of tiles without recoding to new specifications each time.
In the "dynamic tile" world of the OGC Web Map Server (WMS) specification, this is already possible. However, dynamic mapping requires the server to render new tiles for every request, which is often a very slow process. Tile-based mapping is all about speed.
In an ideal world, tile-based clients would be able to use the data already published in WMS servers, but at a speed high enough to satisfy their end-users.
Cacheability
These standards will provide two approaches to enhancing "cacheability" in tile servers. The first approach will enhance the cacheability of existing WMS servers. The second approach will provide a standardized tile server API with strong cacheability.
Not Caching
Neither approach will say anything in particular about caching. Particular mechanisms of caching will differ from implementation to implementation, but the mechanism of caching should not affect the general goal of cacheability.
Not Rendering
Neither approach will say anything in particular about rendering. Cartographic rendering in a tile-based mapping system is a difficult problem, but it is orthogonal to the problem of enhancing cacheability.
Cacheability through Client Behavior
The "WMS Tiling Client Recommendation" is a non-binding recommendation paper for the authors of tiling clients. The paper provides a set of best practices for accessing legacy WMS servers which enhance the ability of the server maintainers to insert caching mechanisms in front of their servers without re-configurating or re-deploying the core WMS application. Standardization is provided for parameters, parameter order, projection, scale levels, bounding box rounding, and so on.
Cacheability through Server Standardization
The "Tile Map Service Specification" is a standards paper for the authors of interoperable tiling web map servers and clients. The paper provides a simple specification in the spirit of the original Web Map Server specification, providing the basis for a discoverable, interoperable server of tiled map images. The TMS specification will allow degrees of freedom on things like projection, format, scale levels, and so on, that are not possible with a single, global standard for tiles.