[PROJ] [gdal-dev] LIBERTIFF / Thread-safe TIFF reader

[Michael Smith]

It’s a COG so it just decompresses and reads the tiles/cells needed for reprojection

 

 

-- 

Michael Smith

Remote Sensing/GIS Center

US Army Corps of Engineers

 

 

From: PROJ <proj-bounces at lists.osgeo.org> on behalf of Rahkonen Jukka via PROJ <proj at lists.osgeo.org>
Reply-To: Rahkonen Jukka <jukka.rahkonen at maanmittauslaitos.fi>
Date: Sunday, December 22, 2024 at 3:12 PM
To: Howard Butler <howard at hobu.co>, Even Rouault <even.rouault at spatialys.com>
Cc: gdal dev <gdal-dev at lists.osgeo.org>, proj <proj at lists.osgeo.org>
Subject: Re: [PROJ] [gdal-dev] LIBERTIFF / Thread-safe TIFF reader

 

Hi,

 

The total size of the .tif files in my PROJ_DATA is 959 MB.  I tried the LERC compression with MAX_Z_ERROR values 0.001 and 0.01

for /f %i in ('dir /b *.tif') do (gdal_translate -of GTiff -co compress=lerc -co max_z_error=0.001 %i %i.lerc.tif)

z_error 0.001: 682 MB (-29%)

z_error 0.01: 549 MB (-43%)

 

The savings in space are real (though I think I could save 98 percent of space be deleting the grids which I never use). When it comes to compression/decompression, I think that a proper test where Proj is used for doing something real would be needed. Does Proj decompress the whole grid file, or just the tiles that it needs? How much time is used for opening the file and finding the tiles?

 

-Jukka Rahkonen-

 

 

Lähettäjä: gdal-dev <gdal-dev-bounces at lists.osgeo.org> Puolesta Howard Butler via gdal-dev
Lähetetty: sunnuntai 22. joulukuuta 2024 16.39
Vastaanottaja: Even Rouault <even.rouault at spatialys.com>
Kopio: gdal dev <gdal-dev at lists.osgeo.org>; proj <proj at lists.osgeo.org>
Aihe: Re: [gdal-dev] [PROJ] LIBERTIFF / Thread-safe TIFF reader

 

 

 

On Dec 20, 2024, at 4:56 PM, Even Rouault via gdal-dev <gdal-dev at lists.osgeo.org> wrote:

 

Besides reprocessing all of our existing grids,https://github.com/geotiffjs/geotiff.js/tree/master/src/compression seems to show that it doesn't support ZSTD, which would break at least our wonderful cdn.proj.orginteractive map

 

To throw a wrench into it... 

 

geotiff.js has LERC support. Floating point LERC TIFFs compressed with a MAX_Z_ERROR to one decimal better than the *stated precision* of the grids would be smaller and more efficiently compressed/decompressed. By maybe a 1/3rd over zstd and deflate.

 

See this great write-up by LINZ about the topic https://github.com/linz/elevation/tree/master/docs/tiff-compression 

 

Howard

_______________________________________________ PROJ mailing list PROJ at lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/proj 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20241222/08852e1f/attachment-0001.htm>