gdalwarp ignores cutline when -tr specified

[warmerdam]

Frank,

I’m using gdal-16 and came across an issue while using gdalwarp with the cutline option. Basically it works as expected without the target resolution specified. So a simple call uses the cutline to restrict the source data area works fine:

E:\>gdalwarp E:\DEV\2009\Frank\Cutline\source.tif E:\DEV\2009\Frank\Cutline\out1.tif  -cutline E:\DEV\2009\Frank\Cutline\alpha.shp

Creating output file that is 655P x 520L.

Processing input file E:\DEV\2009\Frank\Cutline\source.tif.

0...10...20...30...40...50...60...70...80...90...100 - done.

However, in the following command where the target resolution is lower than the source, the result is very different (its seems to ignore the cutline):

E:\>gdalwarp E:\DEV\2009\Frank\Cutline\source.tif E:\DEV\2009\Frank\Cutline\out2.tif  -cutline E:\DEV\2009\Frank\Cutline\alpha.shp -tr 0.00015 0.00015

Creating output file that is 437P x 347L.

Processing input file E:\DEV\2009\Frank\Cutline\source.tif.

0...10...20...30...40...50...60...70...80...90...100 - done.

[warmerdam]

I have established that the problem is that the cutline is internally used to build source masks, but the LoadCutline?() function in gdalwarp.cpp is actually transforming the cutline to *destination* file pixel coordinates.

Some non-trivial rework in gdalwarp.cpp will be required.

[warmerdam]

I have significantly restructured gdalwarp to address this problem. The fix is in trunk (r16368) and 1.6 branch (r16369). I have also introduced a test for this situation (r16367).

I'm rebuilding the OSGeo4W GDAL 1.6 package now.

[warmerdam]

The OSGeo4W gdal-1.6 package has been updated to 1.6.0-7 with the fix.