Disk space and numbers of tiles for world layer

Question

I'm thinking about testing tiles generation of a world layer for webmapping.

In this context, I want to know how I can calculate the number of tiles (256x256 for tilecache if I remember) I will need for n levels in WGS84 coordinates.

Maybe I will use a composite solution with pregenerated tiles and on the fly generation but I have to know at the end the available disk space if every tiles are generated and the number of files it will represent.

There are two goals, time it will take and disk space needed.

Any informations are welcome

Edit:

I've found this script to calculate the number of tiles to generate depending on zoom levels and your data extent. See this gist https://gist.github.com/1675606

Answer 1

Here is excel sheet in Google Docs from GeoSolutions team (http://geo-solutions.blogspot.com/2010/12/estimating-time-and-space-required-to.html)

https://spreadsheets4.google.com/ccc?key=tyCIm7rz8753DUGC9FyOXaw#gid=0

Answer 2

I made a cheat-sheet that lists the total number of tiles for given zoom-levels.

It has two tables. One showing the number of zoom-levels needed to show things at a certain scale, starting from a tile showing people.

level 1: 1 # Person
level 2: 5 # Car
level 3: 21 # House building
level 4: 85 # Square
level 5: 341 # Small neighbourhood
level 6: 1,365 # Football stadium
level 7: 5,461 # Small farm
level 8: 21,845 # Central park New York
level 9: 87,381 # Entire airport
level 10: 349,525 # Small city (Copenhagen)
level 11: 1,398,101 # Medium city (Amsterdam)
level 12: 5,592,405 # Large city (London)
level 13: 22,369,621 # Medium Island (Mallorca)
level 14: 89,478,485 # Large Island (Sicily)
level 15: 357,913,941 # Small country (Denmark, Estonia, Taiwan)
level 16: 1,431,655,765 # Medium Country (Korea, Greece)
level 17: 5,726,623,061 # Region (Southern Europe, Arabian Peninsula)
level 18: 22,906,492,245 # Small continent or large country (China)
level 19: 91,625,968,981 # Medium continent (Africa) or huge country (Russia) 
level 20: 366,503,875,925 # Asia
level 21: 1,466,015,503,701 # The World

The other one show the number of zoom levels needed if starting with a world map, and progressive detail levels:

level 1: 1 # The World
level 2: 5 # Large contenents
level 3: 21 # Medium continents, huge countries
level 4: 85 # Small continents, large countries
level 5: 341 # Region (Southern Europe, Arabian Peninsula)
level 6: 1,365 # Medium Country (Korea, Greece)
level 7: 5,461 # Small country (Denmark, Estonia, Taiwan)
level 8: 21,845 # Large Island (Sicily)
level 9: 87,381 # Medium Island (Mallorca)
level 10: 349,525 # Large city (London)
level 11: 1,398,101 # Medium city (Amsterdam)
level 12: 5,592,405 # Small city (Copenhagen)
level 13: 22,369,621 # Entire airport
level 14: 89,478,485 # Central park New York
level 15: 357,913,941 # Small farm
level 16: 1,431,655,765 # Football stadium
level 17: 5,726,623,061 # Small neighbourhood
level 18: 22,906,492,245 # Square
level 19: 91,625,968,981 # House building 
level 20: 366,503,875,925 # Car
level 21: 1,466,015,503,701 # Person

Answer 3

This is very old question, but there are (at least) two important caveats, depending on the task at hand.

1. The task may result in rendering a (very) large number of empty tiles without specific management of the tile creation process.
2. The size on disk of a tile pyramid may be much (more than 100%) larger than expected from the sum of its component file sizes, due to the 4KB minimum cluster size (aka block size) on most storage.

(2) is pretty much already explained, but as an example I have a tile pyramid where the total file size is 168MB, but its size on disk is over 600MB. It makes it far more important to get (1) right.

As to (1): consider if your 'world file' job involves only country boundaries.

Any tile that is not a boundary can be served with one of two 'alt' tiles - a 'sea' tile (blue) for anywhere not inside a country, or a 'block' (fill) tile for tiles that are entirely within a national border. Only tiles that include a segment of border need to be rendered - the rest can be 'defaulted' away.

Why is this? Because all block tiles of a specific type (type in (sea,land), or type in (sea,country a, country b, etc)) will be identical.

The 'block' tile could be one colour for each country, or one colour for the whole world, or a blank tile (if you're overlaying the country outlines on a background).

'Block' tiles only need to be rendered once (e.g., 1 256x256 tile, entirely filled with the desired colour).

When the tiles are being created, you can test

(a) if its 'parent' - the tile at one less zoom level - exists; and

(b) if it is a 'block' tile (i.e., it is entirely filled with one colour).

In case (a) the tile does not need to be rendered; if the parent does not exist it's because the parent was entirely a block tile and was deleted.

In case (b) (where the parent exists so the tile needs to be tested), if it's a block tile then it can safely be deleted from the tile pyramid. (The test for block-tile-ness is simply based on file size. A 256x256 tile entirely of one colour is a very precise size, and the probability that a 'proper content' tile is the same size is zero).

Deleting these tiles during the creation process adds minimal time to the tile-rendering loop, but saves huge amounts of disk space. The alternative is to render everything and then recursively search the pyramid for block tiles and delete them: this takes longer.

Once the pyramid is built, the tile call procedure can default to the 'block' tile if it goes looking for tiles/z/x/y and gets a 404.

To see why this is the case, consider rendering a 256x256 zoom=1 where the top quadrant is entirely empty. You know with certainty that the 4 tiles at zoom=2 that cover the same area will also be empty. Likewise, the 16 tiles at zoom=3 and so forth.

So any time during the tiling process where the tile is a block colour (or is empty), all times at higher levels of zoom can be ignored.

This saves vast amounts of storage, and lots of time in the tiling process.

A caveat to these caveats: a more complex tiling job will switch on different layers at different zoom levels. If this is the case, great care has to be taken to ensure that the 'parent' test is not performed when the zoom level is one where a new layer is included in the render set.