<div dir="ltr"><div>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).</div><div><br></div><div>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.</div><div><br></div><div>Thank you all for the input,</div><div>Michael</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, Sep 1, 2026 at 11:28 PM Chris Toney <<a href="mailto:jctoney@gmail.com">jctoney@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
The `gdalraster` R bindings are also written manually. They implement<br>
a ~thin layer of abstraction over the raster and vector object models,<br>
provided as a class-based interface. These are implemented as C++<br>
classes directly exposed to R. There is additionally a large number of<br>
stand-alone functions for utils, VSI file system, etc., including<br>
geotransform conversions and invert. We primarily use the C API but<br>
there a few exceptions where C++ API is used, i.e., we're not<br>
constrained to C API. It is more of a personal preference, and<br>
historical habit likely motivated by ABI compatibility originally. I<br>
don't expect we would bind a C API for GDALGeoTransform.<br>
<br>
Thanks.<br>
<br>
Chris<br>
<br>
On Tue, Sep 1, 2026 at 12:31 PM Laurențiu Nicola via gdal-dev<br>
<<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a>> wrote:<br>
><br>
> Hi Even,<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> Laurentiu<br>
><br>
> On Tue, Sep 1, 2026, at 21:02, Even Rouault via gdal-dev wrote:<br>
><br>
> Michael,<br>
><br>
> 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:<br>
><br>
> - 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<br>
><br>
> - avoid exposing to SWIG things that haven't been considered stable enough to be exposed to C<br>
><br>
> 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.<br>
><br>
> Even<br>
><br>
> Le 31/08/2026 à 21:50, Michael via gdal-dev a écrit :<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> So my questions are: can I use the GDALGeoTransfor c++ class directly from SWIG and, if not, why?<br>
> -------------<br>
><br>
> %{<br>
> #include "gdal_geotransform.h"<br>
> %}<br>
><br>
> class GDALGeoTransform {<br>
> private:<br>
>   const double *data() const;<br>
>   ~GDALGeoTransform();<br>
> public:<br>
> %mutable;<br>
>   GDALGeoTransform();<br>
>   GDALGeoTransform(const double coeffs[6]);<br>
>   GDALGeoTransform(double xorigIn, double xscaleIn, double xrotIn, double yorigIn, double yrotIn, double yscaleIn);<br>
>   void Rescale(double dfXRatio, double dfYRatio);<br>
> %immutable;<br>
>   void Apply(double dfPixel, double dfLine, double *pdfGeoX, double *pdfGeoY) const;<br>
>   bool GetInverse(GDALGeoTransform &inverse) const;<br>
>   bool IsAxisAligned() const;<br>
> };<br>
><br>
> --<br>
> Michael Bucari<br>
><br>
> _______________________________________________<br>
> gdal-dev mailing list<br>
> <a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
> <a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
><br>
> --<br>
> <a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
> My software is free, but my time generally not.<br>
> LLMs contribute to global warming and brain rot.<br>
> Let's guillotine them! "Ah ! ça ira, ça ira, ça ira !"<br>
><br>
> _______________________________________________<br>
> gdal-dev mailing list<br>
> <a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
> <a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> gdal-dev mailing list<br>
> <a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
> <a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div><div><br clear="all"></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Michael Bucari</div>