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