[Tilesathome] Cutover to new server? When?

spaetz osm at sspaeth.de
Sat Jul 12 20:10:59 BST 2008


> Presumably that will also mean that re-rendering all of the tiles under 
> the new server will take at least as long. So there will be an overlap 
> of old and new system for quite a while. I think that is perfectly fine, 
> but it does mean that the legacy system has to work well. I.e. the 
> blankness lookup must be implemented correctly.

I don't do database lookups for blankness in the legacy code, I just look for a real tile. Going through the "new tile search" -> "old tile file search" -> "recursive database search" would be quite a stretch for an operation that should be blazingly fast.

> I see three possible options for the legacy blankness lookup.
> 1) Just like the LegacyTileset, call the old blankness db. From your 
> numbers above, this seems quite inefficient though, although I could 
> imagine this could be optimised quite a bit, e.g. not spanning a new 
> database connection on each new lookup
> 2) Implement a new blankness database in some form. Not sure how this 
> would be populated though.
> 3) Use the ocean tiles db as a fallback of the fallback. From my 
> previous tests, this was actually quite efficient and easy to code at 
> least for z12 and above.

I'd appreciate a patch for solution 3, if you can make it efficient enough. The code would be called from the serve_legacy_tile function in Tile.py in the directory tah_intern.
I am still not 100% sure that this will be necessary or efficient enough, but we should try it.

spaetz




More information about the Tilesathome mailing list