#5951 closed defect (fixed)
gdalwarp crop_to_cutline weirdness
Reported by: | rghosh0 | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | 2.0.0 |
Component: | Utilities | Version: | unspecified |
Severity: | normal | Keywords: | warp crop_to_cutline |
Cc: |
Description
Hi,
The 'crop_to_cutline' option for gdalwarp is described as: "Crop the extent of the target dataset to the extent of the cutline."
It seems that this isn't always the case. I'm using a four-corner cutline in the process of warping a geotiff from a Lambert Conformal Conic projection to NA83 lat/long. Without using crop_to_cutline, I get my entire image. When I use crop_to_cutline, it seems that only the corners, and not the entire extent, of the cutline are used for cropping, and so part of the warped image is cut off.
http://s3.amazonaws.com/arcturus/with_crop_to_cutline.png
http://s3.amazonaws.com/arcturus/no_crop_to_cutline.png
This doesn't seem desirable to me, nor consistent with what is described in the man page. Nor does the cropping behaviour seem consistent with the cutting behaviour in how the cutline is interpreted.
Change History (8)
follow-up: 3 comment:1 by , 9 years ago
comment:2 by , 9 years ago
Hum I think I know what happens. The target extens computed from the -crop_to_cutline is the bounding box of the projected vertices of the cutline. In the case ot this reprojection, they don't actually form the real reprojected extent. So some intermediate points should be added to densify the line. The workaround is to use ogr2ogr -segmentize to produce a more dense cutline.
comment:3 by , 9 years ago
Replying to jratike80:
Could you add the commands which you have used, your cutline and if possible, an image to play with so that others can reproduce your issue?
Sure,
Source image: http://aeronav.faa.gov/enroute/04-30-2015/enr_h07.zip
Cutlines (use any one of these; same result):
http://s3.amazonaws.com/arcturus/cutlineNAD83.zip http://s3.amazonaws.com/arcturus/cutlineMerc.zip http://s3.amazonaws.com/arcturus/cutlineLambertConformalConic.zip
Commands:
tiff2rgba -c none ENR_H07.tif decompressed.tif
listgeo -proj4 ENR_H07.tif > orig.prj
geotifcp -g orig.prj decompressed.tif decomp-geo.tif
gdalwarp -wm 1024 -wo NUM_THREADS=4 -t_srs +proj="longlat +datum=NAD83 +no_defs" -r cubic -tr 0.005 0.005 -cutline cutline.shp -cl cutline -crop_to_cutline -dstnodata "0 0 0 0" decomp-geo.tif output.tif
comment:4 by , 9 years ago
I've analyzed this use case and I'm not convinced there's something to do in gdalwarp itself since it might depend on use cases. Your cutline matches the corners of the validity zone in the source image, which forms a rectangle.
Here's what I've done :
1) Reproject the cutline into the source SRS:
ogr2ogr cutline_usifr.shp cutline.shp -t_srs "+proj=lcc +lat_1=45 +lat_2=33 +lat_0=39 +lon_0=-95 +x_0=0 +y_0=0 +datum=NAD83 +units=m +no_defs"
2) Densify it :
ogr2ogr cutline_usifr_segmentize.shp cutline_usifr.shp -segmentize 10000
3) Do the reprojection (you don't need to use tiff2rgba. gdalwarp -dstalpha can add an alpha channel):
gdalwarp -wm 1024 -wo NUM_THREADS=4 -t_srs +proj="longlat +datum=NAD83 +no_defs" -tr 0.005 0.005 -cutline cutline_usifr_segmentize.shp ENR_H07.tif out.tif -overwrite -dstalpha -overwrite -crop_to_cutline -r cubic
comment:5 by , 9 years ago
EDIT: reconsidering my above statement, actually since without -crop_to_cutline the warper works correctly, it would be nice that in crop_to_cutline we automatically do this reprojection to source SRS, densification and reprojection to target SRS.
comment:7 by , 9 years ago
Component: | GDAL_Raster → Utilities |
---|---|
Keywords: | warp crop_to_cutline added |
Milestone: | → 2.0 |
Resolution: | → fixed |
Status: | new → closed |
Could you add the commands which you have used, your cutline and if possible, an image to play with so that others can reproduce your issue?