Re: tiles@home job queuing... 2600

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: tiles@home job queuing... 2600

On Sunday 26 November 2006 00:12, you wrote:
>      "",

I've been experimenting with some other options for supplying requests:

That's a module-based system, i.e. there are N different strategies for
generating requests, each of which is stored in a separate file somewhere.  A
module is picked at random to handle each request.

Each module might implement a different strategy, like:
* grow data from an existing area
* pick jobs from a queue
* refresh old tiles
* look at RSS feed for places people are editing
* look at planet.osm.diff for new places
* tiles marked as "need update" by people browsing
* popular tiles
* oldest most interesting tiles

Since they're all in separate files, different people can be making changes in
various modules without overwriting each other.  

We can then adjust the weighting of strategies depending on the situation,
* creating data for the first time
* gradual updates (normal use)
* replacing existing data (e.g. new rendering rules)

(Currently there aren't many modules, and they're not high-performance. That
will change)



p.s. Might be worth sending x,y,zoom to the "finished" script rather than
JobID, (it can look-up the job id from that information) since then it can
mark jobs as finished even if the client got its tileset request from some
other method

dev mailing list
[hidden email]

attachment0 (196 bytes) Download Attachment