On Nov 15, 2007 3:59 AM, Christopher Schmidt <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 15, 2007 at 01:12:30AM +0000, 80n wrote: > > On Nov 14, 2007 11:16 PM, <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 >
_______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/tilesathome
