[gdal-dev] gdalwarp -crop_to_cutline produces non-square pixels for EPSG:3857 (GDAL 1.10.1, released 2013/08/26)

[Even Rouault]

Le jeudi 05 février 2015 17:57:02, Jesse McGraw a écrit :
> Thank you, Even.  For now I'll proceed with the additional warping.
> 
> Just for my education: are square pixels a requirement for EPSG:3857?

In the general case, no. But it might be a requirement (or an optimization) 
depending on what you do with your data afterwards. Difficult to give a 
definitive answer on that...

> 
> On Thu, Feb 5, 2015 at 11:50 AM, Even Rouault <even.rouault at spatialys.com>
> 
> wrote:
> > Le jeudi 05 février 2015 17:41:22, Jesse McGraw a écrit :
> > > Thanks Even.
> > > 
> > > I did try re-warping the cropped output to 3857 again and it does
> > > produce square pixels but at the expense of an additional warping
> > > operation
> > > 
> > > I'm just curious why the warping that is part of the -crop_to_cutline
> > > process is changing the pixel ratio while a regular, non-cropping
> > > warping makes them square
> > 
> > I think I explained it in my previous answer. This is because
> > -crop_to_cutline
> > uses -te internally, which in the general case doesn't allow pixel
> > squares. And non-cropping warping doesn't necessarily preserve extent of
> > the output to
> > be the same as extent of the input (even in non-reprojection cases). You
> > can
> > check that actually by comparing gdalinfo on the temporary and final
> > datasets.
> > There's no fundamental reason why -crop_to_cutline couldn't produce exact
> > square pixels, if people are annoyed by that behaviour. Just someone has
> > to do
> > it...
> > 
> > > On Thu, Feb 5, 2015 at 11:36 AM, Even Rouault <
> > 
> > even.rouault at spatialys.com>
> > 
> > > wrote:
> > > > Le jeudi 05 février 2015 17:23:06, Jesse McGraw a écrit :
> > > > > I'm not sure whether this is a real issue or not but I thought I'd
> > > > > bring
> > > > 
> > > > it
> > > > 
> > > > > up, at the very least I'll learn something
> > > > > 
> > > > > When using "gdalwarp -cutline <shapefile> -crop_to_cutline" on an
> > 
> > input
> > 
> > > > > raster that is in EPSG:3857 with square-pixels the output raster,
> > 
> > while
> > 
> > > > > still EPSG:3857, now has non-square pixels.
> > > > > 
> > > > > They're aren't terribly non-square but aren't they supposed to be
> > > > > completely square for EPSG:3857?
> > > > 
> > > > Perhaps... Actually the effet of -crop_to_cutline is exactly the same
> > 
> > as
> > 
> > > > manually passing the target extents with -te with the bounding box of
> > 
> > the
> > 
> > > > cutline.
> > > > It is not possible to both preserve the extent extents and pixel size
> > 
> > at
> > 
> > > > the
> > > > same time, due to width and height being integer values.
> > > > So, in order to preserve pixel square, the extent should be modified
> > > > a little
> > > > bit. What is more appropriate is a matter of point of view I think.
> > > > You can always re-run "gdalwarp tmp.tif out.tif" where tmp.tif is the
> > > > output
> > > > of first gdalwarp with -crop_to_cutline. And you should get square
> > 
> > pixels
> > 
> > > > I believe.
> > > > 
> > > > > (FWIW, I see that there are tickets opened that reference similar
> > > > > issues but they reference the output being shifted or the origin
> > > > > changing, not
> > > > 
> > > > the
> > > > 
> > > > > pixel shape changing)
> > > > > 
> > > > > For example:
> > > > > #Warp our original .tif to EPSG:3857
> > > > > $gdalwarp \
> > > > > 
> > > > >         -t_srs EPSG:3857 \
> > > > >         -dstalpha \
> > > > >         -co TILED=YES \
> > > > >         "ENR_L33.tif" \
> > > > >         "./2.tif"
> > > > > 
> > > > > #See that the output pixels are square
> > > > > $gdalinfo 2.tif
> > > > > Origin = (-8577554.996301921084523,5421778.172851986251771)
> > > > > Pixel Size = (43.677179501975118,-43.677179501975118)
> > > > > 
> > > > > 
> > > > > #Now crop the image to a cutline
> > > > > $gdalwarp \
> > > > > 
> > > > >         -crop_to_cutline \
> > > > >         -dstalpha \
> > > > >         -cutline "./ENR_L33.shp" \
> > > > >         -cblend 10 \
> > > > >         -co TILED=YES \
> > > > >         "./2.tif" \
> > > > >         "./3.tif"
> > > > > 
> > > > > #See that output pixels are not square
> > > > > $ gdalinfo 3.tif
> > > > > Origin = (-8480047.445924906060100,5366376.137789577245712)
> > > > > Pixel Size = (43.678439570399853,-43.675457269061347)
> > > > > 
> > > > > 
> > > > > I ran some more tests and without the -crop_to_cutline option the
> > > > > output pixels remain square
> > > > > 
> > > > > Thanks,
> > > > > 
> > > > >   Jesse
> > > > 
> > > > --
> > > > Spatialys - Geospatial professional services
> > > > http://www.spatialys.com
> > 
> > --
> > Spatialys - Geospatial professional services
> > http://www.spatialys.com

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