Tiles@home/The blank tile problem
'Blank tiles' is a way to not have to store real tiles for areas that are either all 'ocean' or all 'land'.
We don't want to store these tiles, but we still want to know if these are blank tiles, and if so, whether they are land or sea (or some other feature/landuse, like forests or parks). We can either store this on disk or in a database. Database approach is probably more efficient, but even this should be optimized. Current approach is for t@h to maintain a database to keep track of them.
The database stores a row in the TILES_BLANK table stating 'this tile is blank (sea|land)'. At request time, if no tiles exist on disk, the tile is looked up in the database, and if the tile in the database is there, an appropriately colored blank image is returned instead.
- Example Blank Sea tile - tile information for 0,0 at level 7
- Example Blank Land tile - tile information for 48,7 at level 7
1: Detecting blank uploads
- Clients upload tiles which may or may not be blank
- Server doesn't have space to store blank tiles
- Server deletes tiles < 1000 bytes, on the assumption they're empty
- issues 1 and 2 are fixed by the "Cambridge" client--Deelkar (talk) 22:35, 9 March 2007 (UTC)
- issue 3 has also long since been fixed, not sure when --Deelkar (talk) 09:31, 9 April 2009 (UTC)
2: Deleting tiles
It's currently very difficult for a client to delete a tile (from the server) that it knows is empty, if the server already has a tile for it. It can't upload a blank tile (since the server will discard it, and it may/should be configured not to upload blank tiles)
Could do something like adding blank delete_z_x_y.txt files to the upload ZIP
3: Detecting plain-color tiles
We can't even assume that a small filesize indicates constant-colour images.