4.2
Tiled Maps
The basic premise behind a tiled map is that it starts with a single square image, then divides this into four, and continues dividing recursively using a quad tree segmentation algorithm, so that each successive zoom level contains four times as many images, or tiles, as the previous. The map scale is therefore decreasing with each successive zoom level, so more detail can be seen as the user zooms in.
Figure 4.18: Tiled map squares with the top left square recursively divided. The numbers show the level of zoom.
Figure 4.18 shows the recursive subdivision of the top left tile. Further information about tiling and how it was used to create static tile sets for London Census data can be found in [Gib+08] which details the development of the ‘London Profiler’ website. For a more general view of web mapping, [Bat+10a], covers map ‘mash-ups’, where data from different sources is overlayed on a map, along with other aspects of web mapping past and future.
Tiled maps used for web mapping which conform to the original Google tile speci- fication, or the retro-fitted OpenGIS “Web Map Tile Service” described in section 3.6, quadruple in number at each successive zoom level. An estimate of the number of tiles required to store the whole world can be made by summing the total number of tiles over all zoom levels and applying a linear correction factor to take into account the letterbox effect of the -90 to +90 latitude and -180 to +180 longitude rectangle. At the top level, the whole world is represented by one tile, which is split using a quad tree algorithm. At the next level this splits into four tiles, followed by each of them splitting
into four to make sixteen. This is repeated for every subsequent level of zoom, yielding a formula for the total number of tiles as follows:
N = 40+ 41+ 42+ . . . + 4n where n is the final zoom level (4.3)
N =
n
X
z=0
4z (4.4)
Although equation 4.4 can be calculated for each zoom level individually, it can be reduced further by recognising that it is a simple geometric progression of the form:
N = n X k=0 ark= ar0+ ar1+ ar2+ . . . + arn (4.5) N = n X k=0 ark = a(1 − r n+1) 1 − r (4.6) N = a(1 − r n+1) 1 − r (4.7)
In this case, a = 1 and r = 4 to give the quad tree progression. Taking n = 17 as the maximum zoom level and using equation 4.7, gives an initial estimate of:
N = 22, 906, 492, 245 tiles (4.8)
This needs to be divided by 2 because only the tiles within the (-180,-90), (180,90) envelope are stored. Then a correction factor needs to be applied to account for miss- ing tiles in remote locations, for example the middle of the ocean, which are also not stored. As this is an estimate, a linear scaling factor can be applied to all zoom levels uniformly, so the requirement is to calculate the percentage of the Earth that is wa- ter. Although more complex methods exist to calculate the area of complex polygons, for example the strip method introduced in [SP98], as this is an estimate, reproject- ing the data using an area preserving projection and simply calculating the water to land ratio is sufficient. World vector maps exist which are free to download, for exam- ple, ‘TM WORLD BORDERS-0.3’ from Bjørn Sandvik’s website, ‘thematicmapping. org’. This particular shapefile happens to contain the United Nations Food and Agri- culture Organisation’s data on country areas in thousands of hectares, so it is a simple
4.2. Tiled Maps 131 matter to add up all the areas in the attribute table and obtain a total in KM2.
The formulas to obtain the surface area of an oblate spheroid are widely published and a quick search of Wolfram Mathworld [Wei14] yields the following:
e = r 1 − b 2 a2 (4.9) S = 2πa2 + πb 2 e ln 1 + e 1 − e (4.10) Using the WGS84 coefficients:
a = 6378.137KM (semi − major)
f = 1/298.257223563 (f lattening)
b = a(1 − f ) = 6356.752KM (semi − minor)
Soblate = 510050577.7KM2 (f rom equation 4.10)
Dividing the land area from the shapefile by Soblateresults in the following estimate:
Land = 129632390
510050577.7× 100% = 25.4% (4.11)
Working on the basis that 25.4% of the world is land7, the result in equation 4.8 can
be modified as follows:
N = 1
2 ×
25.4
100 × 22, 906, 492, 245 = 2, 909, 124, 515 (4.12)
As the original question related to storage of all the tiles comprising the world, the next problem is to estimate the size of a tile on disk. Web mapping systems have almost exclusively used 256 pixel square tiles as a trade-off between size and detail, so an upper bound for the size of a tile can be estimated as follows:
256px × 256px × 32 bits per pixel = 256KB (4.13)
This figure assumes a worst case scenario and no compression, while by averaging all the tiles actually stored by a web mapping system, an average of 2KB has been observed in practice.
7The National Oceanic and Atmospheric Administration (NOAA) states that the percentage of Earth’s surface covered by water
is 71%, so the estimate of 25.5% is too low, but it is important to show how to estimate the area on the WGS84 spheroid. The reason the estimate is low is because not all the land masses are accounted for in the data. See: http:// www.noaa.gov/ ocean.html.
N × 4KB per tile = 11, 636, 498, 060KB = 11, 097GB (4.14) This is significantly bigger than a 33GB Open Street Map ‘world file’ which stores all the data for the planet, and is worth rendering only on demand, especially when it is realised that this estimate is only for a single map. While there might be a limited number of cartographic representations in use, when more general representation of data on maps is considered, the number of tiles multiplies. Taking the 2011 Census as an example, there are 2,558 variables which can be mapped (from the NOMIS r2.2 release), while for the 2001 Census, a related project called the “London Profiler”8
mapped population and deprivation statistics on Google Maps using pre-created static tiles [Gib+08]. This comprised a subset of individual Census variables, mapped down to zoom level 18 for the limited London area. These scales of magnitude are important to bear in mind when attempting to make maps from all the data contained in entire data stores. In general, with pre-created tiles, it is necessary to limit either the zoom level, or geographic area.
Despite the fact that the Mercator projection has singularities at the poles, which require the map to be truncated above and below certain latitudes, it is still used almost exclusively in zoom-able web-based mapping systems. While the projection allows for a non-uniform aspect ratio, web maps define the aspect ratio to be unity, which, along with the spherical Earth used as the datum, results in the truncation of the maps according to the following formula. The symbol, φ, represents latitude, while R is the Earth’s radius and y is the Mercator North ordinate.
AspectRatio = 1 ⇒ y = ±width 2 y R = π φ = tan−1sinh y R = tan−1(sinh π) = 85.05113◦
While a map truncated at ±85 degrees latitude is fine for most applications, where many environmental maps are concerned, not being able to represent data near the poles 8London Profiler website: http:// www.londonprofiler.org. Unfortunately, this is no longer online, so only exists in [Gib+08].
4.2. Tiled Maps 133 is unacceptable. The key issues with this type of system are to be able to reproject the data into the Mercator projection, then each tile request results in a box test to select the data to be drawn on the tile. This involves calculation of the tile box from the tile coordinates passed in the web request, a spatial index to optimise selection of the data, followed by rendering to the tile. The rendering of the data can be performed by a geospatial library like geotools (Java), SharpMap (C#) or Mapnik (C++), with the lower level geometry handled by a library like the Java Topology Suite (Java), NetTopologySuite (C#) or GEOS (C++). The GEOS library was used by me as part of the 3D pipeline to take a map asset from MapTube and place it in the “Second Life” online system using Autodesk’s FBX format as published in [Hud+09a], [Bat+09] and [Bat+10a]. Any system able to handle 2 dimensional path geometries with holes and rasterise them is a suitable candidate, including GPU implementations.
The WMTS standard from the OGC is a response to the proprietary web mapping standards that have emerged as tiled maps have gained popularity. By developing this new standard, the OGC addresses the original WMS standard’s inability to scale to large numbers of users. Quoting from the OGC WMTS specification document:
“The OGC 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 (com- bined with the OGC Style Layer Descriptor (SLD) standard). WMTS trades the flexibility of custom map rendering for the scalability possible by serving static data (base maps) where the bounding box and scales have been con- strained 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.”
(From document 07-057r7 Web Map Tile Service Standard [Ope10a]) Part of this statement from the OGC’s standard could be seen as contentious though, as there is no issue with serving dynamic data using WMTS. The ability to cache map requests and the ability to handle dynamic data are two separate issues. Taking Google’s Fusion Tables system as an example, this certainly does work with dynamic
data, while real-time mapping systems like CASA’s ‘SurveyMapper’9 can build dy-
namic maps on the fly using volunteered geographic information.
Following the Google release, both Microsoft and Yahoo! followed with their own mapping systems and MetaCarta began work on an open source alternative to the com- mercial Javascript map libraries. Their ‘OpenLayers’ project performs the same func- tion as the Google Maps API, relying on an available source of map tiles in one of a number of popular formats. This highlights one of the problems with the development of tiled map systems. Where no officially recognised standards existed, third party ven- dors made up their own. Google initially used Keyhole strings made up of the letters ‘t’ (NW), ‘q’ (NE), ‘r’ (SE) and ‘s’ (SW) to define tiles, but quickly standardised on numbering in the X and Y directions with an additional zoom parameter, as ‘Z X Y’. While they chose to number with the origin in the top left, other mapping systems used a bottom left origin, or specified tiles as strips in directories as ‘Z/Y/X’ which was favoured by OpenStreetMap.
One of the enabling technologies involved in the propagation of maps on the web is the existence of data. Google’s initial business insight was to licence the data from mapping agencies all around the world to build a connected map which was then freely available to view. Both Google and Microsoft now spend billions of dollars on their mapping services, which they finance partly though advertising and premium services. With the OpenStreetMap community actively mapping the whole world, open vec- tor data to make maps is now freely available. The missing link is currently the satellite data, street view images and 3D maps which do not exist in any open form yet. While looking at 3D representations of maps, for example Google Earth or NASA’s World- Wind, rendering on the user’s computer requires the raw data, which requires licensing of the data in an appropriate form. For this type of system where the raw data is effec- tively being given away, only an open licence makes sense. This is also the case with some forms of tiled maps where vectors are used to draw the cartography instead of im- age tiles. The new release of Google Maps in May 2013 introduced WebGL support for rendering maps on the browser. This marks a shift away from tiled maps and towards vector based cartographic content which can be manipulated in a more interactive way by the user. Cartagen10is an open source project that pre-dates Google’s use of vector mapping to provide a similar set of features. In this case, OpenStreetMap data is used to draw maps on the browser, again using WebGL for graphics acceleration.
4.2. Tiled Maps 135 Other tiled map systems worth mentioning are ‘Mapnik’, which is another open source project often used for rendering OpenStreetMap data or making choropleth maps. ‘TileMill’ is an open source map design studio which runs on the desktop and uses Mapnik to render its maps. Its purpose is to make it simple for inexperienced users to create maps. The ‘MapBox’ suite of software tools, including the ‘MapBox GL JS’ javascript library for WebGL maps, is designed around an online maps designer and includes image maps in addition to the vector tile maps used with “MapBox GL JS” library. ‘Leaflet’ is also worth mentioning here, which is designed to be a lightweight javascript library for web-based maps. All of the projects mentioned here perform functions, which, when used together in the correct way, build into a fully-functioning web-based mapping system.
The one feature that almost all web mapping systems have in common is that they expect the data to remain static. With cartographic data, this is generally the case as changes to roads and rivers are relatively infrequent and cache misses are rare, but for applications where the data backing the maps changes routinely, cache misses are high and the requests pass from the edge to the application servers. This causes a problem with the visualisation of volunteered geographic information, or any other real-time system, because the data is constantly changing. This defeats most buffering and caching systems and results in the load being passed on to the application servers as the map tiles need to be constantly re-rendered. One answer to this is to do the map rendering on the client, so, for complex fast changing data, tiled maps may not be the answer. Finally, the one remaining question regarding web mapping is whether a full function web GIS is possible? Google mail, documents, spreadsheets, presentations, calendars and even SolidWorks CAD (OnShape) are now possible through WebGL.