<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>