[gdal-dev] follow warp with translate still?

[Even Rouault]

Le 31/12/2021 à 09:04, Evert Etienne (SITEMARK) a écrit :
> > If you output to regular GTiff, the 2 step process might be needed 
> to get the best compression
>
> Are there some guidelines to when this is needed since you say 'might'?
> Would it be possible to explain why this is the case?

By default, warping doesn't proceed by chunks that would necessarily 
align on entire target blocks, so some target blocks might be rewritten 
several times, which will usually cause some space to be lost in the 
file if it uses compression (at least this is true for GeoTIFF output). 
The whole logic is at 
https://github.com/OSGeo/gdal/blob/master/alg/gdalwarpoperation.cpp#L1363. 
The -wo OPTIMIZE_SIZE=YES warping option can be specified to avoid that, 
but it is sometimes detrimental for speed of execution if the shapes of 
the source and target images are significantly different due to 
characteristics of their CRS.


>
> Thanks
>
> On Dec 30, 2021 23:26, Even Rouault <even.rouault at spatialys.com> wrote:
>
>     Matt,
>
>     There has been an enhancement in gdalwarp to support writing
>     directly to drivers, like COG, that supports only the CreateCopy
>     mode. So you don't need the 2 step process and can directly
>     gdalwarp -of COG (it will more or less do the 2 steps internally)
>
>     If you output to regular GTiff, the 2 step process might be needed
>     to get the best compression
>
>     Even
>
>     Le 30/12/2021 à 22:29, Matt.Wilkie at yukon.ca
>     <mailto:Matt.Wilkie at yukon.ca> a écrit :
>
>         A few years ago it was best practice to follow a gdal warp
>         process with translate in order to get better compression, and
>         even overall speed although extra disk write is involved. Is
>         this still the case? and when using COG output driver?  e.g.
>
>         gdalwarp infile.tif interim.tif
>
>         gdal_translate -of cog -co compress=zstd  interim.tif final.tif
>
>         thanks!
>
>         *Matt Wilkie*
>
>         Geomatics Developer & Administrator
>
>         Environment | Technology, Innovation and Mapping
>
>         T 867-667-8133 | _Yukon.ca
>         <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fyukon.ca%2F&data=04%7C01%7Cevert.etienne%40sitemark.com%7C956448b3d0fb4d64e85e08d9cbe36bbd%7Cfc89adff07ac47008853b7b7e906068e%7C0%7C0%7C637764999902500335%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=RW%2FH6JNyDipGaTjWVJixD38pCPT3PlqrkmZgXQQM%2B80%3D&reserved=0>_
>
>         /Hours: 08:30-16:30, Mon-Wed: Office, Thu: Remote, Fri: Away./
>
>
>         _______________________________________________
>         gdal-dev mailing list
>         gdal-dev at lists.osgeo.org  <mailto:gdal-dev at lists.osgeo.org>
>         https://lists.osgeo.org/mailman/listinfo/gdal-dev  <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.osgeo.org%2Fmailman%2Flistinfo%2Fgdal-dev&data=04%7C01%7Cevert.etienne%40sitemark.com%7C956448b3d0fb4d64e85e08d9cbe36bbd%7Cfc89adff07ac47008853b7b7e906068e%7C0%7C0%7C637764999902500335%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=M%2F%2BmehTP3cdAaThPcV0bk9ChffUupqTzcsaxyJw8jho%3D&reserved=0>
>
>     -- 
>     http://www.spatialys.com  <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.spatialys.com%2F&data=04%7C01%7Cevert.etienne%40sitemark.com%7C956448b3d0fb4d64e85e08d9cbe36bbd%7Cfc89adff07ac47008853b7b7e906068e%7C0%7C0%7C637764999902500335%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=laNHz%2FOiaBi5f62f1cxan%2FF3KcSMJvHREQ0H5ggnVSg%3D&reserved=0>
>     My software is free, but my time generally not.
>
>
-- 
http://www.spatialys.com
My software is free, but my time generally not.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20211231/3f4d037f/attachment.html>