On Dec 19, 2007 1:17 AM, Brent Easton <[EMAIL PROTECTED]> wrote: > Hi Maciek, > > This is known as the [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 > >[email protected] > >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: [EMAIL PROTECTED] > > > _______________________________________________ > Tilesathome mailing list > [email protected] > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/tilesathome >
_______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/tilesathome
