[OSM-dev] Complete tileset - experiments with tile sizes and disk space

Dave Stubbs osm.list at randomjunk.co.uk
Tue Dec 23 17:25:36 GMT 2008

2008/12/22 OJ W <ojwlists at googlemail.com>:
> On Mon, Dec 22, 2008 at 1:43 PM, Bill Magee <bill at billmagee.co.uk> wrote:
>> I don't do *nix but on WinXP the typical allocation size for large disks
>> is 4kb (and I assume other file systems will do similar). Any tile under
>> 4kb (lots of them) will occupy this 4kb regardless.
> Back when tiles at home stored its images in one file each, I think the
> sysadmins chose a block size of 512 bytes for exactly that reason.
> That would have been on Linux with ReiserFS though, so probably
> doesn't help for your app.
> The replacement scheme was
> http://wiki.openstreetmap.org/wiki/Tiles%40home/Tileset_as_one_file
> which puts 1366 tiles in each file (along with compression for various
> types of blank tiles) - apparently it doesn't take long to extract the
> PNG data for any given tile from such files.

mod_tile as used by the cyclemap and the main mapnik layer has a
similar scheme where it renders and saves tiles as meta blocks of 8x8
tiles. This drastically reduces block count as files contain 64 tiles
each. The meta file is just an offset table followed by each tile's
png. There's a fun directory structure too to improve directory lookup
on filesystems that don't keep their directory contents indexed.

The mod_tile apache module then retrieves the tile you're requesting
from the associated meta file without having to unpack it.

The t at h and mod_tile schemes are each optimised for the typical update
pattern each process uses -- in t at h each z12 tileset gets updated at
once so it makes sense to have the one file, where as for mod_tile the
process renders 8x8 sections on-demand so it makes sense to keep those
as one file.

For a fairly static and comprehensive tile set you might find some
other packing method more efficient.


More information about the dev mailing list