<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 12, 2016 at 10:20 AM, Markus Neteler <span dir="ltr"><<a href="mailto:neteler@osgeo.org" target="_blank">neteler@osgeo.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Mon, Jan 11, 2016 at 8:04 PM, Panagiotis Mavrogiorgos<br>
<<a href="mailto:pmav99@gmail.com" target="_blank">pmav99@gmail.com</a>> wrote:<br>
> Hi all,<br>
><br>
> Just out of curiosity, why is there an upper limit to the memory we can use<br>
> on operations like r.in.gdal?<br>
<br>
</span>The question is too generic, so I'll refer to r.in.gdal only:<br>
To my knowledge there is a GDAL imposed CACHE limit<br>
<br>
<a href="https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.in.gdal/main.c#L271" rel="noreferrer" target="_blank">https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.in.gdal/main.c#L271</a><br>
<br>
271    /* default GDAL memory cache size appears to be only 40 MiB,<br>
slowing down r.in.gdal */<br>
272    if (parm.memory->answer && *parm.memory->answer) {<br>
273           /* TODO: GDALGetCacheMax() overflows at 2GiB, implement<br>
use of GDALSetCacheMax64() */<br>
274           GDALSetCacheMax(atol(parm.memory->answer) * 1024 * 1024);<br>
<br>
but concerning the data you can import I am not aware of any limit.<br>
<br>
Maybe this page is of interest to you:<br>
<a href="https://grasswiki.osgeo.org/wiki/Large_raster_data_processing" rel="noreferrer" target="_blank">https://grasswiki.osgeo.org/wiki/Large_raster_data_processing</a><br>
<br>
What is exactly your problem you encountered?</blockquote><div><br></div><div>Thank you Marcus, </div><div><br></div><div>That was really helpful. I don't have a particular problem. I just found strange that the limit was so low on x64 architectures.</div><div><br></div><div>with kind regards,</div><div>Panos</div></div><br></div></div>