[OSM-dev] tiles at home disk usage

Jeroen Dekkers jeroen at vrijschrift.org
Wed May 2 18:08:37 BST 2007

At Wed, 2 May 2007 16:59:45 +0200,
Frederik Ramm wrote:
> Hi,
> > The lookup would work like this:
> > query the db, if it's a sea tile, return that tile. Else lookup the
> > tile on the hard disk and return that. If there isn't a tile, return
> > the empty tile.
> I am still unsure if this is a good idea. We have just dropped the  
> "every request goes to the database" method and I would not want to  
> re-introduce that unless necessary.
> For me it is important that uploaded tiles have the highest priority.  
> If someone uploads something for an area that was until then believed  
> to be blue sea, then that tile has to be used. In your case, that  
> would mean a write request to that extra table where you keep the sea  
> tiles.
> I think I still favour first checking the file system, then the  
> database if nothing is found. The directory lookups are, I believe,  
> relatively cheap as they, too, can get cached.
> > I'm not sure what exactly to store in the db. It should be that
> > information that has the smallest total size, so we can try to keep
> > the table in memory. I also don't know what the best way to store the
> > info is. We can probably group 16 tiles together in one int. That
> > would be the equivalent of a level 15 tile. We can use bit operations
> > to get the information for the level 16 and 17 tiles. The first bit of
> > the int would be the 0,0 level 17 tile within the level 15 tile,
> > second bit 0,1 etc. Then we can also find out with simple bit
> > operations whether the level 16 and level 15 tiles are sea tiles (if
> > all bits say sea, then the level 15 tile is also a sea tile). We can
> > also pack level 12, 13 and 14 tiles that way.
> Sounds awfully complicated. Is that really necessary? I'd advocate  
> storing one plain simple SQL row for each tile in our normal metadata  
> table and that's it. For empty tiles, whether water or land, I'd  
> allow the optimisation that if a record is not found for a certain  
> tile, the next-lower zoom level is tried to find out whether it is  
> land or water.

Yeah, we should probably first implement things this way. If that
doesn't scale enough, we can try to optimise things further. I'm just
trying to think of the fastest way to implement things.

Jeroen Dekkers

More information about the dev mailing list