why cogger? what value does it add to gdal_translate?

[maphew]

Readme could/should describe the value that cogger brings. For example gdal_translate -of cog already creates a cloud optimised geotiff out of the box in one step, so why might someone want to go through the the process of using gdal to preprocess an image, and then run cogger on it afterwards?

[tbonfort]

Bucket-list of answers:

• historically, cogger predates gdal's native COG support
• ability to build a cog from manually built external overviews (gdaladdo and cog have caught up now, but historically they lacked many options as to which options could be used when building overviews). There are still some cases where manually building overviews can be useful (think different compression/lossiness levels per overview level)
• ability to build a cog from individual existing tiles, allowing distributed compression (and therefore near-constant-time creation provided sufficient nodes are available, whatever the image size). The splitting/distribution code is not included as it is very platform dependant, but cogger has the code for the final reconstruction
• ability to directly ouptut to a streaming backend (i.e. cloud storage)
• ability to quickly repackage a cog without recompression after modifying metadata (e.g. nodata value, projection, etc...)
• ability to quickly repackage a cog after having tweaked the number of available overviews
• COG driver cannot be used when programmatically creating a TIF (through WriteBlock etc...). It is in that case much more efficient to create a gtiff file, compute overviews, then run cogger on the result.
• TBC