id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
11555	Tilecache use sometimes scaled tiles instead of existing hires tiles	mdk	mdk	"This is a complex case, I hope I can explain it in a understandable way.

Sometimes single tiles are missing. Especially Bing has sometimes tile server which failed, which cause patterns like
[[Image(Missing_Bing_tiles.png)]]
Tiles could be missing on each zoom level.

Assuming the above image use z17 (now we have z17 tiles in the cache) and zooming to z18. If now a tile is missing in z18, the tile cache is smart enough and try to fill the hole with a scaled version from z17.
[[Image(2x2_tiles_blurred.png)]]
But instead of replacing only the missing tile in z18, the cache takes a tile (which covered the missing z18 tile) from z17, scale it up to 2 by 2 tiles and use all 4 tiles for display, even if only one tile in z18 is missing! The three existing z18 tiles are ignored and “overwitten” with the scaled z17 tiles.

If you zoom in to z19, every thing could be fine like here (Bing has all z19 tiles, and we have the tiles in our cache):
[[Image(hires_tiles.png)]]
But it could get even worst. Assuming a tile is missing in z19 and also the tile to fill the hole is missing in z18, the tile cache uses an existing tile from z17 and scale it up to 4 by 4 tiles. And again the cache is now using all 16 scaled tiles instead of the 15 z19 and only uses the scaled tile for the single missing z19 tile.
I found a case, where every thing was fine (see above), but when I scroll the slippy map a little bit to the west, I came to a tile missing as described above. Now the cache replaces a 4 by 4 are with double scaled tiles:
[[Image(4x4_tiles_blurred.png)]]
And if you scroll back to the ast, the hires z19 tiles are shown again.

The tile cache should only used scaled tiles if they are missing for a zoom level and not using all scaled tiles if he must scale a tile."	defect	closed	minor		Core imagery	latest	irreproducible	bing