Hi, The `gdalraster` R bindings are also written manually. They implement a ~thin layer of abstraction over the raster and vector object models, provided as a class-based interface. These are implemented as C++ classes directly exposed to R. There is additionally a large number of stand-alone functions for utils, VSI file system, etc., including geotransform conversions and invert. We primarily use the C API but there a few exceptions where C++ API is used, i.e., we're not constrained to C API. It is more of a personal preference, and historical habit likely motivated by ABI compatibility originally. I don't expect we would bind a C API for GDALGeoTransform.
Thanks. Chris On Tue, Sep 1, 2026 at 12:31 PM Laurențiu Nicola via gdal-dev <[email protected]> wrote: > > Hi Even, > > Speaking for the Rust bindings, they have two parts: one is automatically > generated by parsing the header and includes almost everything (macros, > inline function etc. will be problematic), and one is C++-ish, written > manually, and woefully behind the GDAL functionality. Users can switch > between them as needed. > > Specifically for GeoTransform, we expose e.g. GDALApplyGeoTransform in the > low-level bindings, and GeoTransform is an alias to an array of six floats in > the high-level ones, with extra apply and invert methods somewhat hidden > behind an import, which call the C functions. IsAxisAligned seems to be > missing from both. > > Now if SWIG could generate the high-level APIs, that would save a lot of work > and especially bikeshedding, but I don't see it happening, so you don't need > to worry about it. > > Laurentiu > > On Tue, Sep 1, 2026, at 21:02, Even Rouault via gdal-dev wrote: > > Michael, > > This is likely a design decision from 20 years ago when the "new" bindings > have been added. I wasn't involved, but I can imagine at least 2 reasons to > prefer binding C functions rather than C++ classes: > > - make sure that the bindings generated against GDAL X still run against > libgdal Y where Y >= X without being rebuilt, since the C ABI is backwards > compatible. But that doesn't seem to be a very realistic/common scenario > > - avoid exposing to SWIG things that haven't been considered stable enough to > be exposed to C > > Maybe other GDAL users, such as people doing Rust or R bindings, could give > us some hints if they'd be interested in binding the GDALGeoTransform class > to their language. If so, making C bindings would serve everybody. > > Even > > Le 31/08/2026 à 21:50, Michael via gdal-dev a écrit : > > I want to expose the GDALGeoTransform class. It doesn't have a C struct > representation (like OGREnvelope) or an opaque C handle type. I could add C > interfaces to GDALGeoTransfor, but that seems absurd since GDALGeoTransfor > is mostly a C++ wrapper of the C routines. > > However, using the GDALGeoTransfor class directly from the SWIG interfaces > works surprisingly well (See below). What doesn't work is the 'Apply' > overloads which accept a `GDALRasterWindow` type, because SWIG can't include > gdal_rasterband.h while CPL_SUPRESS_CPLUSPLUS is defined. > > So my questions are: can I use the GDALGeoTransfor c++ class directly from > SWIG and, if not, why? > ------------- > > %{ > #include "gdal_geotransform.h" > %} > > class GDALGeoTransform { > private: > const double *data() const; > ~GDALGeoTransform(); > public: > %mutable; > GDALGeoTransform(); > GDALGeoTransform(const double coeffs[6]); > GDALGeoTransform(double xorigIn, double xscaleIn, double xrotIn, double > yorigIn, double yrotIn, double yscaleIn); > void Rescale(double dfXRatio, double dfYRatio); > %immutable; > void Apply(double dfPixel, double dfLine, double *pdfGeoX, double *pdfGeoY) > const; > bool GetInverse(GDALGeoTransform &inverse) const; > bool IsAxisAligned() const; > }; > > -- > Michael Bucari > > _______________________________________________ > gdal-dev mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/gdal-dev > > -- > http://www.spatialys.com > My software is free, but my time generally not. > LLMs contribute to global warming and brain rot. > Let's guillotine them! "Ah ! ça ira, ça ira, ça ira !" > > _______________________________________________ > gdal-dev mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/gdal-dev > > > _______________________________________________ > gdal-dev mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/gdal-dev _______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
