<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<span style="white-space: pre-wrap">
</span>
<blockquote type="cite" cite="mid:rmibjx7li0z.fsf@s1.lexort.com">
<pre class="moz-quote-pre" wrap="">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.</pre>
</blockquote>
No, vendor libertiff.hpp into PROJ as already done in GDAL. If
someone wants to package libertiff as a standalone package, fine for
them, but we're probably not at that point of success that we need
to do it. I'm happy to resync libertiff_upstream/GDAL/PROJ
libertiff.hpp when needed. Given its limited scope, it is probably
close to be feature complete.<br>
<blockquote type="cite" cite="mid:rmibjx7li0z.fsf@s1.lexort.com">
<pre class="moz-quote-pre" wrap="">
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.</pre>
</blockquote>
Yep, that's the main restriction. So this is a question for the
community: does anyone use PROJ TIFF grids with a codec that is not
uncompressed or deflate ?<br>
<blockquote type="cite" cite="mid:rmibjx7li0z.fsf@s1.lexort.com">
<pre class="moz-quote-pre" wrap=""> 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".</pre>
</blockquote>
Yes the deal would be: you can use any valid (Geo)TIFF/(Geo)BigTIFF
big/little endian ordered, provided you limit yourself to
uncompressed or deflate.<br>
<blockquote type="cite" cite="mid:rmibjx7li0z.fsf@s1.lexort.com">
<pre class="moz-quote-pre" wrap="">
<dark_humor>Maybe take it to OGC</></pre>
</blockquote>
Fortunately, there's nothing geo in this!<span
style="white-space: pre-wrap">
</span>
<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.
Butcher of all kinds of standards, open or closed formats. At the end, this is just about bytes.
Mood of the day: "Bien entendu, on peut sauter sur sa chaise comme un cabri en disant : les standards ! les standards ! les standards ! Mais ça n’aboutit à rien et ça ne signifie rien." ~ dixit De Gaulle</pre>
</body>
</html>