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 _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
