[Tilesathome] Memory requirement of T at H

[80n]

On Dec 19, 2007 1:17 AM, Brent Easton <b.easton at exemail.com.au> wrote:

> Hi Maciek,
>
> This is known as the T at H Unrenderability theorem:
>
> For any given computer system, there exists a set of tiles that are too
> complex for that system to render in real time.
>
> There are a couple of approaches to this problem:
>
> 1. I have working with Dodi on reducing the size of the SVG files
> generated. The files are bloated out with a lot of extra stuff that is
> outside of the render box and so never get's rendered. It get's pulled in
> along with the place names to handle generation of names accross tile
> borders. The use of the smart-linecaps feature for nearly every single line
> generated also blows out the size and complexity by a factor of at least 2,
> especially in the lowzoom processing. If we can reduce the size of the
> generated SVG, then Inkscape will be better able to process it. Dodi seems
> to be tied up at the moment, so this work has stalled.
>
> 2. I have added the option to use Batik instead of Inkscape to render
> tiles. You may have better luck with Batik in extreme situations.
> Unfortunately, there is a bug in Osmarender that causes Batik to fail
> occasionally. Still working on this one also.
>
> 3. A more general solution is to use Osmosis to cut the dowloaded OSM file
> into smaller strips for processing the higher zoom levels. This will result
> in smalled SVG's. Since the higher zoom levels process the SVG's in strips
> anyway, nothing is lost. This requires a mod to Osmosis and much work on
> tilesgen.pl and I just haven't had a chance to work on it.
>

A better solution would be to have t at h work at z13 instead of z12.  This
will reduce the problem by a factor of 4.  And if it still fails, then run
it at z14.  The original choice of z12 was arbitrary based on the assumption
that it was a manageable size.  Clearly it isn't once a dense urban tile is
fully mapped, particularly for highzoom levels where there is much more
detail, so choose a level that is practical.

This would be far easier than introducing another dependency (osmosis
requires java I think) into the t at h client stack.

80n



>
>
> Hopefully, after Christmas, we can get something happening. Options 1 and
> 2 are in hand. Any assistance offered with option 3 would be appreciated.
>
>
> Regards,
> Brent.
>
>
>
> *********** REPLY SEPARATOR  ***********
>
> On 19/12/2007 at 1:13 AM mkalkal  wrote:
>
> >Hi,
> >
> >   My computer has 1GB of RAM and 3GB of swap,but  when I was given to
> >render such tiles :
> >Doing tileset 1171,1547 (zoom 12)
> >Doing tileset 2103,1347 (zoom 12)
> >inkscape was  killed with out of memory message. My current system is
> >Debian lenny and i686 kernel.
> >I wonder if I should to switch to amd64 kernel in order to give inkscape
> >more virtual space ?
> >Simply adding more swap may not work.
> >What do you think ?
> >
> >
> >Maciek Kaliszewski
> >
> >
> >
> >----------------------------------------------------------------------
> >Najlepsze zdjecia listopada!
> >Zobacz >> http://link.interia.pl/f1ca8
> >
> >
> >_______________________________________________
> >Tilesathome mailing list
> >Tilesathome at openstreetmap.org
> >http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/tilesathome
> >
> >
> >--
> >No virus found in this incoming message.
> >Checked by AVG Free Edition.
> >Version: 7.5.503 / Virus Database: 269.17.4/1188 - Release Date:
> 17/12/2007 2:13 PM
>
>
> ____________________________________________________________
> Brent Easton
> Analyst/Programmer
> University of Western Sydney
> Email: b.easton at uws.edu.au
>
>
> _______________________________________________
> Tilesathome mailing list
> Tilesathome at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/tilesathome
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tilesathome/attachments/20071219/63e87564/attachment.html>