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

[Sean Gillies]

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? GDAL is growing new
features rapidly and it doesn't seem that the old types have been a blocker
or huge friction for core developers.

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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20230920/58aaa7a7/attachment.htm>