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

[Even Rouault]

> 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


-- 
http://www.spatialys.com
My software is free, but my time generally not.