<!DOCTYPE html><html><head><title></title></head><body><div style="font-family:Arial;">Hi Even,</div><div style="font-family:Arial;"><br></div><div style="font-family:Arial;">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.</div><div style="font-family:Arial;"><br></div><div style="font-family:Arial;">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.</div><div style="font-family:Arial;"><br></div><div style="font-family:Arial;">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.</div><div style="font-family:Arial;"><br></div><div style="font-family:Arial;">Laurentiu</div><div style="font-family:Arial;"><br></div><div>On Tue, Sep 1, 2026, at 21:02, Even Rouault via gdal-dev wrote:</div><blockquote type="cite" id="qt" style=""><p>Michael,</p><p>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:</p><p>- 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</p><p>- avoid exposing to SWIG things that haven't been considered
stable enough to be exposed to C</p><p>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.</p><p>Even</p><div class="qt-moz-cite-prefix">Le 31/08/2026 à 21:50, Michael via
gdal-dev a écrit :</div><blockquote type="cite" cite="mid:CACKw9A9nQukYtXqKMAVjVirH7iT1A3YL4=CX4KDjPUt5Xu7cUg@mail.gmail.com"><div dir="ltr"><div dir="ltr"><div>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.</div><div><br></div><div>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.</div><div><br></div><div>So my questions are: can I use the GDALGeoTransfor c++
class directly from SWIG and, if not, why?</div><div>-------------</div><div><br></div><div><div>%{</div><div> #include "gdal_geotransform.h"</div><div> %}</div></div><div><div><br></div><div>class GDALGeoTransform {</div><div> private:</div><div> const double *data() const;</div><div> ~GDALGeoTransform();</div><div> public:</div><div> %mutable;</div><div> GDALGeoTransform();</div><div> GDALGeoTransform(const double coeffs[6]);</div><div> GDALGeoTransform(double xorigIn, double xscaleIn, double
xrotIn, double yorigIn, double yrotIn, double yscaleIn);</div><div> void Rescale(double dfXRatio, double dfYRatio);</div><div> %immutable;</div><div> void Apply(double dfPixel, double dfLine, double *pdfGeoX,
double *pdfGeoY) const;</div><div> bool GetInverse(GDALGeoTransform &inverse) const;</div><div> bool IsAxisAligned() const;</div><div> };</div></div><div><br></div><div><span class="qt-gmail_signature_prefix">--</span></div><div dir="ltr" class="qt-gmail_signature">Michael Bucari</div></div></div><div><br></div><pre class="qt-moz-quote-pre">_______________________________________________
gdal-dev mailing list
<a class="qt-moz-txt-link-abbreviated" href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>
<a class="qt-moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/gdal-dev">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a>
</pre></blockquote><pre class="qt-moz-signature" cols="72">--
<a class="qt-moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
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 !"</pre><div>_______________________________________________</div><div>gdal-dev mailing list</div><div><a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a></div><div><a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a></div><div><br></div></blockquote><div style="font-family:Arial;"><br></div></body></html>