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.roua...@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.roua...@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 _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev