<div dir="ltr">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.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 1, 2015 at 9:59 AM, Sean Gillies <span dir="ltr"><<a href="mailto:sean@mapbox.com" target="_blank">sean@mapbox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>I've encountered a problem similar to the one reported at <a href="https://trac.osgeo.org/gdal/ticket/4088" target="_blank">https://trac.osgeo.org/gdal/ticket/4088</a>. 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.<div><div><br></div><div>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? </div></div></div><div><br></div><div>Thanks,</div></div>
</blockquote></div><br></div>