[OSM-dev] Tiles at home empty tile detection

Dirk-Lüder Kreie osm-list at deelkar.net
Fri Mar 9 03:43:18 GMT 2007

Hash: SHA1


There seems a lot of rumors and misconceptions around how the empty tile
detection in tiles at home works.
Some clarification about the why and how of ETD:
- - The server will be running out of harddrive space soon if there's
  nothing done to prevent empty tiles cluttering the space.
- - The previous (crude) approach was to simply delete tiles smaller than
  a certain size, based on the assumption that the less complex the
  tile the smaller the png size, which is quite accurate, but...

The Problem arose when comparing the outputs of different png
implementations, some manage to squeeze 2 roads and a bridge in 654
Bytes, others render a completely empty tile at 759 Bytes. So it became
obvious that filesize is not accurate enough to see wether a tile is
empty or not. This becomes even more clear when you consider large
areas (forest), that produce uni-colored tiles, that will (by file size)
look exactly like an empty tile.
To not further load the server, it was decided to put the detection into
the renderer. This is currently implemented as a check of the image area
vs. a known empty tile. libGD has a nice function that can reliably
compare images of different modes (e.g. truecolor vs. paletted) and
decide that they show the same if they would look the same to you and
me, e.g. a plain tile of color #f8f8f8 compares true against any
reference image of 256x256 px and the same colour, regardless of encoding.
If it finds the tile just rendered and cut out to look the same as the
reference image, the tile is *not* written to disk, instead a
placeholder png is placed in it's stead. This can easily be identified
by it's filesize, because no tile will ever compress to 67 Bytes (which
is incidentally the smallest png file still valid). Why bother to make
it a valid PNG file? So that the tiles at home directory can be easily
viewed by any braindead graphics browser or thumbnail viewer without
proper bad file handling. The fact that the png shows a single black
pixel has nothing to do with it being used as empty tile, but solely
it's filesize of 67 Bytes.
Now the Server has a reliable way of determining which regions of the
map are now empty (even the ones that did have data before) instead of
having to guess.
Before this can be fully taken advantage of by the server it's necessary
for all clients to update to the Cambridge version of tiles at home.

That got a bit lengthier than I thought, but I hope this clarifies
matters a bit.

Dirk-Lüder "Deelkar" Kreie

Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the dev mailing list