[Tilesathome] Caught in the queue...

[OJW]

On Saturday 26 May 2007 09:45, Damian Sulewski wrote:
> there are tiles, for which the API always returns do data to the t at h
> client, so the tiles are not rendered.
> 2209 1342 at z12 is such a tile.
> If such a tile gets into the request que it will never leave it, since
> it will never be rendered. Furthermore, since there are more of them out
> there, they will fill the que, and slowdown the rerendering.


Just added some code to count the number of "retries" in a request (the number 
of times that a rendering client took the request but failed to upload the 
result)

Presumably we want to mark the request as "probably impossible" if this 
exceeds a certain limit, so that it doesn't keep getting returned to the 
"new" queue.

Then we need lots of other logic to deal with what happens when it next gets 
requested.  e.g. should it be OK to manually re-request an "impossible" area, 
but not allow a priority-2 ("automated") request to be accepted for that 
area?  Should the list of impossible areas be available to download (and can 
any requesting tools use that list in a sensible way?)  

Should such areas be marked on the visible map?  How? (e.g. dedicated map 
layer that returns either (a) transparent or (b) semitransparent warning 
symbol depending on whether a tile is in that list, so that it can be 
overlaid on an openlayers map)