Opened 8 years ago

Closed 8 months ago

#4344 closed defect (wontfix)

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

Reported by: lutra Owned by: warmerdam
Priority: normal Milestone: closed_because_of_github_migration
Component: default Version: 1.8.1
Severity: normal Keywords:
Cc:

Description

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

Attachments (1)

out.tif.zip (412.1 KB) - added by Even Rouault 8 years ago.
Result of "rm out.tif; gdalwarp -q -cutline Borneo.shp -of GTiff SEA_2007_deliverable/Insular_SEA_land_cover_2007.tif out.tif"

Download all attachments as: .zip

Change History (11)

comment:1 Changed 8 years ago by 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.

Changed 8 years ago by Even Rouault

Attachment: out.tif.zip added

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

comment:2 Changed 8 years ago by 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.

comment:3 in reply to:  1 Changed 8 years ago by 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).

comment:4 in reply to:  1 Changed 8 years ago by lutra

Replying to rouault:

Hum, I'm a bit lost

Hi, any feedback about this?

comment:5 Changed 8 years ago by 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.

comment:6 Changed 8 years ago by 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

comment:7 Changed 8 years ago by Tilo

Priority: normalhighest
Severity: normalcritical

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

comment:8 in reply to:  7 Changed 8 years ago by lutra

Replying to Tilo:

I request the gdal developers to fix this.

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

comment:9 Changed 5 years ago by Even Rouault

Priority: highestnormal
Severity: criticalnormal

comment:10 Changed 8 months ago by Even Rouault

Milestone: closed_because_of_github_migration
Resolution: wontfix
Status: newclosed

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.

Note: See TracTickets for help on using tickets.