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

Jesse McGraw jlmcgraw at gmail.com
Thu Feb 5 08:41:22 PST 2015


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

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20150205/e14b5837/attachment-0001.html>


More information about the gdal-dev mailing list