5.2. The Idea of Tiled Maps

Acknowledgements: This material is a slight derivative of a course module written by Sterling Quinn of the John A. Dutton e-Education Institute, College of Earth and Mineral Sciences, The Pennsylvania State University, and was produced with permission from the author. We thank the author, and Penn State for permission to use. The material is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.

5.2.1 Introduction to Tiled Maps

The earliest web maps were typically drawn on the fly by the server, no matter how many layers were available or requested. The symbol sets and labeling choices for this type of map are relatively limited and complex to work with. In fact, for many years, web cartographers had to build a map with minimal layer set and simple symbols to avoid hampering performance (e.g., speed to which the map would be displayed on the client computer’s end). In many cases, a cartographer was not even involved; instead, the web map was made by a server administrator tweaking eXtensible Markup Language (XML) files that defined the layer order, symbol sizes, and so forth. This was the case with both open specification web services (like WMS) and proprietary web services (like Esri ArcIMS). Part of this approach stemmed from early efforts to make web GIS applications look exactly like their desktop counterparts. Sometimes these are referred to as “Swiss Army Knife applications” because they try to do everything (you may know one!). People expected that in a web GIS they should be able to toggle layer visibility, reorder layers, change layer symbols on the fly, and do everything else that they were accustomed to doing using desktop GIS packages. Ironically, this mindset prevailed at a time when web technology was least suited to accommodate it.

In the mid-2000s, after Google Maps, Microsoft Virtual Earth (now Bing Maps), and other popular mapping applications hit the web, people started to realize that maybe they didn't need the ability to tinker with the properties of every single layer. These providers had started fusing their vector layers together in a single rasterized image that was divided into 256 x 256 pixel images, or tiles. These tiles were pre-generated and stored on disk in the server for rapid distribution to clients. This was done out of necessity to support hundreds or thousands of simultaneous users, a burden too great for drawing the maps on the fly.

The figure below shows how a tiled map consists of a "pyramid" of images covering the extent of the map across various scales. Tiled maps typically come with a level, row, and column numbering scheme that can be shared across “caches” to make sure that tile boundaries match up if you are overlaying two tile sets.

Fig 5.2.1 Caption: Tiled web maps take the form of a pyramid where the map is drawn at a progressive series of scale levels, with the smallest (zoomed out) scales using fewer tiles. (Figure credit (and much of this readings text) goes to Sterling Quinn, of Penn State and their e-Education Institute from their “Why Tiled Maps” reading available at https://www.e-education.psu.edu/geog585/node/706).

When reviewing Figure 5.2.1 above, and references to “larger scale” and “smaller scale” maps, it is important to remember the terms large and small scale are as geographers define them. Recall that to a geographer, a “large scale” map means each tile represents a finer physical area on the ground, and “small scale” means the tile represents a broader region on the ground. You may understand that large and small scale using this terminology is based on the ratios in map scale. A “1-inch represents 200,000 inches on the map” scale (1:200,000) is a smaller scale map compared to a 1-inch equals 1,000 inches on the map (1:1,000) because its scale 1:200,000 is a smaller ratio than 1:1,000. So to geographers, small and large mean the opposite of what some non-geographers might interpret when they hear large and small scale maps.

Turning back to Figure 5.2.1, the tile at the top of the pyramid is a small scaled tile in that it covers the same physical area on the ground as the set of 16 tiles at the bottom of the pyramid. Because the tile at the top of the pyramid covers that entire area at the bottom of the pyramid (but with courser pixel resolution), it is a smaller-scaled tile in geographer’s definition of scale. Alternatively, each tile of the 16 tiles at the bottom of the pyramid, represent a finer area on the ground, so they are larger spatial scale tiles compared to the one at the top of the pyramid.

Cartographers loved the innovation of tiled maps, because now they could invest all the tools of their trade into making an aesthetically pleasing web map without worrying about performance. Once you had created the tiles, you just had a set of images sitting on disk, and the server could retrieve a beautiful image just as fast as it could retrieve an ugly one. And because the tiled map images could be distributed so quickly by a web server, Google and others were able to employ asynchronous JavaScript and XML (AJAX) programming techniques to retrieve the tiles with no page blink as people panned. (You may still remember seeing the tiling phenomenon if you have used Google Maps or Earth in the past, where as you zoom in to a finer area of the Earth you see coarser, sometimes rasterized images get replaced with finer, clearer images. This is the replacement of smaller scale tiles with larger ones as one zooms in to the larger scale from the top of the pyramid to the bottom in Figure 5.1.2.).

This was revolutionary. Which would you rather have: a slippy map [1] with stunning cartography and no layer control, or a clunky and ugly map with the ability to reorder layers and adjust the color of a school? Some longtime GIS geeks had to stop to think about this, but for the common web user, the choice was a no-brainer.

Within a year or two of Google Maps' release, commercial GIS software began offering the ability to build map tiles. For many, ArcGIS Server was desirable because the map could be authored using the mature map authoring tools in ArcMap; however, cost was a concern for some. Arc2Earth was another commercial alternative. The free and open source Mapnik library could also build tiles, but it wasn't until recent years that projects like TileMill wrapped a user-friendly GUI around Mapnik.

Fig 5.2.2 Caption: Tiles from OpenStreetMap data, rendered by MapQuest.

Tiled maps were the only model that could reasonably work for serving complex web maps to thousands of simultaneous users. However, they eliminated the ability for users to change layer order or symbols. People started working around this by serving out their general-purpose basemap layers as tiles and then overlaying a separate layer with thematic information. The general-purpose basemap tiles could be re-used in many applications. The thematic layers could also be tiled if the data didn't change too quickly or cover too broad of an area at large scales.

5.2.2. Making the Decision to Build and Maintain Tiles

If you want faster navigation of your basemap or you feel that more than a couple of users will be requesting maps simultaneously from your server, you should create a tile cache of your basemap. You may also choose to cache thematic layers if their features are not constantly changing attributes or position. In both cases, be aware that the tile cache represents a snapshot of your data at the time the cache was created. To put it more bluntly, your tiles are “dumb images” that will not automatically update themselves when the back end raster or vector data they represent change. You are responsible for periodically creating new tiles in order to update the map. With large caches, sometimes server administrators target the cache updates at just the changed areas rather than rebuilding tiles for the entire map. This requires keeping some kind of log about which places were edited, or comparing “before” and “after” versions of a dataset. Is there an existing tile cache that meets your needs?

Building a tiled basemap requires lots of rich data, high-end map authoring software, cartographic skills, and potentially enormous amounts of time and disk space. You may still need to do it, which is why we are discussing it. However, because of these challenges, general-purpose web mashups often use tiles made by somebody else. OpenStreetMap is an attractive option if you want free tiles with no restrictions. If you want to use Google's, Microsoft's, or Esri's tiles, you may be able to use them for free or you may have to pay, depending on the nature of your map (commercial or not for profit) and how many people use your app. Other companies such as CloudMade and MapBox have marketed their own versions of tiles using OpenStreetMap data.

If you are going to build your own basemap, it's helpful to have an experienced cartographer on staff who is experienced with designing at multiple scales. The symbols, colors, and details must be adjusted appropriately at each of the scales where tiles are created. Tiled basemaps can quickly get complicated with layer and labeling scale suppression rules. Cartographers may also need to design one set of tiles to stand on its own and another set of tiles to overlay satellite imagery, a task that requires very different colors and symbols.

Projection

If you are going to overlay your tiles with any of the tiles from OpenStreetMap, Google, Microsoft, or Esri (or even just attempt to look like them), you must convert your GIS data into a modified spherical Mercator projection that was created solely for the convenience of fitting the world onto a set of square tiles. Mercator has the property of representing angles more accurately for high latitude locations in the Earth when zoomed in to large (close to the ground) scales (recall Fig 5.2.1). Since web GIS maps like Google Maps were used most often by users for finding street-level locations or directions, this was the projection the Google Maps people decided to use [2]. GIS purists balked at this idea because the Mercator projection exaggerates areas farther away from the equator (see the discussion in [2]) and predicted it would fail to achieve mass uptake, but many people (at least at mid latitudes) now hold their nose and move forward with it. Be aware that Esri, Google, and other organizations have used other code numbers and variations of this projection in the past: things can get very confusing if you are using older software or APIs. In the past couple of years, people seem to have standardized on EPSG:3857 although even the subparameters of this projection can be interpreted in diverse ways that lead to offsets.

Even when you display your maps in EPSG:3857, you do not ever want to perform measurements in this projection. The results will be largely skewed even at mid latitudes. It's best to make sure that geometries are projected into a more local coordinate system before performing any measurements. The Esri blog post Measuring distances and areas when your map uses the Mercator projection provides a good overview of the problem and an example solution that uses the ArcGIS API for JavaScript, although the concepts can also be applied with FOSS APIs (to be discussed later).

Scales

Not only must you match the projection in order to overlay, you must also match the scales. These are not nice well-rounded numbers; rather, they were derived mathematically from the starting point of putting the whole world on a 2x2 grid of tiles. For example, one of the scales is 1:36,111.98 and as you zoom in, the next one is 1:18,055.99. So much for your simple USGS 1:24000 series! Partly for this reason (and partly because many laypeople don't understand map scales), the common web map scaleset is often referred to with simple numbers such as “Level 14,” “Level 15,” etc., that increase as you zoom in. You just have to get a feel for which levels correspond to national scale, provincial scale, city scale, neighborhood scale, etc. The table in the Bing Maps Tile System article is helpful for this.

To conclude, this reading was included to help you understand conceptually, the idea of tiling for web mapping, and some of the key issues that are involved. In a future exercise, we will be working with tiled images and Geoserver. But first, we will just turn to working with establishing data that are served by Geoserver, building on what you know already related to Postgres and PostGIS and WMS and WFS.

Footnotes

[1] Slippy map: “a term referring to modern web maps which let you zoom and pan around (the map slips around when you drag the mouse).” http://wiki.openstreetmap.org/wiki/Slippy_Map

[2] See the discussion on this Google forum, especially the response by Joel H. https://productforums.google.com/forum/#!topic/maps/A2ygEJ5eG-o