Changes between Version 16 and Version 17 of UserDocs/GdalWarp
- Timestamp:
- Dec 26, 2014, 3:42:20 AM (9 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
UserDocs/GdalWarp
v16 v17 48 48 }}} 49 49 50 Our understanding is that Win32 processes are frequently subject to memory fragmentation problems and so even in a process with - in theory - 2GB of heap RAM space available it is still often difficult to allocate large blocks of memory. In this case with -wm 500 set the main warp buffers can be quite large (364MB for the example) and it seems it has failed to allocate the buffer. Use more modest buffers (or not use the options at all) or else get a 64bit executable for gdalwarp.50 Our understanding is that 32 bit processes are frequently subject to memory fragmentation problems and so even in a process with - in theory - 2GB of heap RAM space available it is still often difficult to allocate large blocks of memory. In this case with -wm 500 set the main warp buffers can be quite large (364MB for the example) and it seems it has failed to allocate the buffer. Use more modest buffers (or not use the options at all) or else get a 64 bit executable for gdalwarp. 51 51 52 52 Source: … … 125 125 partial blocks, leading to lost space in the output format. 126 126 127 The situation can be improved by using the [http://gdal.org/structGDALWarpOptions.html#a0ed77f9917bb96c7a9aabd73d4d06e08 OPTIMIZE_SIZE warping option] ,128 but not that depending on the source and target projections, it might also significantly slow down127 The situation can be improved by using the [http://gdal.org/structGDALWarpOptions.html#a0ed77f9917bb96c7a9aabd73d4d06e08 OPTIMIZE_SIZE warping option] ("-wo OPTIMIZE_SIZE=YES"), 128 but note that depending on the source and target projections, it might also significantly slow down 129 129 the warping process. 130 130