[Tilesathome] t at h client tilesetfile creation

[spaetz]

On Tue, Oct 14, 2008 at 01:05:05PM -0400, Matthias Julius wrote:
> > I tested the creation of tilesetfiles by the client. They look good. I
> > have implemented tileset file handling now.

(what is still missing is marking requests as finished as user stats. No clue yet, how a tileset should affect the "Uploaded number of tiles".

> > 3) we save the tilesets and have a cron job that examines all existing
> > tileset files and deletes empty ones regularly. Not that difficult but
> > probably wasteful?
> 
> 3a) only check tileset files that have been uploaded since the last
> check.

That's feasable and might be the short term fix until we implement something better.
 
> 4) the client can upload a special "empty" file.
> 4a) this file only contains 1 byte (1=sea, 2=land, 3=transparent)
> 4b) this file is a special tileset file that instead of containing 4
> bytes for each empty tile only contains the information that all tiles
> are empty and whether it is land, sea or transparent.

Right, that's the alternative option I was considering. It would actually only mark "blankness". The type of blankness is determined by oceantiles.dat then.
 
> Do we want to keep meta data for empty tilesets?

I am not very keen on it, we can always have an upload log that we delete after a week if we want to keep track of vandalism.
 
> Having a special "empty" file could eliminate the need for database
> lookups while tile serving alltogether.  The drawback of this is that
> it will be a lot of inodes.  Don't know if that is a problem.

I rather have one 4MB db file (that is kept open and is mmapped into RAM across tile servings) than 16 million 4 byte files that need opening and closing all the time.

> What filesystem does the server use for the tile store?  Does it store
> small files directly in the inode instead of wasting a whole block for
> a 1 byte file?

it's a JFS file system. no clue how it deals with millions of 4 byte files.

spaetz