On 06/12/2010 13:15, Even Rouault wrote:
Selon Hermann Peifer<pei...@gmx.eu>:
Even,
Thanks for the quick feedback.
Just to clarify: last week, I compiled revision 21190 from
http://svn.osgeo.org/gdal/trunk/gdal, configured
--with-libtiff=internal.
Hum OK so there's definitely a bug somewhere. Would be worth opening a ticket if
you had a way of reproducing those errors. Ideally with a smaller shapefile.
Would be interesting to see if it works better with another compression scheme,
let's say DEFLATE.
Thanks for the hint with DEFLATE. And yes, I am working on a 64 bit
Debian/Linux system.
As far as I can see: the LZW error only occurred while processing this
one file, which also happens to be the biggest out of 231 shapefiles
that I am handling in my current task. So it might be difficult to
reproduce the error with a smaller file.
1 additional question, as I do not really understand the inner workings
of gdal_rasterize:
Does it help at all what I did when trying to reduce the memory demand:
to loop through the geometries by some CODE value? Does gdal_rasterize
always load *all* the geometries into memory, independent of the -where
filter ?
Hermann
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
