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
