> 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 _______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/tilesathome
