Map Tiles and Cached Map Services
The tiling of large maps is an old practice. Large paper maps have always been divided into a series of map sheets at various scales. With the increasing popularity of web mapping applications and the rapid growth of map data availability, the pre-computation and caching of map image tiles has become a common practice in map servers as they use far fewer server resources than maps rendered on demand. In this way, the time required for the client to display complex and high quality base maps is mainly limited by the bandwidth of its connection with the map server.
Google was one of the first major mapping providers to adopt the tiled web maps. Others, like Bing and OpenStreetMap, followed the same practice. GIS software vendors, like Esri and Oracle, provide functionality for map tiling and caching of both vector layers and raster images. They also support single fused and multi-layer tiles. In the former, a group of layers are combined into a single image per tile, while in the later these layers appear in the client as a collection of layers with enabled feature selection and controllable visibility.
The creation of map tiles is according to the values of a series of properties. These properties include the shape and size of tiles, numbering of zoom levels, subdivision scheme of a tile to result the tiles in the next zoom level, numbering of individual tiles, and map projection of tiles. Combining tiles from various servers, including mapping providers, might involve some simple or complex transformations. The standardization of the values for the above properties may save time in rendering the fetched tiles in the client.
Google Maps conventions for these values are as follows. All map tiles are square-shaped and equal sized, i.e., 256×256 pixels. The world is rendered in a single tile at the outer most zoom level and numbered as 0. This layout depicts the earth on the Web Mercator projection (latitude values range roughly from -85.0511 to +85.0511 degrees), and excludes polar areas. The projection adopted for all tiles is Web Mercator with WGS’84 datum. Each tile at any zoom level k is replaced by 4 equal-sized tiles at zoom level k+1. As the size of each new tile is still 256×256 pixels, the pixel size at level k+1 is four times smaller than the pixel size at level k. The number of tiles at zoom level k is equal to 4^k, e.g., at zoom levels 3 and 17, there are 64 and 17,179,869,184 tiles, while the ground resolution is 20km and 1.19m per pixel, respectively. The numbering of a tile at zoom level k is described by a pair of integers (x,y), where x is the column number of the tile, starting from the longitude of 180 degrees and heading East, and y is the row number of the tile, starting from the latitude of +85.0511 degrees and heading South (Figure 1).
Figure 1. Google Maps Tiling Scheme: the first three zoom levels, the tiles, and their numbering. All tiles are square-shaped and 256×256 pixels.
Most major mapping providers and vendors have made an effort to align with Google’s convention and/or provide transformation functions to/from it, as an effort towards standardization. For example, Esri decided to move ArcGIS Online to Google tiling scheme and change the tile size from 512×512 pixels to 256×256 pixels as early as 2009. Bing Maps tiling system follows an interesting encoding of tiles, which is based on Quadtree spatial index structure. This encoding is called “quadtree keys” or “quadkeys” in short and optimizes the storage and indexing of tiles.
The fetching of map tiles from a map server to a client can be accelerated by using appropriate indexing and caching strategies at three levels: the server, the ISP, and the client. At the server side, tile files must be indexed appropriately using B+tree or Quadtree variants to accelerate their access on demand, while a caching process can support fast delivery of the tiles. Sophisticated algorithms on top of index structures may efficiently support the access to adjacent tiles (after a pan operation) or tiles at different zoom levels (after a zoom in/out operation). At an intermediate Internet Service Provided (ISP), a shared cache can be established to allow multiple clients retrieve map tiles faster. At the client side, appropriate handling of cache memory content can save time by avoiding reloading recently fetched tiles.
In 2010, the Open Geospatial Consortium (OGC) developed and published the Web Map Tile Service (WMTS) a standard protocol for serving pre-rendered georeferenced map tiles over the web. This service has extended the oldest and most popular standard for web mapping, the Web Map Service (WMS) to support tiles, and replaced the Tile Map Service (TMS) previously developed by the Open Source Geospatial Foundation (OSGeo). Currently, WMTS is a well-recognized and widely used service for tile request and serving.
No doubt, a cached map service can drastically improve the time a client takes to fetch and display base maps and other map layers. However, the creation of pre-rendered tiles is a very time consuming task and it is recommended only for base maps and layers that change on a very slow cycle. In the planning phase of map cache creation it is also important to estimate how popular each tile could be. If some areas are expected to be downloaded very often in high resolution (e.g., downtown Toronto in high zoom levels), the generation and delivery of tiles may be worthy even for relatively dynamic layers. On the other hand, for unpopular areas (e.g., middle of the Atlantic Ocean in middle or high zoom levels), the pre-rendering map tiles may be a waste of time even for static layers.
In the future, the major mapping providers are expected to offer more flexibility in the tiling structure and content. Among the new features could be the variable tile shapes and sizes, non-fixed zoom levels, enhanced multi-layer tiling, and a broad availability of tiles in different projections, not necessarily rectangular. Google Maps API already provides the “Projection” interface that only supports transformations into rectilinear coordinates and example tiles in Gall Peters projection. Offering tiles in various projections will provide alternative base maps to Web Mercator projection that introduces big distortions in high latitudes or excludes the polar areas from the world map.
Keywords: Cached Map Service, Slippy map, Web Map Tile Service, Map Tile Server.
References
Bing Maps Tile System. https://msdn.microsoft.com/en-us/library/bb259689.aspx [Visited on Dec. 1st, 2015]
Esri. What is a Cached Map Service. http://webhelp.esri.com/arcgisserver/9.2/dotnet/manager/publishing/static_map_svcs [Visited on Dec. 1st, 2015]
Google Maps API. https://developers.google.com/maps/documentation/javascript/maptypes?hl=en Google Developers. [Visited on Dec. 1st, 2015]
MapTiler. Tiles à la Google Maps: Coordinates, Tile Bounds and Projection. http://www.maptiler.org/google-maps-coordinates-tile-bounds-projection/ [Visited on Dec. 1st, 2015]
OSM Wiki. Slippy Map. http://wiki.openstreetmap.org/wiki/Slippy_Map [Visited on Dec. 1st, 2015]
Stefanakis, E., 2015. Web Mercator: the de facto standard, the controversy, and the opportunity. GoGeomatics. Magazine of GoGeomatics Canada. October 2015. http://www.gogeomatics.ca/web-mercator-the-de-facto-standard-the-controversy-and-the-opportunity [Visited on Dec. 1st, 2015]
