[gdal-dev] Re: GDAL_retile slowdown at next level
aca at ngi.be
Tue May 18 08:46:28 EDT 2010
I moved my level 1 tiles to a machine with big hard disk, many processors and
a lot of memory.
Then I restarted the process taking the level 1 tiles as source :
gdal_retile.py -targetDir subpyramid/ -levels 11 -pyramidOnly -v -s_srs
/mnt/webgisdata/geoserver/config/3812.prj -ps 512 512 -r bilinear -co
"COMPRESS=JPEG" -co "INTERLEAVE=PIXEL" -tileIndex orthocol -tileIndexField
location --optfile ls.txt &>subpyramid/out.txt &
Differences with previous commands :
-targetDir subpyramid/ : I'm writing to another folder, planning to merge
both pyramids later
-levels 11 instead of 12
--optfile ls.txt : too many files for bash (the source files of the
previous commands were 4000x4000 geotiffs)
&>subpyramid/out.txt : to keep track of the output
In /usr/local/bin/gdal_retile.py, I set the self.cacheSize=1465 (my longest
row is around 458 tiles + security)
It takes a few hours before the first tile is written, gdal_retile prints a
whole bunch of :
ERROR 1: JPEGSetupEncode:RowsPerStrip must be multiple of 8 for JPEG
ERROR 1: TIFFWriteEncodedStrip() failed.
, outputs 297 black tiles then crashes with
Error openenig:<type 'exceptions.NameError'>
I'm not sure if this problem is related with the self.cacheSize change or
with the JPEGSetupEncode error.
Also, I'm not sure whether I had those JPEGSetupEncode errors when creating
the two first levels, as I didn't save the output of the process.
As I think my global problems with pyramid creation are related to the small
tiles, I'll try to produce a pyramid with bigger tiles (4096x4096, inner
tiled). Maybe I should also add -co BLOCKYSIZE=8 ?
I'm sorry I can't provide more feedback on the change of self.cacheSize...
View this message in context: http://osgeo-org.1803224.n2.nabble.com/GDAL-retile-slowdown-at-next-level-tp5034870p5069771.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
More information about the gdal-dev