[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