<div dir="ltr"><div>Kurt,</div><div><br></div><div>In the ideal world, everything has a unit test. In the real world, there are a lot of applications that keep things turning around that were not developed with the same level of care. And yet, we use them everyday. We have unit tests and a lot of them, but not everybody or everything does.<br></div><div><br></div><div>The RFC approval was voted by a number of developers that I don't believe represents the number of developers using GDAL as part of their applications. Perhaps breaking chances should require a more significant number of votes. <br></div><div><br></div><div>I dare to say that, if we are following this path, maybe GDAL should start marketing itself as a set of command line tools and not as a library, given that breaking compatibility just because we can is not something a library developer should do, IMHO.</div><div><br></div><div>Best,</div><div><br></div><div>hermann</div><div><br></div><div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>----------------------------------------------------------------------<br>Hermann Rodrigues<br><a href="mailto:hermann.rodrigues@gmail.com" target="_blank">hermann.rodrigues@gmail.com</a><br><a href="mailto:hermann@csr.ufmg.br" target="_blank">hermann@csr.ufmg.br</a><br><span style="font-size:12.8px">Twitter: @horodrigues | @dinamica_ego</span></div><div></div><div>Centro de Sensoriamento Remoto / UFMG<br><a href="https://csr.ufmg.br" target="_blank">https://csr.ufmg.br</a> | <a href="https://dinamicaego.com" target="_blank">https://dinamicaego.com</a></div></div></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 16, 2022 at 2:41 PM Kurt Schwehr <<a href="mailto:schwehr@gmail.com">schwehr@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hermann,<div><br></div><div>Speaking to GDAL being one (not very small) piece of an ecosystem of libraries and tools:</div><div><br></div><div>This is exactly what unit tests are for. A well done tool or library should have the tests that cover their critical uses of libraries they depend on. It's often referred to as the "Beyonce rule": "If you liked it, you should have put a test on it." (c.f. <a href="https://www.oreilly.com/library/view/software-engineering-at/9781492082781/ch01.html" target="_blank">here</a>)</div><div><br></div><div>Now is a great time to make sure that your workflow has a check for proper handling of 8-bit rasters.</div><div><br></div><div>-kurt</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 16, 2022 at 11:39 AM Even Rouault <<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>I think long term compatibility is a very desirable
feature, and several applications just use GDAL as part of
their code base without even being aware of what is
happening in the GDAL development front. The same is true
for several other libraries, given the fact the use of
package managers (VCPKG, conan etc) are becoming more
common. For some code bases, GDAL is just a small cog, and I
believe it is very easy for the developers to simply
download the next version from the package manager thinking
that they are getting mostly bug fixes and not being aware
of new silent incompatibilities.<br>
</div>
<br>
</div>
</div>
</blockquote>
We try to avoid breakage or silent breakage when reasonable, but
sometimes it is the best thing to do. People/software who depends on
the past functionality will see the tests related to their code
testing GetMetadataItem("PIXELTYPE", "IMAGE_STRUCTURE") ==
"SIGNEDBYTE" break and will probably figure out they should read
GDAL release notes to understand what happens. It is not the first
time nor the last one we will do that.<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>Sorry, but I think it is funny that you mention removing
GDT_Byte would have breaking implications, since I am
expressing my reservations against a change that will have
breaking implications. :) <br>
</div>
</div>
</div>
</blockquote>
My perception is that > 90% of current uses of GDT_Byte are for
the unsigned usage. Of course their might be some domains where this
is not the case.<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>I don't understand what limitations you are referring to.
Perhaps the support was broken to some types of raster
files?</div>
</div>
</div>
</blockquote>
This is described in the RFC: " the absence of a proper data type
means that it is easy
to forget to test the PIXELTYPE=SIGNEDBYTE metadata item in all
places where
the value of pixels is taken into account. There were special cases
for
statistics computations, but most of the other code, such as the
overview or
warping computation code had no provision for it, and consequently
mis-interpreted negative values in the range [-128,-1] as positive
values in
the range [128,255]." . So current support of signed 8-byte within
GDAL was broken in a number of places, and the new GDT_Int8 data
type enables to fix it. One could argue that the past behavior of
reporting a metadata item that altered the semantics of GDT_Byte was
a silent breakage of the API promise of GDT_Byte being unsigned.<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div> In my field, signed 8-bit images representing
categorical images are very common, given the fact they can
be used fully decompressed and represent a null value/nodata
in very convenient way (as a negative value).<br>
</div>
</div>
</div>
</blockquote>
<p>You should have a better experience with GDAL 3.7 then, pending
perhaps a few changes in your code.</p>
Even<br>
<pre cols="72">--
<a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</div>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div>
</blockquote></div>