[gdal-dev] Call for discussion/review of RFC95: Use standard C/C++ integer types

[Even Rouault]

Hi Even,
>
> 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?
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).
>
> 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.
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:

- https://github.com/MapServer/MapServer/pull/6936 : minimal change is 
just to define GDAL_USE_OLD_INT_TYPES

- https://github.com/PDAL/PDAL/pull/4179 : minimal change is just to 
define GDAL_USE_OLD_INT_TYPES

- https://github.com/qgis/QGIS/pull/54680: 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

So nothing dramatic. Hopefully rasterio or fiona wouldn't be too 
troublesome to adapt

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

Do you have something in mind about a tangibly better improvement to the 
API that would make it worth a 4.0?

Even


>
> On Tue, Sep 19, 2023 at 10:30 AM Even Rouault 
> <even.rouault at spatialys.com> wrote:
>
>     No other reaction ? Are people comfortable with bumping to 4.0 ?
>     If so,
>     no opinion on what we should slip in while we are it (thinking more
>     about breaking changes than new features, which generally can be
>     added
>     afterwards) ?
>
>     Le 16/09/2023 à 14:53, Even Rouault a écrit :
>     >
>     >> About GDAL 4.0 vs 3.8, I'm fine with 4.0. But I do not know if
>     >> "users" will expect a bigger change in functionalities for a mayor
>     >> release update.
>     >
>     > Yes, there are a few other tickets flagged as appropriate for 4.0:
>     > https://github.com/OSGeo/gdal/milestone/33
>     >
>     > All of them could probably be implemented without making the
>     3.8/4.0
>     > schedule drift. The exportToWKT with WKT2 as default would involve
>     > some work in GDAL drivers, given that some of them are dependent on
>     > WKT1, but hopefully nothing that cannot be overcome. The main
>     impact
>     > would probably be on the autotest suite (fast resolution would be
>     > similar to drivers, and replace all exportToWKT() with
>     > exportToWKT(["FORMAT=WKT1"]), and possibly switch progressively
>     to WKT2)
>     >
>     > Other topics that could/should be split for a 4.0 ?
>     >
>     > Thinking about CRS stuff, currently gdaltransform operates with the
>     > GIS friendly axis order, which is at odds with the fact that
>     > OGRSpatialReference default and PROJ's cs2cs which use the
>     authority
>     > compliant axis order since PROJ 6.0 / GDAL 3.0. Not sure if we'd
>     want
>     > to make gdaltransform follow cs2cs (possibly with a
>     > --axis-order=gis_friendly/authority_compliant explicit flag)
>     >
>     > Maybe some 'Ex' (which stands for API) functions in the C API
>     could be
>     > removed and their extra/modified arguments reincorporated with the
>     > original non-Ex function. Would totally make sense for the few ones
>     > impacted by RFC95 like GDALGetDefaultHistogramEx,
>     > GDALSetDefaultHistogramEx, GDALGetRasterHistogramEx
>     >
>     > There might be also some defaults (open, creation options) that
>     could
>     > be changed, although nothing immediately jumps to mind
>     >
>     > Even
>     >
>     >
>
>
>
> -- 
> Sean Gillies

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20230920/d64f9af9/attachment-0001.htm>