with gdal 1.8 clipping produces shifted raster (ok with gdal < 1.8)

[lutra]

For a complete description see here

​http://hub.qgis.org/issues/4530

Resumed:

using a vector as mask to clip a raster produces an output that is shifted is compared with the (raster) input.

This does NOT happen with gdal < 1.8, only with gdal >= 1.8

[Even Rouault]

Hum, I'm a bit lost.

I tried "rm out.tif; gdalwarp -q -cutline Borneo.shp -of GTiff SEA_2007_deliverable/Insular_SEA_land_cover_2007.tif out.tif" on GDAL 1.7.3, GDAL 1.8.0 and GDAL 1.9.0dev, and I get exactly the same result for each run... And when comparing visualy under QGIS, I absolutely see no artefact.

Ah, and the issue in #4222 was something different. It was about -crop_to_cutline. I don't see it involved in that ticket, right ?

I'm attaching the result of my run so you compare and tell me exactly what you find wrong.

[Even Rouault]

Result of "rm out.tif; gdalwarp -q -cutline Borneo.shp -of GTiff SEA_2007_deliverable/Insular_SEA_land_cover_2007.tif out.tif"

[lutra]

Hi, sorry for the confusion. In believe I found the real cause of the shift.

In the QGIS gdal GUI, when clipping with a vector mask the command produced 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, then the output is shifted. If the command is edited and the second parameter is removed then the output is not shifted. This is obviously easy replicable also from the CLI.

Are both parameters legit in same gdalwarp operation? If not I guess it is a qgis problem only.

Thanks in advance.

[lutra]

Ah, and the issue in #4222 was something different. It was about -crop_to_cutline. I don't see it involved in that ticket, right ?

actually it seems the very same "problem" (maybe just a qgis one).

[lutra]

Replying to rouault:

Hum, I'm a bit lost

Hi, any feedback about this?

[Even Rouault]

yes, it is indeed the same issue as #4222 . Personnaly, I don't see it at as critical one, due to the way how gdalwarp works, that generally never guarantees that the resolution of the input dataset will be kept (even if no reprojection is used, you could notice that if the pixels of the input dataset are not square, gdalwarp will compute square pixels for the output). In the use case describe above, you use -crop_to_cutline in a special case where no warping is done, so I can understand your expectations. However I believe this would require a few hacks at difference places of gdalwarp.cpp to check that we are in that precise case and behave as you expect.

I'm leaving it open, but not particularly willing to take action on it. If someone has sufficient motivation to tackle the issue and provide a patch, I'll try to review it.

[Tilo]

Hi, I have a huge tiff image (covering an entire country) with 3399 columns and 3747 rows, so a total of 12,736,053 cells. The cell size is 1000m or 1km. I needed to extract the data per km2.

I used the gdalwarp -crop_to_cutline in the command line to carve out a portion of the raster image based on the shapefile of a state of the country. The problem is, that although the gdalwarp command worked it caused a shift (of about 500m) during this step. Following suggestions from qgis users I tried gdalwarp -cutline only using the state shapefile, and although it did not cause a shift this time, it did not reduce the size of the whole image either(in the sense, it gave 0 values everyhwere outside the state but still had all those 3399 columns and 3747 rows. This defeats the purpose of my whole exercise of trying to carve out only a portion of the raster on the basis of the state shapefile.

I am requesting the gdal developers to fix this 'shift' issue.

Thanks very much,

Tilottama

[Tilo]

Hi, The problem continues to persist in the newly released qgis 1.7.4. The shifted imaged problem continue. I request the gdal developers to fix this.

Thanks,

Tilottama

[lutra]

Replying to Tilo:

I request the gdal developers to fix this.

"I request"? Have you considered supporting the fix?

[Even Rouault]

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to ​https://github.com/OSGeo/gdal/issues if it is not already reported there.