[gdal-dev] gdal_translate with -projwin possible bug

[Even Rouault]

Hi Lauren,

This change was semi intended as far as I can remember (the change that leads 
to that was intended, the effect in this use case not) . It dates back to GDAL 
2.1.0 where the VRT driver can now support floating point coordinates for 
SrcWin / DestWin, and gdal_translate was updated accordingly to not round to 
integer pixel coordinates deduced from world coordinates specified through -
projwin.  Sub pixel accuracy makes sense when using with a resampling that is 
not nearest neighbour with the -r switch. But indeed for nearest neighbour, it 
might result in a non intended shift.
Perhaps a good compromise would be to round to integer for nearest neighbour 
only ?

Regarding Jukka's comment,
> I am sure that there are also users who consider that it is a bug if the
> output does not exactly match -projwin.

Using -a_ullr is a way of definining the output bounds for sure.

Even

> Hello all,
> 
> I've noticed what I think may be a bug with gdal_translate, just looking
> for further information before deciding whether to report it.
> 
> In version 1.11.4 and earlier, using the -projwin tag to subset a raster
> produces an output whose cell alignment and content matches the source
> dataset - it just grabs any cells that intersect the box and writes them to
> the output.
> 
> In v2.1.0 (at least in a Windows environment), this no longer occurs. The
> output raster is distorted to match the exact extent of the -projwin
> coordinates. No resampling is involved, but the cell origins shift, and the
> cell sizes are either shrunk or stretched slightly to conform to the
> projwin box. This is a substantial change in behaviour which doesn't appear
> to have been documented.
> 
> From my point of view, its an unwelcome change. I've been using
> gdal_translate with -projwin and vsicurl to clip out sections of large
> national datasets without having to download the whole file first, and
> without needing to know things like the source dataset origin, cellsize etc
> in order to ensure output aligns with input. I need each dataset I clip out
> to 'stack' properly, and to represent an unaltered subset of the source
> data.
> 
> Please let me know if this is a true bug or just an undocumented change,
> and/or if there's a better alternative command to use.
> 
> Regards,
> Lauren O'Brien

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com