<div dir="ltr"><div>I've asked before about making GDAL's error propagation system better. That's one thing I'd like to add to a list of proposed changes for 4.0. Could we have a separate call for 4.0 ideas and review it next month (or later)? I'm so busy with a running project and looking for a new job that I don't have as much time for open source project roadmapping as I did a few weeks ago.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 20, 2023 at 11:23 AM Even Rouault <<a href="mailto:even.rouault@spatialys.com">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>
Hi Even,
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>I'm in favor of overhauling the types in the next major
version. However, I'm not convinced we need to jump
immediately to 4.0. The current situation isn't ideal, but
isn't holding us back very much right?</div>
</div>
</blockquote>
No, there's no urgency. It is just one of the many continuous rather
boring improvements we do in the code base, except that one is
noticed externally. My pain concern about defering is that the
candidate implementation will rot quickly, and the manual parts are
painful to redo (but nothing dramatic: a few hours of effort, not
weeks).<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Speaking for Fiona and Rasterio, supporting GDAL versions
3.5-3.7 and 4.0 at the same time will be a pain and will
require some conditional compilation changes throughout the
code. These projects will need some time to prepare. </div>
</div>
</blockquote>
I've experimented a bit about trying the RFC 95 branch to build
mapserver, PDAL and QGIS against it and being compatible with older
GDAL versions as well:
<p>- <a href="https://github.com/MapServer/MapServer/pull/6936" target="_blank">https://github.com/MapServer/MapServer/pull/6936</a> : minimal
change is just to define GDAL_USE_OLD_INT_TYPES</p>
<p>- <a href="https://github.com/PDAL/PDAL/pull/4179" target="_blank">https://github.com/PDAL/PDAL/pull/4179</a> : minimal change is just
to define GDAL_USE_OLD_INT_TYPES</p>
<p>- <a href="https://github.com/qgis/QGIS/pull/54680" target="_blank">https://github.com/qgis/QGIS/pull/54680</a>: set
GDAL_USE_OLD_INT_TYPES, a few if GDAL >= 4.0 branches and a few
other changes that make it work with all GDAL versions<br>
</p>
<p>So nothing dramatic. Hopefully rasterio or fiona wouldn't be too
troublesome to adapt<br>
</p>
<blockquote type="cite">
<div dir="ltr">
<div>And I'd be more enthusiastic about supporting 3.7 and 4.0
simultaneously if 4.0 made GDAL's C API tangibly better, like
dataset unification in 2.0 or the PROJ switch in 3.0.<br>
</div>
</div>
</blockquote>
<p>Do you have something in mind about a tangibly better improvement
to the API that would make it worth a 4.0?<br>
</p>
<p>Even<br>
</p>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Sep 19, 2023 at
10:30 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">No other reaction ? Are
people comfortable with bumping to 4.0 ? If so, <br>
no opinion on what we should slip in while we are it
(thinking more <br>
about breaking changes than new features, which generally
can be added <br>
afterwards) ?<br>
<br>
Le 16/09/2023 à 14:53, Even Rouault a écrit :<br>
><br>
>> About GDAL 4.0 vs 3.8, I'm fine with 4.0. But I do
not know if <br>
>> "users" will expect a bigger change in
functionalities for a mayor <br>
>> release update.<br>
><br>
> Yes, there are a few other tickets flagged as
appropriate for 4.0: <br>
> <a href="https://github.com/OSGeo/gdal/milestone/33" rel="noreferrer" target="_blank">https://github.com/OSGeo/gdal/milestone/33</a><br>
><br>
> All of them could probably be implemented without
making the 3.8/4.0 <br>
> schedule drift. The exportToWKT with WKT2 as default
would involve <br>
> some work in GDAL drivers, given that some of them are
dependent on <br>
> WKT1, but hopefully nothing that cannot be overcome.
The main impact <br>
> would probably be on the autotest suite (fast
resolution would be <br>
> similar to drivers, and replace all exportToWKT() with
<br>
> exportToWKT(["FORMAT=WKT1"]), and possibly switch
progressively to WKT2)<br>
><br>
> Other topics that could/should be split for a 4.0 ?<br>
><br>
> Thinking about CRS stuff, currently gdaltransform
operates with the <br>
> GIS friendly axis order, which is at odds with the fact
that <br>
> OGRSpatialReference default and PROJ's cs2cs which use
the authority <br>
> compliant axis order since PROJ 6.0 / GDAL 3.0. Not
sure if we'd want <br>
> to make gdaltransform follow cs2cs (possibly with a <br>
> --axis-order=gis_friendly/authority_compliant explicit
flag)<br>
><br>
> Maybe some 'Ex' (which stands for API) functions in the
C API could be <br>
> removed and their extra/modified arguments
reincorporated with the <br>
> original non-Ex function. Would totally make sense for
the few ones <br>
> impacted by RFC95 like GDALGetDefaultHistogramEx, <br>
> GDALSetDefaultHistogramEx, GDALGetRasterHistogramEx<br>
><br>
> There might be also some defaults (open, creation
options) that could <br>
> be changed, although nothing immediately jumps to mind<br>
><br>
> Even<br>
><br>
><br>
</blockquote>
</div>
</div></blockquote></div>
</blockquote></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Sean Gillies</div></div>