[OSM-dev] JOSM patch to request T at H renders

[David Earl]

> -----Original Message-----
> From: dev-bounces at openstreetmap.org
> [mailto:dev-bounces at openstreetmap.org]On Behalf Of Martijn van
> Oosterhout
> Sent: 23 March 2007 12:49
> To: Robert Hart
> Cc: dev
> Subject: Re: [OSM-dev] JOSM patch to request T at H renders
>
>
> On 3/23/07, Robert Hart <bathterror at gmail.com> wrote:
> > Bear in mind that requests are already automatically queued on
> upload via
> > the RSS feed. This approach just makes it more bullet proof,
> and avoids the
> > need for T at H polling the main server.
>
> I do think we need to try and minimize the number of needless render
> requests. I'd much prefer a system where I could hit a button to
> request a render, rather than do it automatically.
>
> T at H might have overcapacity, but the main server does not, and every
> request is another BBOX request on the main server...

It is *so* much simpler for clients not to have to worry about the
mechanisms by which their work is rendered.

I'm not clear why a BBOX request (by which I assume you mean a database BBOX
request) needs to happen as a result of . Surely the out of date tile
numbers can be determined directly from the lat/long without touching the
database and those tiles put in the queue. In principle, the calculation
could even be done at the JOSM end (though JOSM isn't a place which should
have to know about the tile numbering algorithm.

Of course the rendering itself will then drag lots of data out of the
database (is this where your worry is?). But if a lag time is put on the
queue, say an entry has to have been there say 15 minutes (or even an hour
if you must) before it gets rendered, and the queue is checked for the
presence of a tile before being added (and if there put to the back of the
queue again) then repeated updates won't cause repeated re-rendering. Any
longer than some fairly short time though and you probably do *want* a
re-render to happen.

David