[Tilesathome] Request timeout

[80n]

On Nov 15, 2007 3:59 AM, Christopher Schmidt <crschmidt at metacarta.com>
wrote:

> On Thu, Nov 15, 2007 at 01:12:30AM +0000, 80n wrote:
> > On Nov 14, 2007 11:16 PM, <hinsons26 at btinternet.com> wrote:
> >
> > > If tile sets take so long to render why not render starting from a
> higher
> > > zoom level, rather than zoom level 12? This would also reduce
> re-rendering
> > > tiles that have not changed I think.
> > >
> >
> > This is a good idea.  Tiles are only going to get more and more complex.
> >
> > Rendering z13-17 should take about 25% of the time and resources
> compared to
> > rendering z12-17.  Not only would more t at h clients stand a better chance
> of
> > success, but the user will see the results quicker.
>
> I'm in favor of this, and will take on the task of changing he server
> side code if we decide to go this route. Who makes the call on the
> client side? How complex are the changes? It seems like there's a number
> of 'tiles are based on z12' assumptions, but I don't know how much
> difference they actually make.
>
> As some have pointed out, this does have some negative affects on
> large labels that cross multiple tiles. Is there any other case where
> this is a problem? Is there a way we can prevent half-labels from
> appearing, to at least avoid cut off label names?
>

The size of the labels at z13 is generally smaller than at z12 so there
should not be any more cropping of place names than is currently experienced
at z12.

The problem then becomes, how to create the z12 tile.  It could be created
using the low-zoom technique of stitching together four z13 tiles, but it
would probably be better to just use the existing method of generating a z12
tile.  This would mean that  a complete z12 tileset would get rendered by
running 4 x z13-z17 tasks and 1 x z12-only task.

If each rendering task is performed by a separate t at h client then the amount
of data downloaded from the api would be twice the current level.  As this
is (I think) currently a bottleneck, the overall throughput of t at h would
halve.  This could be mitigated by deferring the z12-only rendering or
queuing it at a lower priority (or something).

Another approach would be to have the same t at h client download and render
all four z13-z17 tilesets and then concatenate the four downloaded .osm
files to finally generate the z12 tileset.

Another saving could be achieved by implementing change detection and
rendering requests at the z13 level rather than z12.  A t at h client would
then render one z13-z17 tileset and one z12-only tileset.  Unchanged z13
tilesets would not get needlessly re-rendered.

80n





> Regards,
> --
> Christopher Schmidt
> MetaCarta
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tilesathome/attachments/20071115/09e78713/attachment.html>