[gdal-dev] gdalwarp -crop_to_cutline produces non-square pixels for EPSG:3857 (GDAL 1.10.1, released 2013/08/26)
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 -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? (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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalwarp -crop_to_cutline produces non-square pixels for EPSG:3857 (GDAL 1.10.1, released 2013/08/26)
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 -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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalwarp -crop_to_cutline produces non-square pixels for EPSG:3857 (GDAL 1.10.1, released 2013/08/26)
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 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 -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 > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalwarp -crop_to_cutline produces non-square pixels for EPSG:3857 (GDAL 1.10.1, released 2013/08/26)
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 > > 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 -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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalwarp -crop_to_cutline produces non-square pixels for EPSG:3857 (GDAL 1.10.1, released 2013/08/26)
Thank you, Even. For now I'll proceed with the additional warping. Just for my education: are square pixels a requirement for EPSG:3857? On Thu, Feb 5, 2015 at 11:50 AM, Even Rouault 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 -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 > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalwarp -crop_to_cutline produces non-square pixels for EPSG:3857 (GDAL 1.10.1, released 2013/08/26)
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 > > 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 -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
