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
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
