QGIS » QGIS Application

Hi Agus,

if there is a problem it should be in gdal, not the tools. Please give it a try from the command line.

In any case I think this is expected and not a bug as the clipping doesn't occur exactly on a pixel edge of the input dataset.

1. I confirm this is a problem in GDAL as the same result is produced by the command pasted on the console.

Hi Agus,
I actually tested the operation myself on qgis-master/Ubuntu 11.10 and gdal 1.7.x or 1.6.x and I can't find any shift. The command is

gdalwarp -q -cutline /home/gio/Desktop/Borneo.shp -of GTiff /home/gio/Desktop/SEA_2007_deliverable/Insular_SEA_land_cover_2007.tif /home/gio/Desktop/clip3.tif

On the other hand with both Linux and Windows, when using a QGIS version compiled against gdal 1.8.x I get the shift. The shift I see is half pixels size (half width) in the south east direction, not north east...

This issue is probably related to this

http://trac.osgeo.org/gdal/ticket/4222

that I filed in the GDAL trac a while ago and that was rejected.

The issue is in any case definitely a GDAL issue, and you may want (please) insist with the GDAL developers that this is a regression.

Speaking more in general (and not considering the shift problem in gdal >= 1.8):

The vector border obviously passes trough pixels so, in the result raster, what I see is that if more of 50% of the pixel of the input raster - cut by the vector border - is "inside" the vector mask, than is part also of the output raster (with the right value), otherwise (less than 50% of the pixel "inside" of the vector mask) the pixel is part of the output raster.

Using the "value tool" plugin is very easy to verify it and also see that all the other pixels (the ones completely "inside" the vector mask) do match perfectly in both input and output rasters.

2. In my opinion, this is a bug: clipping a raster should leave the geometry of the remaining pixels unmodified. Note this
result is particularly wrong for categorical raster layers (i.e., landcover maps).

There is no way to have the vector mask fit exactly the edges of the raster pixels... Well... there is one way, you can rasterize the vector, make it a mask and then clip the original raster with it. I'll do this operation in a few seconds in QGIS using the GRASS plugin. If you set the GRASS region with the extent and the resolution of the input raster then, when rasterizing, the vector will fit perfectly the edges of the pixels of your input raster.

Actually, note that this
problem does not occur if you draw the rectangle interactively.

see the attached screenshot, drawing interactively the rectangle mask do not fit the raster pixels edges. If you know the extension of the input raster, the coordinates of the corners and the resolution than you can easy make the clip rectangle fit the edges of the pixels by introducing its extent manually.

The input clipping vector should me automatically modified to
match the raster grid by default. The current behaviour could be an option, and in this case a choice of interpolation should
also be prompted.

See above, this is somehow already done: if the pixels - where the mask border pass trough - are mainly inside the mask, then are part of the output. If you want the vector borders follow the pixels edges then you have to rasterize it.

Oh gosh, what a mess.

I was sure that I made pretty precise tests, then found a pattern (the gdal version) so I filed the ticket in the gdal trac. They didn't confirmed, so I made another round of tests and now I can safely say that I found the real pattern.

Using gdaltools the produced command is like

gdalwarp -q -cutline /home/gio/Desktop/SEA_2007_deliverable/Borneo.shp -crop_to_cutline -of GTiff /home/gio/Desktop/SEA_2007_deliverable/Insular_SEA_land_cover_2007.tif /home/gio/Desktop/SEA_2007_deliverable/out_ubuntu_gdal180_qgis.tif

with both "-cutline" and "-crop_to_cutline" parameters.

If both are left in the command, then the output get the observed shift.

if you edit the command in the gdaltools GUI (now that is possible) and remove the "-crop_to_cutline" parameter, then the output is not shifted.

I reopen the ticket as I'm not sure if is a bug, and especially if is a gdal tools one or a gdal one. I will leave feedback in the ticket I filed in the gdal trac, and then let you know when they will answer.

Ok, the issue is then in GDAL not QGIS. This can become a feature request.

Should be fixed in the Processing front-end. Please reopen if necessary