Web Map Tile Service (WMTS)

Overview

Tile mapping techniques are becoming increasingly popular. A Web Map Tile Service (WMTS) provides access to cartographic maps of geo-referenced data, not direct access to the data itself. The tile service standard specifies the way in which map tiles are requested by clients, and the ways that servers describe their holdings.

Additional Information

Standards     

OpenGIS® Web Map Tile Service Implementation Standard

Related Information

Web Map Service (WMS)

Notes

The implementation standard developed by the Open Geospatial Consortium (OGC) is based on the collaborative development work on tile mapping conducted by the Open Source Geospatial Foundation.

Additional Information: Tile Mapping Techniques

Background

WMTS Methodology

Background

The OpenGIS® Web Map Tile Service Implementation Standard builds on earlier efforts to develop scalable, high performance services for web-based distribution of cartographic maps. WMTS is inspired by the OSGeo Tile Map Service Specification. The team that worked on this standard also considered similar initiatives, such as Google maps and NASA OnEarth. This OCG® standard includes both the resource (RESTful approach) and procedure-oriented architectural styles (KVP and SOAP encoding) in an effort to harmonize this interface standard with the OSGeo Tile Map Service Specification.

WMTS complements earlier efforts to develop services for the web-based distribution of cartographic maps. The OCG®-WMTS provides a complementary approach to the OGC® Web Map Service (WMS) for tiling maps. WMS focuses on rendering custom maps, and is an ideal solution for dynamic data or custom-styled maps (combined with the OGC® Styled Layer Descriptor (SLD) standard). WMTStrades the flexibility of custom map rendering for the scalability possible by serving staticdata (base maps) where the bounding box and scales have been constrained to discrete tiles. The fixed set of tiles allows for the implementation of a WMTS service using a web server that simply returns existing files. The fixed set of tiles also enables the use of standard network mechanisms for scalability, such as distributed cache systems.

The WMTS standard has been structured as a stand-alone standard, but shares many concepts with the Web Map Service (WMS).

Open Source Geospatial Foundation (OSGeo)

The Open Source Geospatial Foundation (OSGeo) was created to support and build the highest-quality open source geospatial software. Their goal is to encourage the use and collaborative development of community-led projects. The community Wiki of the OSGeo is the place where documents can be created collaboratively (ie. adoption processes, user hints, suggestions, committee notes, etc.).

The Tile Map Service (TMS) Specification has been the work of a loose community of participants interested in client/server mapping solutions that use multi-resolution image pyramids. It is meant to be a baseline for the implementation of client/server mapping software. It is not an "official standard" nor is it endorsed by OSGeo as an official project or work product of the Foundation.

WMTS Methodology

The WMTS Implementation Standard provides a standard-based solution to serve digital maps using pre-defined image tiles. The service advertises the tiles it has available through a standardized declaration in the ServiceMetadata document common to all OGC® web services. This declaration defines the tiles available in each layer (i.e. each type of content), in each graphical representation style, in each format, in each coordinate reference system, at each scale, and over each geographic fragment of the total covered area. The ServiceMetadata document also declares the communication protocols and encodings through which clients can interact with the server. Clients can interpret the ServiceMetadata document to request specific tiles.

The WMTS standard complements the existing Web Map Service (WMS) standard. The WMS standard focuses on flexibility in the client request, enabling clients to obtain exactly the final image they want. A WMS client can request that the server create a map by overlaying an arbitrary number of the map layers offered by the server, over an arbitrary geographic bound, with an arbitrary background color at an arbitrary scale, in any supported coordinate reference system. The client may also request that the map layers be rendered using a specific server-advertised style or even use a style provided by the client when the WMS server implements the OGC® Styled Layer Descriptor (SLD) standard. However, all this flexibility comes at a price: server image processing must scale with the number of connected clients and there is only limited potential to cache images between the server and the client since most images are different.

As web service clients have become more powerful, it is now possible to consider an alternative strategy which forces the clients to perform image overlays themselves, and which limits the clients to requesting map images which are not at exactly the right position, thereby forcing clients to mosaic the tiles obtained from the server and clip the set of tiles into a final image. This restriction of image requests to a fixed, pre-defined set allows servers to scale based on communication processing abilities rather than image processing abilities, because servers can pre-render some or all of their images and can use image caching strategies. The fixed set of images also enables network providers to cache images between the client and the server, reducing latency and bandwidth use. Popular, non-standardized, commercial implementations of this approach (such as Google Maps, Microsoft Virtual Earth and Yahoo! Maps) have already shown that there are clear performance benefits to adopting this methodology.

Some WMS servers have already embarked on this road, developing their own tiling structures built by constraining WMS GetMap requests to a fixed set and then advertising those constraints in their service metadata. Although this mechanism enables those servers to scale as just described, the tiling structure and the advertising and discovery mechanisms are not standardized. That unfortunately limits interoperability and forces developers to build, for each server, special clients that can understand the server-advertised constraints and limit the WMS GetMap requests issued by the client to exactly the requests understood by the particular server. The WMTS standard offers a standardized approach to declaring the images which a client can request from a server, enabling a single type of client to be developed for all servers. While developing a profile of WMS was initially considered, limiting a WMS in the ways important to allow efficient access to cacheable tiles proved awkward, while forcing implementors to read both a standard and a profile seemed less efficient than developing the WMTS stand-alone specification.

WMTS specifies the standard in two stages:

1. An abstract specification describes the semantics of the resources offered by the server and requested by the client. This abstract definition specifies the semantics of the ServiceMetadatadocument, of the Tileimages or representations, and of the optional FeatureInfodocuments providing descriptions of the maps at specific locations.
2. Several different concrete exchange mechanisms between clients and servers, in two different architectural styles, are specified. WMTS defines the GetCapabilities, GetTile and optional GetFeatureInfo operations for procedure-oriented architectural style-based approaches using several different message encodings, including messages encoded using Key-Value Pairs (KVP), XML messages, or XML messages embedded in SOAP envelopes. WMTS also defines the request mechanisms and endpoint publishing strategy to enable a resource-oriented architectural style based on web-based URL endpoints, allowing clients to simply request the ServiceMetadata, Tile, and FeatureInfo resources as documents.

This resource-oriented architecture style offers key advantages in ease of deployment, scalability and network effects of web services. The RESTful pattern provides the ability to set up conformant WMTS servers simply. If all the images are pre-rendered, a WMTS server could even be created using no image processing logic at all, relying only on a normal web server to return the static ServiceMetadata XML document and to provide the image tile files. This is important for deployment purposes as many Internet service providers (especially the free ones) allow web pages and static content hosting but do not allow using CGI, ASP, or more advanced applications for security reasons. The RESTful approach, therefore, enables small organizations to provide geographic data using readily available services or simple web server configurations. This approach also scales dramatically since the issues of serving fixed resources in high volumes have been continuously tackled over the past decades. Finally, this approach can benefit from network scaling effects since the images are considered by the HTTP protocol to be standard web resources, and network providers can leverage their existing technologies to improve the flow of those resources to requesting clients.