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-boun...@lists.osgeo.org> Puolesta Howard Butler
via gdal-dev
Lähetetty: sunnuntai 22. joulukuuta 2024 16.39
Vastaanottaja: Even Rouault <even.roua...@spatialys.com>
Kopio: gdal dev <gdal-dev@lists.osgeo.org>; proj <p...@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@lists.osgeo.org<mailto:gdal-dev@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.org<http://cdn.proj.org/>interactive 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
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
