[OSM-dev] tiles at home disk usage

[Martijn van Oosterhout]

On 5/2/07, Jeroen Dekkers <jeroen at vrijschrift.org> wrote:
> I think we should just put this in a separate table in the
> database. If we can keep this table small enough to fit in memory then
> it should be fast enough, probably faster than storing things in the
> filesystem.

Something tells me that "zoom-17" with (2^34 tiles total) and "fit in
memory" are somewhat incompatable goals :)

I also think we should avoid the DB and just keep a flatfile on disk.
There's no way a database going to compete against an open/read 8
bytes/close.

> I think we don't need to store information of zoom17 sea tiles in the
> middle of the oceans, so we should probably only store information up
> to level 12 and only store higher zoom sea tiles near land.

But if someone zooms in to level-17 in the middle of the ocean, they
should still see blue. You're surely not proposing that the DB check
level-17, then 16, then 15 all the way to level 12 until it gets a
hit?

> I'm not sure what exactly to store in the db. It should be that
> information that has the smallest total size, so we can try to keep
> the table in memory.

The existing info for coasttile data extended to level-17 is about as
optimal as you can get: 2 bits per tile requiring only 4GB for all of
level-17.

> We could also just put two simple text files called emptytiles.txt and
> bluetiles.txt in the zip file. On each line there would be an x,y tile
> number that is an empty or blue tile. I don't really see a need for
> XML... :-)

Absolutly! Take the guess work out of the empty tile match. We
obviously have CPU time to spare on the t at h clients, get them to check
whether the tile is actually empty and add the coords to the file and
on the server process them into the flat files.

Have a nice day,
-- 
Martijn van Oosterhout <kleptog at gmail.com> http://svana.org/kleptog/