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.
