2008/12/22 OJ W <[email protected]>: > On Mon, Dec 22, 2008 at 1:43 PM, Bill Magee <[email protected]> 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 ti...@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...@h and mod_tile schemes are each optimised for the typical update pattern each process uses -- in t...@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. Dave _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
