[OSM-dev] tiles at home disk usage
frederik at remote.org
Wed May 2 15:59:45 BST 2007
> 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
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.
>> (Instead of communitcating via byte sizes, an XML "meta data file"
>> could be envisaged, but that can also be done as a tidy-up step
> We could also just put two simple text files called emptytiles.txt and
> bluetiles.txt in the zip file. On each line there would be an x,y tile
> number that is an empty or blue tile. I don't really see a need for
> XML... :-)
Sure, that would only be preparing for a future time in which we
would wnat to transfer other metadata, like full version numbering/
checksums of client's files, date when source data was fetched from
server, and so on.
Frederik Ramm ## eMail frederik at remote.org ## N49°00.09' E008°23.33'
More information about the dev