Even Rouault via gdal-dev <gdal-dev@lists.osgeo.org> writes:
> Now for the PROJ community only: my evil idea when coding it was that
> I could ""port"" a very subset of it to remove the libtiff depedency
> from PROJ. As we only uses Deflate compression, at least for grids we
> host on proj-data / the CDN, we could just switch our libtiff
> dependency to be just a libz/libdeflate one (can we just pick up
> libdeflate to simplify things - most libtiff builds nowadays already
> link to libdeflate - and get the x2 boost it gives over zlib. I guess
> we can). What do you think?
Without thinking too much:
You say '"port"' (in quotes), and I don't follow. The new
implementation is a library, even if it does not have a .so. So it
seems obvious that it would become a dependency of a particular gdal
driver and, of proj. If that means adding a feature for proj that
gdal doesn't need, and one codebase, that's fine and the normal
approach. If you mean "there are two live branches of libertiff",
that sounds like a bad idea.
It also seems that it could be vendored, but vendoring is not a good
thing, so if so it should be default-off (and hence fail) if not
present.
This doesn't read all tiff, and proj might be reading grid files that
the people who made them think are compliant, but that the new lib
won't read. Thus this is really a proposal to do two things:
- change the specification of proj to read only a limited subset of
tiff
- change to a simpler implementation that still meets that new
specification
That raises the question of whether the grid file spec is bigger than
proj, and how such a change would be viewed by others, or if this is
"there is a spec, but to use it with proj it has to meet narrower
spec-prime".
So modulo the "vendoring bad" issue, the big question on the table is
whether the proj community is ok with narrowing the grid file
specification, and whether there is some larger community behind that.
<dark_humor>Maybe take it to OGC</>
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
