[gdal-dev] Error while writing a dirty block in GDALFillNodata()

Sean Gillies sean at mapbox.com
Wed Apr 1 19:30:38 PDT 2015


Answering my own question: I had forgotten that GDALFillNodata() modifies
the given image band in-place and had not opened the dataset for updating.
Once I did that, I was all clear. No problems at all with the MEM files.

On Wed, Apr 1, 2015 at 9:59 AM, Sean Gillies <sean at mapbox.com> wrote:

> Hi all,
>
> I've encountered a problem similar to the one reported at
> https://trac.osgeo.org/gdal/ticket/4088. My case is slightly different:
> I've modified GDALFillNodata() to allow MEM as the temp file format (patch
> accepted in GDAL) and I'm getting the dirty block write error while using
> the MEM driver. The image band that I'm trying to fill is 16,384 x 16,384 =
> 168 million pixels. My computer's activity monitor indicates that I have
> well over 4 GB of RAM available.
>
> The BIGTIFF=IF_SAFER solution for #4088 doesn't appear to help me. Can
> anyone suggest the options I might change to increase the possible size of
> or optimize the creation of temp MEM files?
>
> Thanks,
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20150401/b17b466f/attachment.html>


More information about the gdal-dev mailing list