<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">Le 29/12/2023 à 22:10, Nyall Dawson a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CAB28Asih0Hj_Eap_k2LK+_K86rAu5erOPCAuPEqr6MYPAOkD3g@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">
<div><br>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sat, 16 Dec 2023,
1:03 am Even Rouault via gdal-dev, <<a
href="mailto:gdal-dev@lists.osgeo.org" target="_blank"
rel="noreferrer" moz-do-not-send="true"
class="moz-txt-link-freetext">gdal-dev@lists.osgeo.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Le 15/12/2023 à 15:49, Sebastiaan Couwenberg via gdal-dev
a écrit :<br>
> On 12/15/23 15:35, Even Rouault via gdal-dev wrote:<br>
>> Thoughts ? (given the length of the email, it
should probably be <br>
>> formalized as a RFC. I'll do that, unless there
is a massive uprising <br>
>> against the proposal...)<br>
><br>
> LERC doesn't support big endian architectures
currently, only using <br>
> that on little endian architectures using the
internal copy currently <br>
> works as expected. Using the external library would
require <br>
> conditionals in the packaging which I'm not in favor
of.<br>
Bas,<br>
<br>
- The Debian libtiff package already handles that
conditional, so there <br>
must certainly be a way of using the same trick for the
GDAL build recipee<br>
<br>
- The only user of LERC in GDAL (except for its libtiff
internal cpoy) <br>
is the MRF driver. I doubt MRF is used widely except in
Esri data <br>
centers... So even if you don't want to change the GDAL
build recipee to <br>
include a conditional liblerc dependency, that wouldn't be
the end of <br>
the world.<br>
</blockquote>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">Some ESRI image server layers are served up
using lerc compression, eg the landcover tiles:</div>
<div dir="auto"><br>
</div>
<div dir="auto"><a
href="https://tiledimageservices.arcgis.com/P3ePLMYs2RVChkJx/arcgis/rest/services/Esri_2020_Land_Cover_V2/ImageServer?f=pjson"
moz-do-not-send="true" class="moz-txt-link-freetext">https://tiledimageservices.arcgis.com/P3ePLMYs2RVChkJx/arcgis/rest/services/Esri_2020_Land_Cover_V2/ImageServer?f=pjson</a></div>
<div dir="auto"><br>
</div>
<div dir="auto">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. <br>
</div>
</div>
</blockquote>
<p>Hi Nyall,</p>
<p>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
(<a class="moz-txt-link-freetext" href="https://github.com/OSGeo/gdal/blob/master/autotest/gdrivers/wms.py#L872">https://github.com/OSGeo/gdal/blob/master/autotest/gdrivers/wms.py#L872</a>)
which might be just what you need.<br>
</p>
<p>It would be nice if the GDAL Debian package could link liblerc in
the future.<br>
</p>
<p>Even</p>
<br>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</body>
</html>