On Nov 15, 2007 3:59 AM, Christopher Schmidt <<a href="mailto:crschmidt@metacarta.com">crschmidt@metacarta.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div class="Ih2E3d">On Thu, Nov 15, 2007 at 01:12:30AM +0000, 80n wrote:<br>> On Nov 14, 2007 11:16 PM, <<a href="mailto:hinsons26@btinternet.com">hinsons26@btinternet.com</a>> wrote:<br>><br>> > 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@h clients stand a better chance of > success, but the user will see the results quicker.

<br><br></div>I'm in favor of this, and will take on the task of changing he server<br>side code if we decide to go this route. Who makes the call on the<br>client side? How complex are the changes? It seems like there's a number

<br>of 'tiles are based on z12' assumptions, but I don't know how much<br>difference they actually make.<br><br>As some have pointed out, this does have some negative affects on<br>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? </blockquote><div> 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.

<br><br>If each rendering task is performed by a separate t@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@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@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@h client would then render one z13-z17 tileset and one z12-only tileset.  Unchanged z13 tilesets would not get needlessly re-rendered.

<br><br>80n<br><br><br><br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>Regards,<br><font color="#888888">--<br>Christopher Schmidt

<br>MetaCarta<br></font></blockquote></div><br>