OSGeo
Replace libtiff by vendored libertiff + external libdeflate
Cf thread at https://lists.osgeo.org/pipermail/proj/2024-December/011674.html
Not sure I'll follow up on this as there have been discussions about potentially using LERC. If we want to handle several codecs, libtiff is probably still the better choice, as from PROJ's point of view it is just one single find_package() whereas if we need to handle several codecs, that will be a find_package() per codec.
that will be a find_package() per codec.
LERC would not be a find_package. It would be vendored.
If geodetic grids were actually defined as definite-precision content, they wouldn't be delivered as floating points. I think it should be reasonable to provide LERC-compressed content to a stated MAX_Z_ERROR and garner the significant benefits from the LERC approach for floating point files. Otherwise, can the other mantissa-heads in the community tell us why we couldn't take this approach? 😄
The benefits that would be accumulated over the entire system multiplied by the substantial user base of PROJ – CDN usage, people downloading individual bytes, replicated storage on individual systems – would be a lot. LERC would mean smaller files that decompress faster. Can someone make the cogent case for bigger codecs that compress slower?
to a stated MAX_Z_ERROR
One difficulty is to find that value. For ASCII delivered grids, pending the pain of going back to the original sources, we can see it from the number of decimals in the file. For binary grids, that would be a guess.
LERC would not be a find_package. It would be vendored.
We'd still need a find_package() even if vendored (which I'm moderately enthusiast about, although not strongly opposed), because packagers won't accept using a vendored LERC when there's an external one available