Talk:Tiles@home/Dev/Coastline

generalizing duplicate tiles problem

Why limit finding duplicates explicitly to blank land and sea tiles? Keep a record for ALL possible tiles in a DB with x,y,z,md5 (and other fields as needed). Proposed tiles_blank table would be 70% of the world anyway, so why not have the full 100% and simplify and generalize things?

Clients then calculate the hash (eg MD5) of each tile and send that one with each tile (or even before sending the tile itself to save bandwidth). That would cover also duplicate forest tiles (large forest areas) and all other similar (rare?) cases. That way there is also no need to merge tiles.

Saving tiles as (Md5).png and creating symlinks to them based on the mappings in the above mentioned DB table. Not sure what this means in resource usage terms (inodes, disk space...). It should be fairly easy to effectively distribute tiles on several partitions if needed (Tiles@home/Dev/Website/Disk) based on a beginning of a filename (symlinking /tiles/a -> /dev/hdd4/, then saving abcd456.png to /tiles/a/abcd456.png)

Same table could be used for status keeping ("needs re-rendering", pending, in process, done), render queuing, ...

-- Stefanb 12:48, 11 May 2007 (BST)