Tiles@home/Dev/Coastline

Pages:

• Tiles@home/Dev/Interim Coastline Support
• Tiles@home/Dev/Coastline/Idea1

rest of page is development 5 may 2007

policy

part 1: uploads - complete

• 67 byte uploads cause a "blank land" entry to be inserted in blank tile database. the image itself is not used
• 69 byte uploads cause a "blank sea" entry to be inserted in blank tile database. the image itself is not used
• all other < 100 byte uploads are invalid and get dropped

SVN view of the changes made server-side

• Proposal: use zero-byte uploads to indicate the blank tile database entry should be deleted (as well as the tile itself, ofcourse). Kleptog 12:18, 8 June 2007 (BST)

Proposal for version name change due to #1

Prevent old clients uploading, because they'll be sending 571-byte sea images which won't be detected, and which will use precious server space

accepted. new client name is "Headingley"

Proposal to immediately disable old versions. Since the requests queue has been disabled for 2 days and the API is currently down, this shouldn't interrupt anyone's uploads

accepted. old versions blocked from uploading

part 2: serving seas

todo: 404 handler that looks in the new database

hierachical system - if can't find tile, checks for next layer up

part 3: delete tiles

if any tiles exist in the blank db, then delete the equivalent map tile

todo: think about how this works with different layers

part 4: merging blank tiles

type 1: 4 identical sea/land tiles next to each other get merged to a single tile at a lower zoom level

type 2: a land/sea tile completely within another land/sea tile of the same type at a lower zoom level simply gets deleted

Note that this can also be applied at higher zoom levels. If a client is rendering a large lake it can merge the tiles before uploading. In this case the lowest zoom should simply be deleted.

part 5: import known sea tiles at z12

can someone write a script to upload the best known version of oceantiles.dat through the regular upload interface (i.e. lots of copies of blankland.png and blanksea.png in a ZIP file with filenames saying their x,y,z,layer)

in fact, just put the tiles in an upload directory and run the upload script, that will handle the ZIPping and upload stuff...

• I've done this for all land tiles and many sea tiles. However, sea tiles are less important as people arn't going to be looking there as often. There is a fallback mechism for blank tiles, so perhaps we should only actually store blank tiles in large blank areas at level 6, 9, 12, 15 to save on useless entries. Kleptog 12:15, 8 June 2007 (BST)

database

CREATE TABLE `tiles_blank` (
  `x` int(11) NOT NULL,
  `y` int(11) NOT NULL,
  `z` smallint(6) NOT NULL,
  `layer` tinyint(4) NOT NULL default '1',
  `user` int(11) NOT NULL default '-1' COMMENT 'who deleted the tile (user ID)',
  `date` datetime NOT NULL COMMENT 'when was tile deleted',
  `done` tinyint(4) NOT NULL COMMENT '0 if tile still needs to be deleted',
  `type` tinyint(4) NOT NULL COMMENT '1=sea',
  PRIMARY KEY  (`x`,`y`,`z`,`layer`),
  KEY `done` (`done`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci COMMENT='Blank land tiles, sea tiles, deleted tiles';

Types

• 1 = sea (light blue)
• 2 = blank land (white)