id,summary,reporter,owner,description,type,status,priority,milestone,component,version,resolution,keywords,cc,cpu,platform 2404,winGRASS: G_calloc error in v.to.rast,neteler,grass-dev@…,"winGRASS (32bit binaries): v.rast.stats --> which calls v.to.rast: {{{ ERROR: G_calloc: unable to allocate 236326912 * 1 bytes of memory at raster.c:83 ERROR: An error occurred while converting vector to raster }}} Computational region: {{{ g.region rast=somemap@LANDCOVER -p projection: 99 (Lambert Azimuthal Equal Area) zone: 0 datum: etrs89 ellipsoid: grs80 north: 5416100 south: 941500 west: 1547000 east: 7316700 nsres: 100 ewres: 100 rows: 44746 cols: 57697 cells: 2581709962 g.region vect=othermap@LANDCOVER -p projection: 99 (Lambert Azimuthal Equal Area) zone: 0 datum: etrs89 ellipsoid: grs80 north: 5310000 south: 940000 west: 1540000 east: 6530000 nsres: 100 ewres: 100 rows: 43700 cols: 49900 cells: 2180630000 }}} System: * winGRASS 7.1 * RAM 32 GB Also reported here: * http://lists.osgeo.org/pipermail/grass-user/2009-April/050076.html * http://lists.osgeo.org/pipermail/grass-user/2009-April/050074.html * http://lists.osgeo.org/pipermail/grass-user/2009-April/050075.html The issue might be the row cache in v.to.rast: * http://trac.osgeo.org/grass/browser/grass/trunk/scripts/v.rast.stats/v.rast.stats.py#L137 * http://grass.osgeo.org/grass71/manuals/v.to.rast.html with rows=4096 (Number of rows to hold in memory by default). According to the latter email, the memory consumption would be (in GB, plus overhead): {{{ > 4096 * 44746 rows * 8 bytes /1024 /1024 /1024 [1] 1.36554 }}} Given the 32GB of RAM, that should be ok (but even for winGRASS 7 32bit?). Maybe the row cache in v.to.rast should be ""auto"" according to the amount of pixels in a row? BTW: seen again here: * https://gis.stackexchange.com/questions/102273/error-g-calloc-v-to-rast",defect,closed,normal,7.0.0,Vector,svn-trunk,fixed,v.to.rast,,Unspecified,MSWindows 7