[Tilesathome] Memory problem in T at H batik

[Gert Gremmen]

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.

 

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
!!!!

 

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 ?

 

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

 

===================================

 

Another thing that goes trough my head:

 

when rendering vector data into bitmap the following should

be required in terms of memory

 

memory values rounded up to 1 MB

 

Level 12  :   1 MB   =  1 tile   ( 256x256)   

Level 13 :    1 MB   =  4 tiles (512 x 512)

Level 14:    2 MB   = 16 tiles  (1024x1024)

Level 15:    5 MB  = 64 tiles  (2048 x 2048)

Level 16:    17 MB = 256 tiles ( 4096 x 4096)

Level 17 :  68 MB =   1024 tiles ( 8192 x 8192)

 

This should be multiplied by 3 if 32 bits color

rendering (though I think that 256 colors may do)

 

assuming 32 bit color, level 17 full rendering

leads to a bitmap file of only 8192 x 8192 x 3

201.3 Megabyte

 

I understood that a substantial space around each tile is

also rendered, to allow for data that origins from neighboring

tiles to be rendered on the tile in question

(such as place names)

 

half a tile on four sides equals 2 extra tiles

a  quarter of a tile on the 4 corners equals 1 extra tile

 

so a total of four tiles of surfaces 

need to be rendered to create

one tile  of 8192x8192 (level 17) 

(to be cut in 1024 tiles of 256x256)

 

that is 1 tile of 16384 x 16384 pixels = 806 MB

 

To that value one needs to add the memory requirements

of the software.

 

So two ways remain to reduce memory requirements:

 

1/ Reduce the color space with a selected map of 256 colors ( 3 x less
memory)

2/ Start rendering at level 13  (4 times less memory)

 

For an application to function reliably, I think that

it should not use more then 35 % of the available memory.

For a client to run with 500 MB that is 150 MB approx.

If both measures above are to be implemented

that would be easy to manage.

 

 

I think that most  of these calculations have been made earlier, but
it's good to recapitulate.

 

 

I am not familiar with the actual  T at H system, so I may

be incorrect with some of my calculations.

Please correct in that case.

 

Regards,

 

Ing. Gert Gremmen

Email: b.easton at uws.edu.au

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tilesathome/attachments/20071116/13f03e5c/attachment.html>