[OSM-talk] Osmarender 5

[Jon Bright]

Jon Bright wrote:
> 
> I upgraded my t at h installation earlier today.  The first 7 rendered 
> tiles were fine, but the 8th got this error:
> 
> [#8   0% jobinit] Doing tileset 1172,1561 (area around 39.266215,-76.948242)
> [#8 100% default] Finished 1172,1561 for layer default
> [#8   0% maplint] Rendering...                        sh: line 1: 27824 

Ever a sucker for punishment, I ran this tile again.  It's a reasonably 
dense US tile, doubtless from the tiger import.  It can be seen here:

http://www.informationfreeway.org/?lat=39.26370105897797&lon=-76.94513147140968&zoom=12&layers=0B00F000

It again puked on the maplint layer:

[#1   0% maplint] Rendering...                        sh: line 1:  4772 
Aborted                 LC_ALL=C nice "inkscape" -w 256 -h 256 
--export-area=0.000000:0.000000:878.910000:878.742820 
--export-png="/tmp//1119.png_part" "/tmp/output-1119-z12.svg" 
 >/tmp//1119.stdout 2>/tmp//1119.stderr

The SVG file is 37MB:

-rw-rw-r-- 1 sircus sircus 38550239 2007-09-03 21:27 
/tmp/output-1119-z12.svg

Previous inkscape invocations hit a peak of 214MB res.  This one took 
somewhat more:

4772 sircus    29  10  861m 841m 9112 R   90 41.5   0:41.54 inkscape 
         4772 sircus    35  10  893m 868m 9132 R   99 42.8   0:44.53 
inkscape            4772 sircus    35  10 1062m 965m 9132 R   99 47.6 
0:47.52 inkscape

The last line here is the last line that "top -b |grep inkscape" output 
before the error above.  This is still only half what the machine has 
(not counting swap).  Then again, I'd prefer it if t at h didn't take up 
the machine's entire RAM...

If I can supply any more details, let me know.  Equally, if this is 
expected behaviour for a tile that dense, let me know to stop looking :-)

--
Jon