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