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

[Sean Gillies]

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.

On Wed, Sep 20, 2023 at 11:23 AM Even Rouault <even.rouault at spatialys.com>
wrote:

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