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.roua...@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.roua...@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
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
