Hi everyone,<br><br>Solusion! <br><br>I updated r.out.gdal code - now it does not has 2GB limit, unless target driver has or target driver does not support direct writing.<br><br>If target driver supports GDALCreate (it means direct writing) - this driver is used to output GRASS raster (no more limits).
<br>If target driver does not supports GDALCreate - MEM driver is used to create dataset (in memory) and than destination raster is created with GDALCreateCopy.<br><br>As I mentioned, new r.out.gdal code was created with idea that GDAL should not depend on GRASS while GRASS depend on GDAL (cyclic dependency looks abnormaly).
<br><br>Regards,<br><br>Vytautas<br><br><div><span class="gmail_quote">On 10/26/06, <b class="gmail_sendername">Glynn Clements</b> <<a href="mailto:glynn@gclements.plus.com">glynn@gclements.plus.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>Andrew Danner wrote:<br><br>> I'm all for replacing the r.out.gdal script, but one problem I have with
<br>> the new C version of r.out.gdal is that it creates a temporary raster<br>> entirely in memory<br><br>That's unacceptable.<br><br>If I had realised that, I wouldn't have suggested committing it to<br>CVS. Unfortunately, I don't know enough about GDAL to fix it myself.
<br><br>To anyone else working on the new r.out.gdal: don't waste too much<br>time working on it until someone figures out how to fix this issue. If<br>it can't be done, then the module will be removed.<br><br>--<br>Glynn Clements <
<a href="mailto:glynn@gclements.plus.com">glynn@gclements.plus.com</a>><br><br>_______________________________________________<br>grass-dev mailing list<br><a href="mailto:grass-dev@grass.itc.it">grass-dev@grass.itc.it
</a><br><a href="http://grass.itc.it/mailman/listinfo/grass-dev">http://grass.itc.it/mailman/listinfo/grass-dev</a><br></blockquote></div><br>