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. Nyall > 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 >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
