From robin at rtwilson.com  Tue Sep  1 06:33:08 2026
From: robin at rtwilson.com (Robin Wilson)
Date: Tue, 1 Sep 2026 14:33:08 +0100
Subject: [gdal-dev] Indexing lots of remote COGs for use with gdal raster
 clip and QGIS
Message-ID: <etPan.6a96d414.5807ef01.db5b@rtwilson.com>

Hi,

I have a lot of COGs hosted online in HTTP RANGE compatible storage. I want to create a catalog/index of them so that GDAL and tools that use GDAL (like QGIS) can extract the relevant data from the COGs for specific areas. For example, I?d like to use `gdal raster clip` to clip this big ?virtual raster? to a specific bbox or polygon. Ideally I?d also like to be able to view the big raster on-the-fly in QGIS, but I?m aware that may be more difficult. My tiles are ?true tiles? in that they tessellate properly and each location is in a single file.

I?ve been looking at the GDAL Tile Index format, but have been getting a bit confused, and some things haven?t been working quite how I expect. A few questions below:

1. Is there an easy way to generate a GDAL Tile Index file from a file containing a list of remote URLs? I couldn?t find the right way to specify a file containing URLs on the command line, so I ended up writing a short Python script that loads the list of URLs from a file and then passes them to?gdal.TileIndex. Is that the best way to do this? One disadvantage of this method is that I can?t seem to get a progress bar to display.

2. My current way of doing that requires GDAL loading the bbox of each file by requesting it over the network, which is fairly slow, and I have thousands of files to do this for. Is there a way to get the GTI creation to use local files on my hard disk for getting the extent of each file, but save the location as a /vsicurl/ URL to the remote file? I?ve found --base-url in `gdal raster index` though I?m slightly confused by the description of it ("Base URL for STAC-GeoParquet the href property of the id property in a STAC-GeoParquet index.? - does that do what I want and put a base URL in front of each file it finds?). That option doesn?t seem to be present in `gdal driver gti create` though, and seems like it may be STAC-GeoParquet specific.

3. Once I?ve created the file, I can do `gdal raster clip` operations on the command-line quite quickly, but if I load the GTI raster into QGIS then QGIS just hangs. I hoped it would just request the relevant COGs for the area I was looking at. I?ve tried loading it in by dragging and dropping the .gti.gpkg file and then selecting the raster in the layers popup, and also adding it via Add Layer->Raster and putting ?GTI:<path>?. I have a web map working which loads these COG files on the fly depending on where you?re looking (using a minimal STAC catalog in a JSON file) and was hoping to have the same thing working in QGIS, without the effort of setting up something like titiler or titiler-pgstac, as I?m currently managing to get away without running any servers ?(as opposed to static data stores) for this data.

If there?s an alternative method I should be looking at for doing either part of this (the clipping or the viewing in QGIS) then let me know - I?m aware I may be pushing the boundaries of what can be sensibly done with the GTI format.

Best regards,

Robin


Dr Robin Wilson

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260901/57f99fbd/attachment-0001.htm>

From public at postholer.com  Tue Sep  1 10:07:56 2026
From: public at postholer.com (Scott)
Date: Tue, 1 Sep 2026 10:07:56 -0700
Subject: [gdal-dev] Indexing lots of remote COGs for use with gdal
 raster clip and QGIS
In-Reply-To: <etPan.6a96d414.5807ef01.db5b@rtwilson.com>
References: <etPan.6a96d414.5807ef01.db5b@rtwilson.com>
Message-ID: <e3bc1063-fb4d-4459-b012-aa0bef9e3df4@postholer.com>

Hey Robin,

I would look into the GTI raster driver:
https://gdal.org/en/latest/programs/gdal_driver_gti_create.html#gdal-driver-gti-create

It creates a GPKG index of rasters for efficient access. Creating a GTI:

gdal driver gti create --resolution .0029,.0029 --output-layer dem30 
ned10/cogs cogs.gti.gpkg

Using the new index:
gdal raster clip -i cogs.gti.gpkg --bbox -111,36,-110,37 --of COG -o 
newCog.tif

QGIS will read the index as a vector file (since it's GPKG) displaying 
bounding boxes for each raster in the index, but not as a raster as a whole.

Hope that helps!


On 9/1/26 06:33, Robin Wilson via gdal-dev wrote:
> Hi,
> 
> I have a lot of COGs hosted online in HTTP RANGE compatible storage. I 
> want to create a catalog/index of them so that GDAL and tools that use 
> GDAL (like QGIS) can extract the relevant data from the COGs for 
> specific areas. For example, I?d like to use `gdal raster clip` to clip 
> this big ?virtual raster? to a specific bbox or polygon. Ideally I?d 
> also like to be able to view the big raster on-the-fly in QGIS, but I?m 
> aware that may be more difficult. My tiles are ?true tiles? in that they 
> tessellate properly and each location is in a single file.
> 
> I?ve been looking at the GDAL Tile Index format, but have been getting a 
> bit confused, and some things haven?t been working quite how I expect. A 
> few questions below:
> 
> 1. Is there an easy way to generate a GDAL Tile Index file from a file 
> containing a list of remote URLs? I couldn?t find the right way to 
> specify a file containing URLs on the command line, so I ended up 
> writing a short Python script that loads the list of URLs from a file 
> and then passes them to?gdal.TileIndex. Is that the best way to do this? 
> One disadvantage of this method is that I can?t seem to get a progress 
> bar to display.
> 
> 2. My current way of doing that requires GDAL loading the bbox of each 
> file by requesting it over the network, which is fairly slow, and I have 
> thousands of files to do this for. Is there a way to get the GTI 
> creation to use local files on my hard disk for getting the extent of 
> each file, but save the location as a /vsicurl/ URL to the remote file? 
> I?ve found --base-url in `gdal raster index` though I?m slightly 
> confused by the description of it ("Base URL for STAC-GeoParquet the 
> href property of the id property in a STAC-GeoParquet index.? - does 
> that do what I want and put a base URL in front of each file it finds?). 
> That option doesn?t seem to be present in `gdal driver gti create` 
> though, and seems like it may be STAC-GeoParquet specific.
> 
> 3. Once I?ve created the file, I can do `gdal raster clip` operations on 
> the command-line quite quickly, but if I load the GTI raster into QGIS 
> then QGIS just hangs. I hoped it would just request the relevant COGs 
> for the area I was looking at. I?ve tried loading it in by dragging and 
> dropping the .gti.gpkg file and then selecting the raster in the layers 
> popup, and also adding it via Add Layer->Raster and putting 
> ?GTI:<path>?. I have a web map working which loads these COG files on 
> the fly depending on where you?re looking (using a minimal STAC catalog 
> in a JSON file) and was hoping to have the same thing working in QGIS, 
> without the effort of setting up something like titiler or titiler- 
> pgstac, as I?m currently managing to get away without running any 
> servers ?(as opposed to static data stores) for this data.
> 
> If there?s an alternative method I should be looking at for doing either 
> part of this (the clipping or the viewing in QGIS) then let me know - 
> I?m aware I may be pushing the boundaries of what can be sensibly done 
> with the GTI format.
> 
> Best regards,
> 
> Robin
> 
> 
> Dr Robin Wilson
> 
> 
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev


From even.rouault at spatialys.com  Tue Sep  1 10:49:23 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Tue, 1 Sep 2026 19:49:23 +0200
Subject: [gdal-dev] Indexing lots of remote COGs for use with gdal
 raster clip and QGIS
In-Reply-To: <etPan.6a96d414.5807ef01.db5b@rtwilson.com>
References: <etPan.6a96d414.5807ef01.db5b@rtwilson.com>
Message-ID: <c363de0f-cf5c-4c82-9e14-144e568fbb07@spatialys.com>


Le 01/09/2026 ? 15:33, Robin Wilson via gdal-dev a ?crit?:
> Hi,
>
> I have a lot of COGs hosted online in HTTP RANGE compatible storage. I 
> want to create a catalog/index of them so that GDAL and tools that use 
> GDAL (like QGIS) can extract the relevant data from the COGs for 
> specific areas. For example, I?d like to use `gdal raster clip` to 
> clip this big ?virtual raster? to a specific bbox or polygon. Ideally 
> I?d also like to be able to view the big raster on-the-fly in QGIS, 
> but I?m aware that may be more difficult. My tiles are ?true tiles? in 
> that they tessellate properly and each location is in a single file.
>
> I?ve been looking at the GDAL Tile Index format, but have been getting 
> a bit confused, and some things haven?t been working quite how I 
> expect. A few questions below:
>
> 1. Is there an easy way to generate a GDAL Tile Index file from a file 
> containing a list of remote URLs? I couldn?t find the right way to 
> specify a file containing URLs on the command line, so I ended up 
> writing a short Python script that loads the list of URLs from a file 
> and then passes them to?gdal.TileIndex. Is that the best way to do 
> this? One disadvantage of this method is that I can?t seem to get a 
> progress bar to display.

see 
https://github.com/OSGeo/gdal/blob/master/autotest/utilities/test_gdalalg_driver_gti_create.py 
. The input argument can be a list of paths, local or remote (/vsis3/ etc)

you can use gdal.alg.vsi.list to get a list of remove /vsis3/ files

>
> 2. My current way of doing that requires GDAL loading the bbox of each 
> file by requesting it over the network, which is fairly slow, and I 
> have thousands of files to do this for. Is there a way to get the GTI 
> creation to use local files on my hard disk for getting the extent of 
> each file, but save the location as a /vsicurl/ URL to the remote file?
Not directly, but if you save in a .gpkg your GTI index, you can easily 
patch the 'location' field from local paths to remote URLs
>
> 3. Once I?ve created the file, I can do `gdal raster clip` operations 
> on the command-line quite quickly, but if I load the GTI raster into 
> QGIS then QGIS just hangs. I hoped it would just request the relevant 
> COGs for the area I was looking at. I?ve tried loading it in by 
> dragging and dropping the .gti.gpkg file and then selecting the raster 
> in the layers popup, and also adding it via Add Layer->Raster and 
> putting ?GTI:<path>?. I have a web map working which loads these COG 
> files on the fly depending on where you?re looking (using a minimal 
> STAC catalog in a JSON file) and was hoping to have the same thing 
> working in QGIS, without the effort of setting up something like 
> titiler or titiler-pgstac, as I?m currently managing to get away 
> without running any servers ?(as opposed to static data stores) for 
> this data.

QGIS will try to gather statistics, hence this can be slow. One way to 
speed up is to have overviews defined in the GTI.


-- 
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 !"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260901/7ae4e1e7/attachment.htm>

From even.rouault at spatialys.com  Tue Sep  1 11:02:08 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Tue, 1 Sep 2026 20:02:08 +0200
Subject: [gdal-dev] Can c++ types be used directly from the SWIG
 interfaces?
In-Reply-To: <CACKw9A9nQukYtXqKMAVjVirH7iT1A3YL4=CX4KDjPUt5Xu7cUg@mail.gmail.com>
References: <CACKw9A9nQukYtXqKMAVjVirH7iT1A3YL4=CX4KDjPUt5Xu7cUg@mail.gmail.com>
Message-ID: <60b51518-b361-4339-9982-b09bf3c91a07@spatialys.com>

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
> gdal-dev at lists.osgeo.org
> 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 !"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260901/766d042f/attachment.htm>

From lnicola at dend.ro  Tue Sep  1 11:21:56 2026
From: lnicola at dend.ro (=?UTF-8?Q?Lauren=C8=9Biu_Nicola?=)
Date: Tue, 01 Sep 2026 21:21:56 +0300
Subject: [gdal-dev] Can c++ types be used directly from the SWIG
 interfaces?
In-Reply-To: <60b51518-b361-4339-9982-b09bf3c91a07@spatialys.com>
References: <CACKw9A9nQukYtXqKMAVjVirH7iT1A3YL4=CX4KDjPUt5Xu7cUg@mail.gmail.com>
 <60b51518-b361-4339-9982-b09bf3c91a07@spatialys.com>
Message-ID: <76af5a6b-2fef-40cc-9282-8ac66cc43cfd@app.fastmail.com>

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
>> gdal-dev at lists.osgeo.org
>> 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
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260901/9c0f3828/attachment-0001.htm>

From jctoney at gmail.com  Tue Sep  1 22:28:13 2026
From: jctoney at gmail.com (Chris Toney)
Date: Tue, 1 Sep 2026 23:28:13 -0600
Subject: [gdal-dev] Can c++ types be used directly from the SWIG
 interfaces?
In-Reply-To: <76af5a6b-2fef-40cc-9282-8ac66cc43cfd@app.fastmail.com>
References: <CACKw9A9nQukYtXqKMAVjVirH7iT1A3YL4=CX4KDjPUt5Xu7cUg@mail.gmail.com>
 <60b51518-b361-4339-9982-b09bf3c91a07@spatialys.com>
 <76af5a6b-2fef-40cc-9282-8ac66cc43cfd@app.fastmail.com>
Message-ID: <CALRbqOTx2VgcG8_gQ1hABx27-6VLBp+KNRYGkr=tup86dWUFkw@mail.gmail.com>

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
<gdal-dev at lists.osgeo.org> 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
> gdal-dev at lists.osgeo.org
> 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
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

From mbucari1 at gmail.com  Wed Sep  2 14:41:33 2026
From: mbucari1 at gmail.com (Michael)
Date: Wed, 2 Sep 2026 15:41:33 -0600
Subject: [gdal-dev] Can c++ types be used directly from the SWIG
 interfaces?
In-Reply-To: <CALRbqOTx2VgcG8_gQ1hABx27-6VLBp+KNRYGkr=tup86dWUFkw@mail.gmail.com>
References: <CACKw9A9nQukYtXqKMAVjVirH7iT1A3YL4=CX4KDjPUt5Xu7cUg@mail.gmail.com>
 <60b51518-b361-4339-9982-b09bf3c91a07@spatialys.com>
 <76af5a6b-2fef-40cc-9282-8ac66cc43cfd@app.fastmail.com>
 <CALRbqOTx2VgcG8_gQ1hABx27-6VLBp+KNRYGkr=tup86dWUFkw@mail.gmail.com>
Message-ID: <CACKw9A975Fov2n+tuY=swd1E1Px2xg_+gs_7A_m1rjZvLA=BGQ@mail.gmail.com>

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 <jctoney at gmail.com> 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
> <gdal-dev at lists.osgeo.org> 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
> > gdal-dev at lists.osgeo.org
> > 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
> > gdal-dev at lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/gdal-dev
> >
> >
> > _______________________________________________
> > gdal-dev mailing list
> > gdal-dev at lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/gdal-dev
>


-- 
Michael Bucari
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260902/7255ee8a/attachment.htm>

From howard at hobu.co  Thu Sep  3 21:39:02 2026
From: howard at hobu.co (Howard Butler)
Date: Fri, 4 Sep 2026 13:39:02 +0900
Subject: [gdal-dev] Can c++ types be used directly from the SWIG
 interfaces?
In-Reply-To: <60b51518-b361-4339-9982-b09bf3c91a07@spatialys.com>
References: <CACKw9A9nQukYtXqKMAVjVirH7iT1A3YL4=CX4KDjPUt5Xu7cUg@mail.gmail.com>
 <60b51518-b361-4339-9982-b09bf3c91a07@spatialys.com>
Message-ID: <F8727086-D21F-42BC-8E8D-8638EB6D96B6@hobu.co>



> On Sep 2, 2026, at 3:02?AM, Even Rouault via gdal-dev <gdal-dev at lists.osgeo.org> wrote:
> 
> - avoid exposing to SWIG things that haven't been considered stable enough to be exposed to C

My memory is this was the dominant reason for the current design organization of the "new" bindings. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260904/ff7deb92/attachment-0001.htm>

From even.rouault at spatialys.com  Thu Sep 10 23:39:39 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Fri, 11 Sep 2026 08:39:39 +0200
Subject: [gdal-dev] Fwd: About organizing a general strike
In-Reply-To: <c9a687a3-36b6-4603-a743-5410046d1cc3@spatialys.com>
References: <c9a687a3-36b6-4603-a743-5410046d1cc3@spatialys.com>
Message-ID: <70f1d0b1-ab19-47d7-b983-d30ed5908876@spatialys.com>

Hi there,

not sure everyone follows osgeo-discuss mailing list, but potentially of 
interest:


-------- Message transf?r? --------
Sujet?: 	About organizing a general strike
Date?: 	Fri, 11 Sep 2026 08:32:36 +0200
De?: 	Even Rouault <even.rouault at spatialys.com>
Pour?: 	OSGeo Discuss list <discuss at lists.osgeo.org>



Hi,

People are generally shy about expressing opinions that might appear to 
be revolutionnary, but it is always interesting to speak up to count forces

So I propose a general strike from the OSGeo community

Motivation: that's actually the gist of the debate there is so much 
things about why we could strike. But here in France, we don't really 
need a good reason to strike. This is part of the life style, of live 
hygiene.

So here's my motion:

"OSGeo developers start a general strike. Motives to follow up in next 
press release, or not."

Starting with my +1

Even

And no, this is not a prank.

-- 
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 !"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260911/26493045/attachment.htm>

From gdt at lexort.com  Fri Sep 11 04:08:09 2026
From: gdt at lexort.com (Greg Troxel)
Date: Fri, 11 Sep 2026 07:08:09 -0400
Subject: [gdal-dev] [PROJ] Fwd: About organizing a general strike
In-Reply-To: <70f1d0b1-ab19-47d7-b983-d30ed5908876@spatialys.com> (Even
 Rouault via PROJ's message of "Fri, 11 Sep 2026 08:39:39 +0200")
References: <c9a687a3-36b6-4603-a743-5410046d1cc3@spatialys.com>
 <70f1d0b1-ab19-47d7-b983-d30ed5908876@spatialys.com>
Message-ID: <rmitsnwrqp2.fsf@s1.lexort.com>

Even Rouault via PROJ <proj at lists.osgeo.org> writes:

> -------- Message transf?r? --------
> Sujet?: 	About organizing a general strike
> Date?: 	Fri, 11 Sep 2026 08:32:36 +0200
> De?: 	Even Rouault <even.rouault at spatialys.com>
> Pour?: 	OSGeo Discuss list <discuss at lists.osgeo.org>
>
> So I propose a general strike from the OSGeo community
>
> Motivation: that's actually the gist of the debate there is so much
> things about why we could strike. But here in France, we don't really
> need a good reason to strike. This is part of the life style, of live
> hygiene.
>
> So here's my motion:
>
> "OSGeo developers start a general strike. Motives to follow up in next
> press release, or not."

I don't understand what the point is, even though I could guess a few
things, perhaps damage to the community caused by LLMs and those who are
willing to use them.  I don't think it's proper for osgeo as a group (or
any other group that isn't specifically constituted as politcal
activism) to cross into politics other than what directly bears on
osgeo's work (e.g. non-open data from governments, LLM-caused problems
in the osgeo world).

I don't follow asking people to approve a general strike for no stated
reason with reasons to be provided later, that they might or might not
want to sign onto.

Overall, I feel like I must be missing some context.

From mdsumner at gmail.com  Sat Sep 12 03:47:12 2026
From: mdsumner at gmail.com (Michael Sumner)
Date: Sat, 12 Sep 2026 20:47:12 +1000
Subject: [gdal-dev] [PROJ] Fwd: About organizing a general strike
In-Reply-To: <rmitsnwrqp2.fsf@s1.lexort.com>
References: <c9a687a3-36b6-4603-a743-5410046d1cc3@spatialys.com>
 <70f1d0b1-ab19-47d7-b983-d30ed5908876@spatialys.com>
 <rmitsnwrqp2.fsf@s1.lexort.com>
Message-ID: <CAAcGz9_bY+rSoZ5AQZ5Wh4Ji-KB-TV-2dr9=DuH3S99mN=7C1w@mail.gmail.com>

I worry that significant funders will respond by maintaining their own
forks and permanently fragment the ecosystem. Maybe that's already happened.

But, I also think we all will soon be in permanent emergency and so rather
ensure efforts prioritize humanitarian support.

Best

Michael Sumner
Research Software Engineer
Australian Antarctic Division
Hobart, Australia
0438489030
e-mail: mdsumner at gmail.com

On Fri, Sep 11, 2026, 21:08 Greg Troxel via gdal-dev <
gdal-dev at lists.osgeo.org> wrote:

> Even Rouault via PROJ <proj at lists.osgeo.org> writes:
>
> > -------- Message transf?r? --------
> > Sujet :       About organizing a general strike
> > Date :        Fri, 11 Sep 2026 08:32:36 +0200
> > De :  Even Rouault <even.rouault at spatialys.com>
> > Pour :        OSGeo Discuss list <discuss at lists.osgeo.org>
> >
> > So I propose a general strike from the OSGeo community
> >
> > Motivation: that's actually the gist of the debate there is so much
> > things about why we could strike. But here in France, we don't really
> > need a good reason to strike. This is part of the life style, of live
> > hygiene.
> >
> > So here's my motion:
> >
> > "OSGeo developers start a general strike. Motives to follow up in next
> > press release, or not."
>
> I don't understand what the point is, even though I could guess a few
> things, perhaps damage to the community caused by LLMs and those who are
> willing to use them.  I don't think it's proper for osgeo as a group (or
> any other group that isn't specifically constituted as politcal
> activism) to cross into politics other than what directly bears on
> osgeo's work (e.g. non-open data from governments, LLM-caused problems
> in the osgeo world).
>
> I don't follow asking people to approve a general strike for no stated
> reason with reasons to be provided later, that they might or might not
> want to sign onto.
>
> Overall, I feel like I must be missing some context.
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260912/fd896e8a/attachment.htm>

From howard at hobu.co  Mon Sep 14 13:11:29 2026
From: howard at hobu.co (Howard Butler)
Date: Mon, 14 Sep 2026 15:11:29 -0500
Subject: [gdal-dev] 2026 GDAL Sponsorship Program Funding Appeal
Message-ID: <E3984014-E0A7-49B9-B35E-5E433956DB25@hobu.co>

Hello,

It is the time of the year when the GDAL Sponsorship Program (GSP) sends renewal invoices and attempts to attract new contributors to financially support the project. This year, I am writing with an update on what GSP made possible for the project over the year. Sponsorship pools resources for work that no single organization could easily fund alone, and it supports the project-wide work that keeps GDAL fast, reliable, reviewable, secure, and ready for contributors. Releases, code review, bug triage, infrastructure maintenance, and long-term modernization are things GSP supports that every GDAL user benefits from.

Since its founding, the GSP has been a key driver of operational activity in the project. From September 1, 2025 through August 31, 2026, GDAL shipped two major releases: 3.12.0 "Chicoutimi" and 3.13.0 "Iowa City", along with nine bug fix releases on nearly a two month cadence. GDAL 3.12 built on the new `gdal` command line interface and added mixed raster/vector pipelines, nested pipelines, a `tee` step, and dynamically generated Python `gdal.alg` bindings. Other work included raster band algebra, VRT pixel-function improvements, release automation, Docker attestation, and security fixes. GDAL 3.13 continued that thread with new vector commands, dataset checks, COG and GeoPackage validation, support for external commands in pipelines, Zarr V3 improvements, COG random-write creation, new E57 and CPHD drivers, S102/S104/S111 write support, NITF CADRG writing, and INTERLIS 2.4 support. Even Rouault has reported more than 590 PRs, tickets, release tasks, reviews, and maintenance items as part of his activity within the GSP for the past year. He has been responsible for all release work, repeated PROJ EPSG update handling, libtiff and other dependency security remediation, command-line interface improvements, Zarr, GeoParquet, VRT and raster-expressions, VSI maintenance, driver review, and drafting the GDAL AI/LLM policy. 

Thank you to the organizations who have publicly supported the project https://gdal.org/en/latest/sponsors/index.html . Without these resources, the project would be struggling to keep up. Unfortunately the funding base for the GSP program has been eroding in the past year+, and two gold sponsors who stopped supporting the project represent $100k of lost support. This matters because the GSP has become the way GDAL pays for work that otherwise waits too long. The new command-line interface did not appear in one release. The same is true for security hardening, dependency updates, Python usability, documentation, cloud storage support, and release infrastructure. These threads have run across the whole life of the program, and they need renewed financial support through the GDAL Sponsorship Program to continue their pace and precision.

If GDAL is part of your organization's platform, product, data pipeline, research workflow, or customer deliverable, know the GSP is the most direct way to help keep that foundation healthy besides directly contributing time and development resources. If your organization is currently a sponsor, thank you, and I hope you can renew again this year. If it isn't, please reach out if there is anything we can do to help you make the case to your organization's leadership. Renewing or joining as a sponsor helps GDAL keep shipping reliable releases, reviewing contributions, maintaining critical infrastructure, and addressing the maintenance work that future feature development depends on. 

Thanks,

Howard