-
Notifications
You must be signed in to change notification settings - Fork 802
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace libtiff by vendored libertiff + external libdeflate #4358
Comments
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. |
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 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? |
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. |
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 |
Cf thread at https://lists.osgeo.org/pipermail/proj/2024-December/011674.html
The text was updated successfully, but these errors were encountered: