[OSM-talk] Fw: calling all python coders for slippy map help

[Robert (Jamie) Munro]

Mikel Maron wrote:
>> OK I see. I thought the idea was to re-render a tile when someone made a 
>> change, but obviously I got that wrong. If this is the case, the tile 
>> server will essentially have purely static tiles, so there will be no need 
>> for a caching system. So is there really a lot else to do regarding 
>> development on the tile server?
> 
> There will be tile invalidation, but I can't see it being effective to process as a stream ..
> edits in a single area would result in repeated invalidation and regeneration.
> So some kind of batch processing .. perhaps daily, weekly, maybe hourly.

Why is repeated invalidation and regeneration a problem? Surely if the
tileserver is able to keep up with every edit as it is made, that is a
good thing - letting editors see their changes straight away. If the
tileserver isn't keeping up with every edit as it happens, then by the
time it reaches a tile, lots of edits would have been made and one
regeneration of that tile by the tileserver will catch them all. It
should just always process tiles in it's queue. I can't see how it would
end up continuously regenerating the same tiles, while other tiles are
allowed to go stale.

It's queue should be ordered by a function of age of edits outstanding,
amount of edits outstanding and higher resolutions first (because higher
resolutions are faster to generate and small changes are more likely to
be visible only in higher resolutions). Alternatively, it could just
render all tiles in a fixed order, skipping those that haven't changed
since last time.

If it were an hourly batch job, what happens if it doesn't finish within
the hour?

Robert (Jamie) Munro



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20061119/3b54fe35/attachment.pgp>