[Tilesathome] Caught in the queue...

[Frederik Ramm]

Hi,

> 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)

Very good!

> 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?

I'd say let the clients deal with that. Just make sure that after  
handing out the same request a number of times and putting it back in  
the queue, you will NOT put it back in the queue.

> Should the list of impossible areas be available to download (and can
> any requesting tools use that list in a sensible way?)

Yes, by all means. It is likely that "impossible" areas are  
impossible because of

(a) bad data
(b) API errors
(c) tilesAtHome/osmarender errors

or a combination. Each of these may be investigated and fixed based  
on alist of "impossible" areas; in fact this list is a valuable input  
for people wanting to fix bugs! And of course they will re-request  
tiles after having fixed bugs.

> 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)

I wouldn't go that far at the moment. I expect "impossible tiles" to  
be freak cases that will lose their freak status after a few days,  
when the bug has been investiaged and fixed. "impossible tiles" are  
not here to stay. A downloadable (or viewable) list - ideally showing  
the time when the tile was last declared "impossible" - should be  
sufficient, and the tile should be cleared from the list as soon as  
it is successfully uploaded by anyone.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00.09' E008°23.33'