Talk:Tiles@home/Tileset as one file

From OpenStreetMap Wiki
Jump to navigation Jump to search

Is anyone actively working on this at the moment? I have written some simple perl scripts that take the output from the tah client temp directory and writes it into a single file according to file format described on this page. With this, hopefully it should be quite easy to change over the client side, once the server part is written. I need to clean them up a bit though before I can post them. I have considered having an attempt at the server side as well, but given I don't know any of the tools, I am not sure I have enough time to do this. So I wanted to make sure I am not duplicating any effort. --Amm

AFAIK nobody is actively working on this.You may want to ask at tilesathome@openstreetmap.org mailing list to be sure. --Jttt 01:07, 30 June 2008 (UTC)


Henry suggested following file format (see [1]): 

Byte 0: 'O'
Byte 1: 'S'
Byte 2: 'M'
Byte 3: ' '
Byte 4: 'T' <- Tileset
Byte 5: 'D' <- Layer (D=default, M=maplint)
Byte 6: '1' <- format version number
Byte 7: ^D
Byte 8-11: x-coord of z12 tile
Byte 12-15: y-coord of z12 tile
Byte 16-19: position of xml meta data block
Byte 20-23: length of xml meta data block
Byte 24-27: position of z12 tile
Byte 28-31: length of z12 tile
Byte 32-35: position of firt z13 tile
Byte 36-39: length of first z13 tile
Byte 40-43: position of second z13 tile

Simple and easy. The first 16 bytes contain the data the reading software (webserver) expects to be there, so it can be compared 1:1 (that is: in one 64-bit comparison). The first position+length pair (all values as 32 bit integers paired up to 64 bits, easy to process for modern processors) contains the address of an XML meta data block (format to be defined). No extra data on the single tiles, so the sea/land tiles have to be included once in the file (thats 67+65 bytes extra), and each empty tile will just point to the same data. (Note: Empty tile data would need 341.25 bytes extra, so including the empty tiles (132 bytes) not just saves cpu cycles but also space.)

I (Jttt) would suggest some modifications: 

Byte 0: 'O'
Byte 1: 'S'
Byte 2: 'M'
Byte 3: 1 <- format version number
Byte 4: 'T' <- Tileset
Byte 5: 'D' <- Layer (D=default, M=maplint)
Byte 6: minimum zoom (12 by default)
Byte 7: maximum zoom (17 for default tiles, 16 for maplint)
Byte 8-11: x-coord of z12 tile
Byte 12-15: y-coord of z12 tile
Byte 16-19: position of xml meta data block
Byte 20-24: length of xml metadata block
Byte 24-27: position of z12 tile
Byte 28-31: position of first z13 tile
Byte 32-35: position of second z13 tile

Length of tile can derived from position of following tile.

Tile position can be negative which means it's special kind of tile. Possible values:

  • -1: blank land
  • -2: sea
  • -x: other solid color tiles or even pattern ??
  • -2^31 - position : mark a contained tile as invalid and fall back to a tile outside the tileset (need the position to derive the correct length)??


Incomplete tilesets

Clients can upload incomplete tilesets. For example when it's not possible to upload big files due to ISP restrictions. Posible ways to handle incomplete tileset:

  • Keep incomplete tilesets in special directory, check it everytime tile is requested
  • Merge current tileset with uploaded incomplete tileset. Incomplete tilesets can be uploaded as zip or in special incomplete tileset fileformat. Using special file format should be faster than zip but it will require extra work. Incomplete tileset format will be very similar to fileformat specified above, with these exeptions:
    • format version number is 2
    • Tile position can contain value NO_TILE which means tile is not included in file and tile from older should be used.
  • Use the current upload process for incomplete tilesets and use the fallback "transition" pathway in serving these single tiles
    • Needs to possibility to invalidate individual tiles in the older complete tileset file.
    • Run a periodic cleanup demon to merge the single tiles back into the tileset file.

Transition strategy

It's not possible to delete all existing tiles and start from the beggining so one tile per file and one tileset per file will have to coexist or one tile per file tiles will have to be converted to one tileset per file system.

I would suggest to let existing tiles to coexist with new format. Tile will be searched in this order:

  • look for tile in big file
  • look for tile in small file
  • look in blank tiles database
  • return "unknown tile"
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Talk:Tiles@home/Tileset_as_one_file&oldid=131866"