Compared to more fully-featured and complex GIS systems, the maths behind Bing Maps is relatively straightforward:

• Bing Maps are always projected using the same Spherical Mercator projection (EPSG: 3857).
• Bing Maps are always displayed at one of a fixed number of zoom levels. At zoom level 1, the entire world fits onto a 2 x 2 grid of 256px x 256px tiles. Then, at every subsequent zoom level, the resolution in both the vertical and horizontal dimensions doubles, up to a maximum of zoom level 19.
• Vector coordinate data is always measured using latitude and longitude coordinates from the WGS84 reference system (EPSG:4326).
• Raster data is always supplied as a set of 256px x 256px tiles, referenced according to the quadkey tile numbering system.

The advantage of operating within these fixed parameters is that it’s possible to create some rules of thumb that can be applied fairly consistently when developing any Bing map application. The following “Ready Reckoner” table(s) gives some figures I find useful when creating datasets for use on Bing maps. Since they use the same projection, these same figures can also be used as guides for Google Maps or Openlayers, say.

Firstly, some constants:

• The full extents of every Bing Map range from –180° to +180° longitude, and from –85.05112878° to +85.05112878° latitude. This makes the projected image appear perfectly square at any zoom level
• The straight line distance right across the middle of the map (i.e. the circumference of the Earth at the equator) is 40,075,018 metres.
• The width/height of the map at any zoom level, z,  can be calculated as 256 * (2z)

## Part 1: Map Scale and Resolution

The following table gives the total map dimensions, scale, and resolution at different zoom levels:

 Zoom Level Width/Height of map (pixels) Scale (m/pixel) Scale (° longitude/pixel) Scale (° latitude/pixel) Coordinate Resolution 1 512 78271.52 0.703125 0.332230972 0.1 2 1024 39135.76 0.3515625 0.166115486 0.1 3 2048 19567.88 0.17578125 0.083057743 0.01 4 4096 9783.94 0.087890625 0.041528871 0.01 5 8192 4891.97 0.043945313 0.020764436 0.01 6 16384 2445.98 0.021972656 0.010382218 0.01 7 32768 1222.99 0.010986328 0.005191109 0.001 8 65536 611.5 0.005493164 0.002595554 0.001 9 131072 305.75 0.002746582 0.001297777 0.001 10 262144 152.87 0.001373291 0.000648889 0.0001 11 524288 76.44 0.000686646 0.000324444 0.0001 12 1048576 38.22 0.000343323 0.000162222 0.0001 13 2097152 19.11 0.000171661 8.11111E-05 0.00001 14 4194304 9.55 8.58307E-05 4.05555E-05 0.00001 15 8388608 4.78 4.29153E-05 2.02778E-05 0.00001 16 16777216 2.39 2.14577E-05 1.01389E-05 0.00001 17 33554432 1.19 1.07288E-05 5.06944E-06 0.000001 18 67108864 0.6 5.36442E-06 2.53472E-06 0.000001 19 134217728 0.3 2.68221E-06 1.26736E-06 0.000001

### Notes

Scale: The various columns of scale are all measured at the equator – the scale on any projected Mercator map varies with latitude. Notice that, given the projected map image is square, yet the range of possible longitude values is roughly double that of the range of latitude values, the map is approximately 2x as precise in the latitude/y axis than it is in the longitude/x axis. Or, to put it another way, you have to move your mouse twice as far up the screen to cover one degree of latitude than you have to move it across the screen to cover one degree of longitude.

Coordinate resolution: The “coordinate resolution” column gives an indication of how many decimal places any coordinate value can be rounded to and still maintain the same visual acuity at a given zoom level. In other words, at zoom level 3, you may as well round any coordinate values to 2 decimal places – any coordinate stated with accuracy beyond that will likely be resolved to the same pixel location anyway.

## Part 2: Raster Tiling

When creating raster tilesets (using Safe FME, GDAL2Tiles, or similar), it’s handy to have an idea of roughly how many tiles are required to cover a given area, and how long it’s likely to take to render those tiles! In the tables that follow, I’ve given information on the tiles required to cover three different-sized areas at different zoom levels.

### Entire Map

The following table gives figures relating to a complete tileset covering the entire map:

 Zoom Level Number of tiles required Time To Render (at 1 tile/sec) Uncompressed Filesize (at 20kb/tile) Compressed Filesize(at 6kb/tile) 1 4 4 seconds 80 Kb 24 Kb 2 16 16 seconds 320 Kb 96 Kb 3 64 1 minute 1.25 Mb 384 Kb 4 256 4 minutes 5 Mb 1.5 Mb 5 1,024 20 minutes 20 Mb 6 Mb 6 4,096 1 hour 80 Mb 24 Mb 7 16,384 4 hours 320 Mb 96 Mb 8 65,536 20 hours 1.25 Gb 384 Mb 9 262,144 3 days 5 Gb 1.5 Gb 10 1,048,576 12 days 20 Gb 6 Gb 11 4,194,304 7 weeks 80 Gb 24 Gb 12 16,777,216 27 weeks 320 Gb 96 Gb 13 67,108,864 2 years 1.25 Tb 384 Gb 14 268,435,456 8 years 5 Tb 1.5 Tb 15 1,073,741,824 Give up. 20 Tb 6 Tb 16 4,294,967,296 No, really. 80 Tb 24 Tb 17 17,179,869,184 … 320 Tb 96 Tb 18 68,719,476,736 … 1.25 Pb 384 Tb 19 274,877,906,944 … 5 Pb 1.5 Pb

### 10km x 10km Square

Now, just to tile just an arbitrary 10km x 10km area:

 Zoom Level Number of Tiles Required Time To Render Uncompressed Filesize 1 1 1 second 20 Kb 2 1 1 second 20 Kb 3 1 1 second 20 Kb 4 1 1 second 20 Kb 5 1 1 second 20 Kb 6 1 1 second 20 Kb 7 1 1 second 20 Kb 8 1 1 second 20 Kb 9 1 1 second 20 Kb 10 1 1 second 20 Kb 11 2 1 second 41.6 kB 12 4 2 seconds 124 kb 13 16 8 seconds 320 kb 14 64 30 seconds 900 Kb 15 225 2 minutes 3 Mb 16 840 10 minutes * 9.23 Mb * 17 3000 40 minutes 35 Mb 18 12000 3 hours 100 Mb 19 48000 12 hours 500 Mb

### 100 km x 100km Square

And, to cover a 100km x 100km square (not the same as just multiplying the last table by 100! – see notes):

 Zoom Level Number of Tiles Time To Render Uncompressed Filesize 1 1 1 second 20 Kb 2 1 1 second 20 Kb 3 1 1 second 20 Kb 4 1 1 second 20 Kb 5 1 1 second 20 Kb 6 1 1 second 20 Kb 7 2 1 second 40 Kb 8 4 3 seconds 160 Kb 9 9 15 seconds 600 Kb 10 25 1 minute 2.2 Mb 11 90 2 minutes 7.8 Mb 12 324 5 minutes 25 Mb 13 1,190 20 minutes 78 Mb 14 4,624 1 hour 240 Mb 15 18,360 4.5 hours 700 Mb 16 72,900 15 hours * 1.9 Gb * 17 291,600 3 days 5.6 Gb 18 1,166,400 10 days 22 Gb 19 4,665,600 1.5 months 100 Gb

### Notes

Number of Tiles Required: A 10km x 10km area is sufficient to cover the extent of a small to medium-sized town/city. If you’re familiar with the National Grid of Great Britain, then 10km x 10km corresponds to an OS Grid Reference square of two letters and two numbers, e.g. TG20, shown below:

A 100km x 100km square is sufficient to cover an expansive metropolis and its surrounding area, or a British county or two, say (though is still much smaller than the average US or Australian state). A 100km x 100km square in the Great Britain OS Grid reference system is denoted by just a two letter code, e.g. TQ shown below:

The number of tiles required to tile the entire world in the table above is calculated from mathematical properties of the map. The number of tiles for 10km x 10km and 100km x 100km are based on real values that I’ve collected from tiling Ordnance Survey grid data, which, as shown in the images above, is not axis-aligned to the Bing Maps projection. This explains why the number of tiles required does not always scale consistently with each zoom level. The values with asterisks (zoom level 16) in the tables are the actual figures I got just this morning from rendering OS VectorMap tiles for the exact two areas shown above – TG20 and TQ – on a single core of my laptop.

Time To Render: This figure varies wildly depending on your particular system configuration, whether your source data is an existing raster file or whether it’s being generated dynamically (e.g. from a database query), and many other factors. The column here gives timings at a rate of 1 tile per second simply as a convenient figure from which to perform further approximate calculations. If your system renders 6 tiles per second, you can divide these times by 6 😉

Note also that the time to render a set of tiles at zoom levels 14 – 16, say, is not necessarily the sum of the times taken to render at each of those zoom levels independently. Many tile rendering engines will render the tiles at the deepest zoom in full, and then aggregate those tiles together in groups of 4 to render the subsequent higher layers more quickly than rendering them directly from source.

Filesize: I find that, by default, the PNG images output by applications such as Safe FME and GDAL are not compressed, and a 256 x 256px tile may, on average be around 20kB in size, which is the baseline used in the “uncompressed” column. Running these tiles through one or more PNG compressions programs can reduce these filesizes (without losing quality) to around 6kB each, which is the baseline used in the “compressed” column. Also, the total filesize of a tileset varies a lot with the density distribution of your data – at close zoom levels, sparse datasets will have a lot of empty tiles, meaning that filesize does not increase linearly with number of tiles generated.

This entry was posted in Bing Maps, Spatial and tagged , . Bookmark the permalink.