Feature request #4530

GdalTools Clipper: make "-crop_to_cutline" a separate option

Added by alobo - over 5 years ago. Updated 3 months ago.

Status:Closed
Priority:Normal
Assignee:-
Category:Processing/GDAL
Pull Request or Patch supplied:No Resolution:fixed/implemented
Easy fix?:No

Description

I get a shifted result if clipping a raster layer with a vector layer.
Raster to be clipped:
South East Asia_2007_deliverable.zip from
http://www.eorc.jaxa.jp/SAFE/LC_MAP/
(no direct link)
Clipping vector: https://sites.google.com/site/filestemp2/home/Borneo.zip
Clipped result: https://sites.google.com/site/filestemp2/home/BorneoLC.tif

Zoom in the coast to see a ~1 pixel shift to the NE
Qgis 1.7.1.
GdalTools 1.2.28
GDAL:1.8.0

Agus

snapshot4.png (260 KB) Giovanni Manghi, 11/17/2011 01:38 AM

snapshot8.png (199 KB) Giovanni Manghi, 11/17/2011 01:38 AM

snapshot10.png (198 KB) Giovanni Manghi, 11/17/2011 01:38 AM

snapshot11.png (189 KB) Giovanni Manghi, 11/17/2011 01:38 AM

History

#1 Updated by Giovanni Manghi over 5 years ago

  • Status changed from Open to Feedback

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.

#2 Updated by alobo - over 5 years ago

Hi Giovanni,

1. I confirm this is a problem in GDAL as the same result is produced by the command pasted on the console.
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). Actually, note that this
problem does not occur if you draw the rectangle interactively. 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.

Perhaps if agree on this modification we could ask the GDALtools to consider it?

Agus

#3 Updated by alobo - over 5 years ago

I meant the GDALtools developer team...

#4 Updated by Giovanni Manghi over 5 years ago

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.

#5 Updated by Giovanni Manghi over 5 years ago

Giuseppe (the gdal tools developer), what do you think about? Do you confirm is a gdal issue?

#6 Updated by Giovanni Manghi over 5 years ago

alobo - wrote:

I meant the GDALtools developer team...

I filed a ticket in the GDAL trac

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

I hope they will not reject it as

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

#7 Updated by Giovanni Manghi over 5 years ago

  • Target version changed from Version 1.7.2 to Version 1.8.0
  • Status changed from Closed to Feedback
  • Resolution deleted (invalid)

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.

#8 Updated by Giuseppe Sucameli over 5 years ago

Anyone confirm that it works fine when clipping the raster with a rectangular region?
If yes, in my opinion is a GDAL bug,
otherwise I may remove the -crop_to_cutline option (intended to shift the output raster cuttin' pixels) and then change it with the extent of the cutline fitted to the grid.

#9 Updated by Giovanni Manghi over 5 years ago

Giuseppe Sucameli wrote:

Anyone confirm that it works fine when clipping the raster with a rectangular region?
If yes, in my opinion is a GDAL bug,
otherwise I may remove the -crop_to_cutline option (intended to shift the output raster cuttin' pixels) and then change it with the extent of the cutline fitted to the grid.

clipping with the interactive rectangle/window (then using gdal_translate) is ok, no shift.

#10 Updated by Giovanni Manghi over 5 years ago

This is the answer of the gdal developers

http://trac.osgeo.org/gdal/ticket/4344#comment:5

#11 Updated by Giovanni Manghi over 5 years ago

Giovanni Manghi wrote:

This is the answer of the gdal developers

http://trac.osgeo.org/gdal/ticket/4344#comment:5

My suggestion is then to add the "-crop_to_cutline" parameter as optional with a checkbox.

#12 Updated by Giovanni Manghi over 5 years ago

  • Tracker changed from Bug report to Feature request
  • Subject changed from GdalTools Clipper: shifted result to GdalTools Clipper: make "-crop_to_cutline" a separate option
  • Status changed from Feedback to Open

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

#13 Updated by Giovanni Manghi about 5 years ago

  • Target version changed from Version 1.8.0 to Version 2.0.0

#14 Updated by Pirmin Kalberer over 4 years ago

  • Target version changed from Version 2.0.0 to Future Release - Nice to have

#15 Updated by Paolo Cavallini over 4 years ago

  • Assignee changed from Giuseppe Sucameli to anonymous -

#16 Updated by Jürgen Fischer almost 3 years ago

  • Assignee deleted (anonymous -)

#17 Updated by Alexander Bruy over 2 years ago

I can confirm issue with shifted results when clipping rasters.

#18 Updated by Pedro Venâncio over 1 year ago

Since this issue is still unsolved from the GDAL side, I think it is best to put the -crop_to_cutline parameter as optional. I've made a Pull Request with this change: https://github.com/qgis/QGIS/pull/2351

Furthermore, I added the -tr xres yres (set output file resolution (in target georeferenced units)) parameter [also as optional] that seems important to me.

#19 Updated by Giovanni Manghi 5 months ago

  • Category changed from GDAL Tools to Processing/GDAL

#20 Updated by Alexander Bruy 3 months ago

  • Status changed from Open to Closed
  • Resolution set to fixed/implemented

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

Also available in: Atom PDF