[Tilesathome] Memory problem in T at H batik

[Brent Easton]

Hi Gert,


>*********** REPLY SEPARATOR ***********
>
>On 16/11/2007 at 3:29 PM Gert Gremmen wrote:
>What I did:
> 
>Runned the tile using batik, creates the memory problem. 
>"glibc ….." seems a memory re-allocation problem.
>The internet is full with this java message, seems a common problem.


Or you might be blowing the 1536MB Heap limit on Linux? 


>Captured the intermediate svg files for all levels.
> 
>Loaded the level 12 .svg in adobe illustrator ; looks OK
>Tried to validate the svg file usinf W3C validator : crash of Validator
>!!!!

That's an Osmarender/XSLT issue, not a Java issue! 

XSLT converts .osm to .svg
Batik (or Inkscape) converts .svg to .png



>Seems  like java is still an immature platform for memory
>intensive applications.
> 
>I still do not understand why some tiles
>have problems, while equally dense tiles in 
>for example Amsterdam render without problem.
> 
>I would also like to know why Mapnik renders
>without problems ? Another approach ?

Mapnik is a C program specifically written for OSM, as opposed to Osmarender which is a cobbling together of generic tools. 

>I would suggest starting to render tiles at level 13
> 
>That would result in 4 x less gross memory to be used.
>Level 12 zoom tile must then be constructed from 
>4 level 13 tiles I think ? 
> 
>Advantages:  4 x faster rendering
>                       smaller uploads
>                      will deal with even complexer tiles.
> 
>Disadvantage : no really rendered level 12 tile


The problem at the moment is that huge SVG's are created for the Zoom 16 and 17 views, which are then immediately rendered in pieces. Low resource clients cannot processs these large SVG's. We need to reduce the size of the Z16 and Z17 SVG's, but at the same time, prevent the need to download the data twice to produce the Z12 (and Z13) in one go, then Z14-17 in another.

My feeling is that we download the Z12 data (plus extra for labels) once as we do now. We can run the Z12-Z15 off this pretty much as we do now. We then run a purpose written program on the client to split the Z12 .osm file into multiple files (perhaps 8 strips, each with overlap for labels) and use these smaller .osm files to generate the Z16 and Z17 views.

The split points could be configurable, so low resource clients might split the OSM data for Z15+, others only for Z16+.

The split program would need to take into account ways and areas that cross or enclose the area of interest without having a node within the section. It really shouldn't be too difficult to write...if one had the time! Conceptually, it is fairly simple and the Java API has plenty of geometry tools to make it pretty easy. 


Regards,
Brent.
____________________________________________________________
Brent Easton                       
Analyst/Programmer                               
University of Western Sydney                                   
Email: b.easton at uws.edu.au