I've explored exposing GDALGeoTransform to the C API via an opaque handle, but the results are a net negative. All C functions which accept a double array geoTransform would need a `2` method for the new `GDALGeoTransformH` type, littering the API with almost useless duplicates. The one functionality which GDALGeoTransform currently has that I would like to access via the C API is the 2 apply methods that operate on OGREnvelope and GDALRasterWindow. I think it makes sense to move those implementations into new C functions: GDALApplyGeoTransformToWindow() and GDALApplyGeoTransformToEnvelope(). Then, expose GDALRasterWindow to the C API in the same way that OGREnvelope is exposed (by making it a struct if CPL_SUPRESS_CPLUSPLUS).
For the SWIG bindings, I'd like to do something similar to what Laurentiudid did in Rust: make GeoTransform an alias to an array of six doubles and add helper methods which duplicate the functionality of GDALGeoTransform methods. Thank you all for the input, Michael On Tue, Sep 1, 2026 at 11:28 PM Chris Toney <[email protected]> wrote: > 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 > -- Michael Bucari
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
