Le 29/12/2023 à 22:10, Nyall Dawson a écrit :
On Sat, 16 Dec 2023, 1:03 am Even Rouault via gdal-dev,
<gdal-dev@lists.osgeo.org> wrote:
Le 15/12/2023 à 15:49, Sebastiaan Couwenberg via gdal-dev a écrit :
> On 12/15/23 15:35, Even Rouault via gdal-dev wrote:
>> Thoughts ? (given the length of the email, it should probably be
>> formalized as a RFC. I'll do that, unless there is a massive
uprising
>> against the proposal...)
>
> LERC doesn't support big endian architectures currently, only using
> that on little endian architectures using the internal copy
currently
> works as expected. Using the external library would require
> conditionals in the packaging which I'm not in favor of.
Bas,
- The Debian libtiff package already handles that conditional, so
there
must certainly be a way of using the same trick for the GDAL build
recipee
- The only user of LERC in GDAL (except for its libtiff internal
cpoy)
is the MRF driver. I doubt MRF is used widely except in Esri data
centers... So even if you don't want to change the GDAL build
recipee to
include a conditional liblerc dependency, that wouldn't be the end of
the world.
Some ESRI image server layers are served up using lerc compression, eg
the landcover tiles:
https://tiledimageservices.arcgis.com/P3ePLMYs2RVChkJx/arcgis/rest/services/Esri_2020_Land_Cover_V2/ImageServer?f=pjson
I was planning on doing some future work in qgis to support reading
these layers by using gdal to do the lerc decompression, so I'd be
disappointed if the lerc compression support is dropped.
Hi Nyall,
Interesting. Digging a bit more, I now see that the MRF driver can open
Lerc blobs too (independently of the MRF extra stuff), so that can
potentially be a way to get Lerc decompression working. And actually
there's is a test in the WMS driver that uses MRF/LERC
(https://github.com/OSGeo/gdal/blob/master/autotest/gdrivers/wms.py#L872)
which might be just what you need.
It would be nice if the GDAL Debian package could link liblerc in the
future.
Even
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
