From florian at katerndahl.com Wed Apr 1 07:04:36 2026 From: florian at katerndahl.com (Florian Katerndahl) Date: Wed, 1 Apr 2026 16:04:36 +0200 Subject: [gdal-dev] Coordinate transformation of geometries between CRSs with different axis ordering (C API) Message-ID: <259a3dcd-60ab-4157-a460-d80c6339f9f2@katerndahl.com> Dear all, I'm currently working on a small program which allows users to specify vector inputs in different coordinates systems and that potentially "normalizes" them to EPSG:4326 internally to process them further. Maybe I'm too inexperienced and there's an easy solution but I got hung up on the coordinate transformation when the input CRS has a different axis ordering compared to the output CRS using GDAL's/OGR's C API. For example, transforming between EPSG:5556 and EPSG:4326, GDAL outputs a warning (forwarded from proj?) that the output's latitude is invalid. Setting the axis ordering of the target CRS to `OAMS_TRADITIONAL_GIS_ORDER` fixes this and results in correctly located polygons. My question is now: Is it sufficient/correct to compare the axis ordering of the input and output coordinate systems and set above mentioned flag (or a custom mapping when neither "x"/"y" are the first two axis) in case they differ? Kind regards and many thanks in advance, Florian Katerndahl From even.rouault at spatialys.com Wed Apr 1 07:26:23 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 1 Apr 2026 16:26:23 +0200 Subject: [gdal-dev] Coordinate transformation of geometries between CRSs with different axis ordering (C API) In-Reply-To: <259a3dcd-60ab-4157-a460-d80c6339f9f2@katerndahl.com> References: <259a3dcd-60ab-4157-a460-d80c6339f9f2@katerndahl.com> Message-ID: <46516261-3212-4e55-af6a-5b7b8bb40f3f@spatialys.com> Le 01/04/2026 ? 16:04, Florian Katerndahl via gdal-dev a ?crit?: > Dear all, > > I'm currently working on a small program which allows users to specify > vector inputs in different coordinates systems and that potentially > "normalizes" them to EPSG:4326 internally to process them further. > Maybe I'm too inexperienced and there's an easy solution but I got > hung up on the coordinate transformation when the input CRS has a > different axis ordering compared to the output CRS using GDAL's/OGR's > C API. > > For example, transforming between EPSG:5556 and EPSG:4326, GDAL > outputs a warning (forwarded from proj?) that the output's latitude is > invalid. Setting the axis ordering of the target CRS to > `OAMS_TRADITIONAL_GIS_ORDER` fixes this and results in correctly > located polygons. My question is now: Is it sufficient/correct to > compare the axis ordering of the input and output coordinate systems > and set above mentioned flag (or a custom mapping when neither "x"/"y" > are the first two axis) in case they differ? The axis ordering of the input CRS vs the one of the output CRS is complelely unrelated w.r.t your decision about setting or not OAMS_TRADITIONAL_GIS_ORDER. Setting it?or not for the input totally depends?on your decision how you want to specify the coordinates. -- http://www.spatialys.com My software is free, but my time generally not. From florian at katerndahl.com Wed Apr 1 08:14:04 2026 From: florian at katerndahl.com (Florian Katerndahl) Date: Wed, 1 Apr 2026 17:14:04 +0200 Subject: [gdal-dev] Coordinate transformation of geometries between CRSs with different axis ordering (C API) In-Reply-To: <46516261-3212-4e55-af6a-5b7b8bb40f3f@spatialys.com> References: <259a3dcd-60ab-4157-a460-d80c6339f9f2@katerndahl.com> <46516261-3212-4e55-af6a-5b7b8bb40f3f@spatialys.com> Message-ID: Hi Even, thanks for your reply. I don't pass the coordinates directly via `OCTTransform` but use `OGR_GeomTransformer_Transform` to transform polygon geometries. Based on the fact than when fetching the points that make up the input polygon, the x and y coordinates match the axis of the input CRS, my assumption was that I don't need to change the ordering for the input CRS. Looking at the points in the output geometry, the coordinates are flipped when not setting?OAMS_TRADITIONAL_GIS_ORDER. This was the reason why I assumed I need to set the axis ordering depending on the CRSs I translate between. But if I understand your reply correctly, I should also not need to touch the axis ordering for the output CRS as GDAL takes care of mapping the data to CRS axis for the output geometry. I suppose my understanding is not sufficient enough (yet) to understand the underlying issue then and I will need to do some further research on my side. Kind regards, Florian On 4/1/26 16:26, Even Rouault wrote: > > Le 01/04/2026 ? 16:04, Florian Katerndahl via gdal-dev a ?crit?: >> Dear all, >> >> I'm currently working on a small program which allows users to >> specify vector inputs in different coordinates systems and that >> potentially "normalizes" them to EPSG:4326 internally to process them >> further. Maybe I'm too inexperienced and there's an easy solution but >> I got hung up on the coordinate transformation when the input CRS has >> a different axis ordering compared to the output CRS using >> GDAL's/OGR's C API. >> >> For example, transforming between EPSG:5556 and EPSG:4326, GDAL >> outputs a warning (forwarded from proj?) that the output's latitude >> is invalid. Setting the axis ordering of the target CRS to >> `OAMS_TRADITIONAL_GIS_ORDER` fixes this and results in correctly >> located polygons. My question is now: Is it sufficient/correct to >> compare the axis ordering of the input and output coordinate systems >> and set above mentioned flag (or a custom mapping when neither >> "x"/"y" are the first two axis) in case they differ? > > The axis ordering of the input CRS vs the one of the output CRS is > complelely unrelated w.r.t your decision about setting or not > OAMS_TRADITIONAL_GIS_ORDER. Setting it?or not for the input totally > depends?on your decision how you want to specify the coordinates. > > From j1 at jimenezshaw.com Wed Apr 1 08:22:51 2026 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Wed, 1 Apr 2026 17:22:51 +0200 Subject: [gdal-dev] Coordinate transformation of geometries between CRSs with different axis ordering (C API) In-Reply-To: References: <259a3dcd-60ab-4157-a460-d80c6339f9f2@katerndahl.com> <46516261-3212-4e55-af6a-5b7b8bb40f3f@spatialys.com> Message-ID: EPSG:4326 is lat-lon, EPSG:5556 is easting-northing-up. I don't see where is your problem. It would be easier if you provide some numbers and tell exactly what you expect (with numbers). On Wed, 1 Apr 2026 at 17:14, Florian Katerndahl via gdal-dev < gdal-dev at lists.osgeo.org> wrote: > Hi Even, > > thanks for your reply. > > I don't pass the coordinates directly via `OCTTransform` but use > `OGR_GeomTransformer_Transform` to transform polygon geometries. Based > on the fact than when fetching the points that make up the input > polygon, the x and y coordinates match the axis of the input CRS, my > assumption was that I don't need to change the ordering for the input > CRS. Looking at the points in the output geometry, the coordinates are > flipped when not setting OAMS_TRADITIONAL_GIS_ORDER. This was the reason > why I assumed I need to set the axis ordering depending on the CRSs I > translate between. > > But if I understand your reply correctly, I should also not need to > touch the axis ordering for the output CRS as GDAL takes care of mapping > the data to CRS axis for the output geometry. I suppose my understanding > is not sufficient enough (yet) to understand the underlying issue then > and I will need to do some further research on my side. > > > Kind regards, > > Florian > > > On 4/1/26 16:26, Even Rouault wrote: > > > > Le 01/04/2026 ? 16:04, Florian Katerndahl via gdal-dev a ?crit : > >> Dear all, > >> > >> I'm currently working on a small program which allows users to > >> specify vector inputs in different coordinates systems and that > >> potentially "normalizes" them to EPSG:4326 internally to process them > >> further. Maybe I'm too inexperienced and there's an easy solution but > >> I got hung up on the coordinate transformation when the input CRS has > >> a different axis ordering compared to the output CRS using > >> GDAL's/OGR's C API. > >> > >> For example, transforming between EPSG:5556 and EPSG:4326, GDAL > >> outputs a warning (forwarded from proj?) that the output's latitude > >> is invalid. Setting the axis ordering of the target CRS to > >> `OAMS_TRADITIONAL_GIS_ORDER` fixes this and results in correctly > >> located polygons. My question is now: Is it sufficient/correct to > >> compare the axis ordering of the input and output coordinate systems > >> and set above mentioned flag (or a custom mapping when neither > >> "x"/"y" are the first two axis) in case they differ? > > > > The axis ordering of the input CRS vs the one of the output CRS is > > complelely unrelated w.r.t your decision about setting or not > > OAMS_TRADITIONAL_GIS_ORDER. Setting it or not for the input totally > > depends on your decision how you want to specify the coordinates. > > > > > _______________________________________________ > 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: From florian at katerndahl.com Wed Apr 1 09:10:36 2026 From: florian at katerndahl.com (Florian Katerndahl) Date: Wed, 1 Apr 2026 18:10:36 +0200 Subject: [gdal-dev] Coordinate transformation of geometries between CRSs with different axis ordering (C API) In-Reply-To: References: <259a3dcd-60ab-4157-a460-d80c6339f9f2@katerndahl.com> <46516261-3212-4e55-af6a-5b7b8bb40f3f@spatialys.com> Message-ID: <9f27c420-ce43-47cd-bd3e-346aff3625b7@katerndahl.com> Hi Javier, I apologize for not being clear enough and the mess of numbers below. a sample input polygon in EPSG: 5556 is comprised of the coordinates: x: 365696.917647, y: 5840653.276548, x: 364734.337581, y: 5794593.871205, x: 419979.831607, y: 5793998.808923, x: 413446.242115, y: 5838664.507080, x: 365696.917647, y: 5840653.276548 or as WKT: POLYGON ((365696.917646939 5840653.27654771,364734.337580538 5794593.87120464,419979.831606673 5793998.8089232,413446.242115242 5838664.50707989,365696.917646939 5840653.27654771)). Transforming this to EPSG:4326 results in the following: x: 52.699111, y: 13.012456, x: 52.285039, y: 13.016931, x: 52.290512, y: 13.826754, x: 52.690976, y: 13.719374, x: 52.699111, y: 13.012456 and again as WKT: POLYGON ((52.6991111242901 13.0124564576972,52.2850386029731 13.01693061834,52.2905122538779 13.8267536946937,52.6909763323844 13.7193738392656,52.6991111242901 13.0124564576972)). The expected output is however: POLYGON ((13.0124564576972 52.6991111242901,13.01693061834 52.2850386029731,13.8267536946937 52.2905122538779,13.7193738392656 52.6909763323844,13.0124564576972 52.6991111242901)). The latter I achieve when setting OAMS_TRADITIONAL_GIS_ORDER on the target CRS (EPSG:4326). Maybe phrasing my question differently is more correct: When using?OGR_GeomTransformer_Transform to transform geometries, am I correct in the assumption that it's my responsibility to make sure the x/y coordinates stored in the supplied OGRGeometryH object are stored in the order the source CRS expects them according to its data-to-axis mapping and that if this ordering differs from what EPSG:4326 defines, set?OAMS_TRADITIONAL_GIS_ORDER on the target CRS? Kind regards, Florian On 4/1/26 17:22, Javier Jimenez Shaw wrote: > EPSG:4326 is lat-lon, EPSG:5556 is easting-northing-up. > I don't see where is your problem. > It would be easier if you provide some numbers and tell exactly what > you expect (with numbers). > > On Wed, 1 Apr 2026 at 17:14, Florian Katerndahl via gdal-dev > wrote: > > Hi Even, > > thanks for your reply. > > I don't pass the coordinates directly via `OCTTransform` but use > `OGR_GeomTransformer_Transform` to transform polygon geometries. > Based > on the fact than when fetching the points that make up the input > polygon, the x and y coordinates match the axis of the input CRS, my > assumption was that I don't need to change the ordering for the input > CRS. Looking at the points in the output geometry, the coordinates > are > flipped when not setting?OAMS_TRADITIONAL_GIS_ORDER. This was the > reason > why I assumed I need to set the axis ordering depending on the CRSs I > translate between. > > But if I understand your reply correctly, I should also not need to > touch the axis ordering for the output CRS as GDAL takes care of > mapping > the data to CRS axis for the output geometry. I suppose my > understanding > is not sufficient enough (yet) to understand the underlying issue > then > and I will need to do some further research on my side. > > > Kind regards, > > Florian > > > On 4/1/26 16:26, Even Rouault wrote: > > > > Le 01/04/2026 ? 16:04, Florian Katerndahl via gdal-dev a ?crit?: > >> Dear all, > >> > >> I'm currently working on a small program which allows users to > >> specify vector inputs in different coordinates systems and that > >> potentially "normalizes" them to EPSG:4326 internally to > process them > >> further. Maybe I'm too inexperienced and there's an easy > solution but > >> I got hung up on the coordinate transformation when the input > CRS has > >> a different axis ordering compared to the output CRS using > >> GDAL's/OGR's C API. > >> > >> For example, transforming between EPSG:5556 and EPSG:4326, GDAL > >> outputs a warning (forwarded from proj?) that the output's > latitude > >> is invalid. Setting the axis ordering of the target CRS to > >> `OAMS_TRADITIONAL_GIS_ORDER` fixes this and results in correctly > >> located polygons. My question is now: Is it sufficient/correct to > >> compare the axis ordering of the input and output coordinate > systems > >> and set above mentioned flag (or a custom mapping when neither > >> "x"/"y" are the first two axis) in case they differ? > > > > The axis ordering of the input CRS vs the one of the output CRS is > > complelely unrelated w.r.t your decision about setting or not > > OAMS_TRADITIONAL_GIS_ORDER. Setting it?or not for the input totally > > depends?on your decision how you want to specify the coordinates. > > > > > _______________________________________________ > 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: From j1 at jimenezshaw.com Wed Apr 1 09:18:05 2026 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Wed, 1 Apr 2026 18:18:05 +0200 Subject: [gdal-dev] Coordinate transformation of geometries between CRSs with different axis ordering (C API) In-Reply-To: <9f27c420-ce43-47cd-bd3e-346aff3625b7@katerndahl.com> References: <259a3dcd-60ab-4157-a460-d80c6339f9f2@katerndahl.com> <46516261-3212-4e55-af6a-5b7b8bb40f3f@spatialys.com> <9f27c420-ce43-47cd-bd3e-346aff3625b7@katerndahl.com> Message-ID: GDAL (via PROJ) is honoring the axis order of the CRS, except if OAMS_TRADITIONAL_GIS_ORDER is set. In your case, the output in ESG:4326 is lat-lon, as expected. If you want anything else, yes, it is your responsibility. On Wed, 1 Apr 2026 at 18:11, Florian Katerndahl wrote: > Hi Javier, > > I apologize for not being clear enough and the mess of numbers below. > > a sample input polygon in EPSG: 5556 is comprised of the coordinates: x: > 365696.917647, y: 5840653.276548, x: 364734.337581, y: 5794593.871205, x: > 419979.831607, y: 5793998.808923, x: 413446.242115, y: 5838664.507080, x: > 365696.917647, y: 5840653.276548 or as WKT: > POLYGON ((365696.917646939 5840653.27654771,364734.337580538 > 5794593.87120464,419979.831606673 5793998.8089232,413446.242115242 > 5838664.50707989,365696.917646939 5840653.27654771)). > Transforming this to EPSG:4326 results in the following: x: 52.699111, y: > 13.012456, x: 52.285039, y: 13.016931, x: 52.290512, y: 13.826754, x: > 52.690976, y: 13.719374, x: 52.699111, y: 13.012456 and again as WKT: > POLYGON ((52.6991111242901 13.0124564576972,52.2850386029731 > 13.01693061834,52.2905122538779 13.8267536946937,52.6909763323844 > 13.7193738392656,52.6991111242901 13.0124564576972)). > The expected output is however: POLYGON ((13.0124564576972 > 52.6991111242901,13.01693061834 52.2850386029731,13.8267536946937 > 52.2905122538779,13.7193738392656 52.6909763323844,13.0124564576972 > 52.6991111242901)). The latter I achieve when setting > OAMS_TRADITIONAL_GIS_ORDER on the target CRS (EPSG:4326). > > Maybe phrasing my question differently is more correct: When > using OGR_GeomTransformer_Transform to transform geometries, am I correct > in the assumption that it's my responsibility to make sure the x/y > coordinates stored in the supplied OGRGeometryH object are stored in the > order the source CRS expects them according to its data-to-axis mapping and > that if this ordering differs from what EPSG:4326 defines, > set OAMS_TRADITIONAL_GIS_ORDER on the target CRS? > > Kind regards, > > Florian > On 4/1/26 17:22, Javier Jimenez Shaw wrote: > > EPSG:4326 is lat-lon, EPSG:5556 is easting-northing-up. > I don't see where is your problem. > It would be easier if you provide some numbers and tell exactly what you > expect (with numbers). > > On Wed, 1 Apr 2026 at 17:14, Florian Katerndahl via gdal-dev < > gdal-dev at lists.osgeo.org> wrote: > >> Hi Even, >> >> thanks for your reply. >> >> I don't pass the coordinates directly via `OCTTransform` but use >> `OGR_GeomTransformer_Transform` to transform polygon geometries. Based >> on the fact than when fetching the points that make up the input >> polygon, the x and y coordinates match the axis of the input CRS, my >> assumption was that I don't need to change the ordering for the input >> CRS. Looking at the points in the output geometry, the coordinates are >> flipped when not setting OAMS_TRADITIONAL_GIS_ORDER. This was the reason >> why I assumed I need to set the axis ordering depending on the CRSs I >> translate between. >> >> But if I understand your reply correctly, I should also not need to >> touch the axis ordering for the output CRS as GDAL takes care of mapping >> the data to CRS axis for the output geometry. I suppose my understanding >> is not sufficient enough (yet) to understand the underlying issue then >> and I will need to do some further research on my side. >> >> >> Kind regards, >> >> Florian >> >> >> On 4/1/26 16:26, Even Rouault wrote: >> > >> > Le 01/04/2026 ? 16:04, Florian Katerndahl via gdal-dev a ?crit : >> >> Dear all, >> >> >> >> I'm currently working on a small program which allows users to >> >> specify vector inputs in different coordinates systems and that >> >> potentially "normalizes" them to EPSG:4326 internally to process them >> >> further. Maybe I'm too inexperienced and there's an easy solution but >> >> I got hung up on the coordinate transformation when the input CRS has >> >> a different axis ordering compared to the output CRS using >> >> GDAL's/OGR's C API. >> >> >> >> For example, transforming between EPSG:5556 and EPSG:4326, GDAL >> >> outputs a warning (forwarded from proj?) that the output's latitude >> >> is invalid. Setting the axis ordering of the target CRS to >> >> `OAMS_TRADITIONAL_GIS_ORDER` fixes this and results in correctly >> >> located polygons. My question is now: Is it sufficient/correct to >> >> compare the axis ordering of the input and output coordinate systems >> >> and set above mentioned flag (or a custom mapping when neither >> >> "x"/"y" are the first two axis) in case they differ? >> > >> > The axis ordering of the input CRS vs the one of the output CRS is >> > complelely unrelated w.r.t your decision about setting or not >> > OAMS_TRADITIONAL_GIS_ORDER. Setting it or not for the input totally >> > depends on your decision how you want to specify the coordinates. >> > >> > >> _______________________________________________ >> 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: From public at postholer.com Wed Apr 1 17:58:26 2026 From: public at postholer.com (Scott) Date: Wed, 1 Apr 2026 17:58:26 -0700 Subject: [gdal-dev] ogrinfo vs gdal vector info equivalent command Message-ID: <79be385d-6c6d-4aee-82cb-c7e0c181f9f1@postholer.com> Greetings! What is the equivalent 'gdal vector info' (or other CLI) command to the older ogrinfo syntax? ogrinfo -dialect sqlite -sql "create index if not exists mytable_col_idx on mytable(col)" source.gpkg The above works fine, the following errors out: gdal vector info --dialect sqlite --sql "create index mytable_col_idx on mytable(col)" source.gpkg ERROR 1: In ExecuteSQL(): sqlite3_step(create index mytable_col_idx on mytable(col)): attempt to write a readonly database I'm struggling with this and have continued to use the old ogrinfo. Thanks! Scott -- www.postholer.com From even.rouault at spatialys.com Wed Apr 1 18:03:27 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Thu, 2 Apr 2026 03:03:27 +0200 Subject: [gdal-dev] ogrinfo vs gdal vector info equivalent command In-Reply-To: <79be385d-6c6d-4aee-82cb-c7e0c181f9f1@postholer.com> References: <79be385d-6c6d-4aee-82cb-c7e0c181f9f1@postholer.com> Message-ID: <4da1892c-094e-4125-b038-41c60a667ebc@spatialys.com> Scott, you don't want info, you want to run a sql command. So gdal vector sql !? And as you perform modifications, you need to provide explicit --update gdal vector sql --update --sql "create index mytable_col_idx on mytable(col)" source.gpkg Even Le 02/04/2026 ? 02:58, Scott via gdal-dev a ?crit?: > Greetings! > > What is the equivalent 'gdal vector info' (or other CLI) command to > the older ogrinfo syntax? > > ogrinfo -dialect sqlite -sql "create index if not exists > mytable_col_idx on mytable(col)" source.gpkg > > The above works fine, the following errors out: > > gdal vector info --dialect sqlite --sql "create index mytable_col_idx > on mytable(col)" source.gpkg > > ERROR 1: In ExecuteSQL(): sqlite3_step(create index mytable_col_idx on > mytable(col)): > ? attempt to write a readonly database > > > I'm struggling with this and have continued to use the old ogrinfo. > > Thanks! > Scott > -- http://www.spatialys.com My software is free, but my time generally not. From public at postholer.com Wed Apr 1 18:16:53 2026 From: public at postholer.com (Scott) Date: Wed, 1 Apr 2026 18:16:53 -0700 Subject: [gdal-dev] ogrinfo vs gdal vector info equivalent command In-Reply-To: <4da1892c-094e-4125-b038-41c60a667ebc@spatialys.com> References: <79be385d-6c6d-4aee-82cb-c7e0c181f9f1@postholer.com> <4da1892c-094e-4125-b038-41c60a667ebc@spatialys.com> Message-ID: <2f3da5f6-6043-428b-ad15-c59655ac32d4@postholer.com> Worked perfect. I tried it with 'gdal vector sql' also, but it was the --update I was missing. Thanks Even! On 4/1/26 18:03, Even Rouault wrote: > Scott, > > you don't want info, you want to run a sql command. So gdal vector > sql !? And as you perform modifications, you need to provide explicit -- > update > > gdal vector sql --update --sql "create index mytable_col_idx on > mytable(col)" source.gpkg > > Even > > Le 02/04/2026 ? 02:58, Scott via gdal-dev a ?crit?: >> Greetings! >> >> What is the equivalent 'gdal vector info' (or other CLI) command to >> the older ogrinfo syntax? >> >> ogrinfo -dialect sqlite -sql "create index if not exists >> mytable_col_idx on mytable(col)" source.gpkg >> >> The above works fine, the following errors out: >> >> gdal vector info --dialect sqlite --sql "create index mytable_col_idx >> on mytable(col)" source.gpkg >> >> ERROR 1: In ExecuteSQL(): sqlite3_step(create index mytable_col_idx on >> mytable(col)): >> ? attempt to write a readonly database >> >> >> I'm struggling with this and have continued to use the old ogrinfo. >> >> Thanks! >> Scott >> From even.rouault at spatialys.com Thu Apr 2 06:42:52 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Thu, 2 Apr 2026 15:42:52 +0200 Subject: [gdal-dev] Integrating AI assisted code review for PR in OSGeo/GDAL? Message-ID: <9a74143e-3fcd-4c18-b229-be9afb55d2b4@spatialys.com> Hi, I think it could be worth to have the *possibility* of requiring an AI assisted review for pull requests, directly available from our canonical repo. I've been occasionaly experimenting Gemini Code Assist and Copilot in my personal fork. Copilot had repeated failures a few weeks ago but seems to have been fixed recently, so I've more experience with /gemini review. I find it useful and it has spotted real issues, some of them would have probably went unnoticed during classic human review, and with an acceptable rate of false positives or debatable remarks. So my proposal would be to have the tool(s)? enabled in OSGeo/GDAL repo, *on demand* (not sure if that's possible for Copilot. Is that a setting? Although I'm not trusting github enough to be sure if we want to increase our use of it.? Gemini review is definitely on demand and an external github app we can disable in one click) for developers or reviewers that want to trigger them. I don't think having them to run systematically is a good idea, because some PRs are too trivial to get any benefit from them, and having them enabled systematically lead to noise as PR comments and notifications. I definitely don't think those tools should replace human review. AI tools are instructed to flatter your ego and will never say your PR is a bad idea, which a human reviewer will occasionally say. Or they lack the global picture, etc. I see them as additional tools on top of our CI instrumentation and human review. Anyone with experience in that area and thoughts? Even -- http://www.spatialys.com My software is free, but my time generally not. From even.rouault at spatialys.com Thu Apr 2 06:42:52 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Thu, 2 Apr 2026 15:42:52 +0200 Subject: [gdal-dev] Integrating AI assisted code review for PR in OSGeo/GDAL? Message-ID: <9a74143e-3fcd-4c18-b229-be9afb55d2b4@spatialys.com> Hi, I think it could be worth to have the *possibility* of requiring an AI assisted review for pull requests, directly available from our canonical repo. I've been occasionaly experimenting Gemini Code Assist and Copilot in my personal fork. Copilot had repeated failures a few weeks ago but seems to have been fixed recently, so I've more experience with /gemini review. I find it useful and it has spotted real issues, some of them would have probably went unnoticed during classic human review, and with an acceptable rate of false positives or debatable remarks. So my proposal would be to have the tool(s)? enabled in OSGeo/GDAL repo, *on demand* (not sure if that's possible for Copilot. Is that a setting? Although I'm not trusting github enough to be sure if we want to increase our use of it.? Gemini review is definitely on demand and an external github app we can disable in one click) for developers or reviewers that want to trigger them. I don't think having them to run systematically is a good idea, because some PRs are too trivial to get any benefit from them, and having them enabled systematically lead to noise as PR comments and notifications. I definitely don't think those tools should replace human review. AI tools are instructed to flatter your ego and will never say your PR is a bad idea, which a human reviewer will occasionally say. Or they lack the global picture, etc. I see them as additional tools on top of our CI instrumentation and human review. Anyone with experience in that area and thoughts? Even -- http://www.spatialys.com My software is free, but my time generally not. From gdal at aitchison.me.uk Thu Apr 2 08:48:34 2026 From: gdal at aitchison.me.uk (Andrew C Aitchison) Date: Thu, 2 Apr 2026 16:48:34 +0100 (BST) Subject: [gdal-dev] Integrating AI assisted code review for PR in OSGeo/GDAL? In-Reply-To: <9a74143e-3fcd-4c18-b229-be9afb55d2b4@spatialys.com> References: <9a74143e-3fcd-4c18-b229-be9afb55d2b4@spatialys.com> Message-ID: <5b3b8ec8-e81d-11f8-5ad6-3226197ebdd1@aitchison.me.uk> On Thu, 2 Apr 2026, Even Rouault via gdal-dev wrote: > I think it could be worth to have the *possibility* of requiring an AI > assisted review for pull requests, directly available from our canonical > repo. I've been occasionaly experimenting Gemini Code Assist and Copilot in > my personal fork. Copilot had repeated failures a few weeks ago but seems to > have been fixed recently, so I've more experience with /gemini review. I find > it useful and it has spotted real issues, some of them would have probably > went unnoticed during classic human review, and with an acceptable rate of > false positives or debatable remarks. > > So my proposal would be to have the tool(s)? enabled in OSGeo/GDAL repo, *on > demand* (not sure if that's possible for Copilot. Is that a setting? Although > I'm not trusting github enough to be sure if we want to increase our use of > it.? Gemini review is definitely on demand and an external github app we can > disable in one click) for developers or reviewers that want to trigger them. > I don't think having them to run systematically is a good idea, because some > PRs are too trivial to get any benefit from them, and having them enabled > systematically lead to noise as PR comments and notifications. > > I definitely don't think those tools should replace human review. AI tools > are instructed to flatter your ego and will never say your PR is a bad idea, > which a human reviewer will occasionally say. Or they lack the global > picture, etc. I see them as additional tools on top of our CI instrumentation > and human review. This all sounds sensible and well though through to me. It was pointed out to me yesterday that https://www.microsoft.com/en-us/microsoft-copilot/for-individuals/termsofuse warns, under IMPORTANT DISCLOSURES & WARNINGS that: Copilot is for entertainment purposes only. It can make mistakes, and it may not work as intended. Don?t rely on Copilot for important advice. Use Copilot at your own risk. -- Andrew C. Aitchison Kendal, UK andrew at aitchison.me.uk From lnicola at dend.ro Thu Apr 2 08:52:53 2026 From: lnicola at dend.ro (=?UTF-8?Q?Lauren=C8=9Biu_Nicola?=) Date: Thu, 02 Apr 2026 18:52:53 +0300 Subject: [gdal-dev] Integrating AI assisted code review for PR in OSGeo/GDAL? In-Reply-To: <5b3b8ec8-e81d-11f8-5ad6-3226197ebdd1@aitchison.me.uk> References: <9a74143e-3fcd-4c18-b229-be9afb55d2b4@spatialys.com> <5b3b8ec8-e81d-11f8-5ad6-3226197ebdd1@aitchison.me.uk> Message-ID: <3c56c59a-4580-42fc-a94d-85132677dbc2@app.fastmail.com> That snippet blew up on social media, but it applies to the Web and probably Windows incarnations of Copilot. The Microsoft 365 one is explicitly excluded, and the GitHub Copilot terms of service are in gh.io. Laurentiu On Thu, Apr 2, 2026, at 18:48, Andrew C Aitchison via gdal-dev wrote: > On Thu, 2 Apr 2026, Even Rouault via gdal-dev wrote: > >> I think it could be worth to have the *possibility* of requiring an AI >> assisted review for pull requests, directly available from our canonical >> repo. I've been occasionaly experimenting Gemini Code Assist and Copilot in >> my personal fork. Copilot had repeated failures a few weeks ago but seems to >> have been fixed recently, so I've more experience with /gemini review. I find >> it useful and it has spotted real issues, some of them would have probab >> went unnoticed during classic human review, and with an acceptable rate of >> false positives or debatable remarks. >> >> So my proposal would be to have the tool(s)? enabled in OSGeo/GDAL repo, *on >> demand* (not sure if that's possible for Copilot. Is that a setting? Although >> I'm not trusting github enough to be sure if we want to increase our use of >> it.? Gemini review is definitely on demand and an external github app we can >> disable in one click) for developers or reviewers that want to trigger them. >> I don't think having them to run systematically is a good idea, because some >> PRs are too trivial to get any benefit from them, and having them enabled >> systematically lead to noise as PR comments and notifications. >> >> I definitely don't think those tools should replace human review. AI tools >> are instructed to flatter your ego and will never say your PR is a bad idea, >> which a human reviewer will occasionally say. Or they lack the global >> picture, etc. I see them as additional tools on top of our CI instrumentation >> and human review. > > This all sounds sensible and well though through to me. > > It was pointed out to me yesterday that > https://www.microsoft.com/en-us/microsoft-copilot/for-individuals/termsofuse > warns, under > IMPORTANT DISCLOSURES & WARNINGS > that: > Copilot is for entertainment purposes only. It can make mistakes, and it > may not work as intended. Don?t rely on Copilot for important advice. > Use Copilot at your own risk. > > -- > Andrew C. Aitchison Kendal, UK > andrew at aitchison.me.uk > _______________________________________________ > gdal-dev mailing list > gdal-dev at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev From schwehr at gmail.com Fri Apr 3 14:09:31 2026 From: schwehr at gmail.com (Kurt Schwehr) Date: Fri, 3 Apr 2026 14:09:31 -0700 Subject: [gdal-dev] Integrating AI assisted code review for PR in OSGeo/GDAL? In-Reply-To: <9a74143e-3fcd-4c18-b229-be9afb55d2b4@spatialys.com> References: <9a74143e-3fcd-4c18-b229-be9afb55d2b4@spatialys.com> Message-ID: My personal take: I have been using Gemini based code reviews in addition to humans for more than 6 months in other code bases. They have gradually gotten a lot better. It started off with 5-10% of the review comments being useful. Now it's more like 75% of the comments are useful. However, I occasionally end up spending significant time figuring out that something that sounds right isn't quite right for the code at hand. Or more challenging are responding to humans who insist I address AI generated comments (I've been that person too...) Overall, it's been a win in getting a lot of little bugs out of code and some of those bugs have been in the code for more than a decade. Just be ready to ignore a lot of AI comments. -Kurt On Thu, Apr 2, 2026 at 6:43?AM Even Rouault via gdal-dev < gdal-dev at lists.osgeo.org> wrote: > Hi, > > I think it could be worth to have the *possibility* of requiring an AI > assisted review for pull requests, directly available from our canonical > repo. I've been occasionaly experimenting Gemini Code Assist and Copilot > in my personal fork. Copilot had repeated failures a few weeks ago but > seems to have been fixed recently, so I've more experience with /gemini > review. I find it useful and it has spotted real issues, some of them > would have probably went unnoticed during classic human review, and with > an acceptable rate of false positives or debatable remarks. > > So my proposal would be to have the tool(s) enabled in OSGeo/GDAL repo, > *on demand* (not sure if that's possible for Copilot. Is that a setting? > Although I'm not trusting github enough to be sure if we want to > increase our use of it. Gemini review is definitely on demand and an > external github app we can disable in one click) for developers or > reviewers that want to trigger them. I don't think having them to run > systematically is a good idea, because some PRs are too trivial to get > any benefit from them, and having them enabled systematically lead to > noise as PR comments and notifications. > > I definitely don't think those tools should replace human review. AI > tools are instructed to flatter your ego and will never say your PR is a > bad idea, which a human reviewer will occasionally say. Or they lack the > global picture, etc. I see them as additional tools on top of our CI > instrumentation and human review. > > Anyone with experience in that area and thoughts? > > Even > > -- > http://www.spatialys.com > My software is free, but my time generally not. > > _______________________________________________ > 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: From even.rouault at spatialys.com Fri Apr 3 15:03:38 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Sat, 4 Apr 2026 00:03:38 +0200 Subject: [gdal-dev] Integrating AI assisted code review for PR in OSGeo/GDAL? In-Reply-To: References: <9a74143e-3fcd-4c18-b229-be9afb55d2b4@spatialys.com> Message-ID: <27dd5893-4e36-4946-80d8-bbcf80a6aa55@spatialys.com> > Overall, it's been a win in getting a lot of little bugs out of code > and some of those bugs have been in the code for more than a decade. > Just be ready to ignore a lot of AI comments. > I found the classification it offers is quite good. "High" priority remarks are almost always genuine bugs and need to be taken into account one way or other (fixing most of the time, or adding a solid code comment to justify why suspect looking code is actually fine). Medium maybe 50% 50%. And Low priority are often a matter of taste / nice to have but not end of the world if not addressed. Reviewers and submitters should have that in mind when helping the PR move forward. -- http://www.spatialys.com My software is free, but my time generally not. From e.chs at outlook.com Fri Apr 3 16:40:49 2026 From: e.chs at outlook.com (=?utf-8?B?RWRvdWFyZCBDaG9pbmnDqHJl?=) Date: Fri, 3 Apr 2026 23:40:49 +0000 Subject: [gdal-dev] Integrating AI assisted code review for PR in OSGeo/GDAL? In-Reply-To: <9a74143e-3fcd-4c18-b229-be9afb55d2b4@spatialys.com> References: <9a74143e-3fcd-4c18-b229-be9afb55d2b4@spatialys.com> Message-ID: One of my repos (MegaLinter) has the free tier of Cursor Bugbot enabled. Theres a number of PRs per month included. Appart from the PR summary added beneath (that isn?t so useful, but sometimes useful to double-check that something else isn?t squeezed in), I kinda started to like it for finding inconsistencies between files in the repo, ie, you?re changing something here, but another place (or docs) contradicts it or won?t work with the changes. It?s probably not unique to that product, I don?t even know what?s the model behind, I didn?t configure it myself. After the limit of free reviews in the month, it?s shuts off and doesn?t annoy anyone. For external contributors, usually they touch up once or twice their PRs with that AI review for simple mistakes and when we get to review it, there?s way less to look at. Edouard Choini?re > Le 2 avr. 2026 ? 09:42, Even Rouault a ?crit : > > ?Hi, > > I think it could be worth to have the *possibility* of requiring an AI assisted review for pull requests, directly available from our canonical repo. I've been occasionaly experimenting Gemini Code Assist and Copilot in my personal fork. Copilot had repeated failures a few weeks ago but seems to have been fixed recently, so I've more experience with /gemini review. I find it useful and it has spotted real issues, some of them would have probably went unnoticed during classic human review, and with an acceptable rate of false positives or debatable remarks. > > So my proposal would be to have the tool(s) enabled in OSGeo/GDAL repo, *on demand* (not sure if that's possible for Copilot. Is that a setting? Although I'm not trusting github enough to be sure if we want to increase our use of it. Gemini review is definitely on demand and an external github app we can disable in one click) for developers or reviewers that want to trigger them. I don't think having them to run systematically is a good idea, because some PRs are too trivial to get any benefit from them, and having them enabled systematically lead to noise as PR comments and notifications. > > I definitely don't think those tools should replace human review. AI tools are instructed to flatter your ego and will never say your PR is a bad idea, which a human reviewer will occasionally say. Or they lack the global picture, etc. I see them as additional tools on top of our CI instrumentation and human review. > > Anyone with experience in that area and thoughts? > > Even > > -- > http://www.spatialys.com > My software is free, but my time generally not. > > From even.rouault at spatialys.com Sat Apr 4 09:01:10 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Sat, 4 Apr 2026 18:01:10 +0200 Subject: [gdal-dev] Anyone has already forgotten the /vsicurl/ prefix? In-Reply-To: <0264434a-3c33-4896-82f7-7df5a247df63@spatialys.com> References: <0264434a-3c33-4896-82f7-7df5a247df63@spatialys.com> Message-ID: <3595c892-b208-41fd-bb0c-baa7bbba8c1f@spatialys.com> Hi, Following-up on this, after a bit of not super conclusive experimentation, I gave up on the idea of a GDAL autoselection of HTTP driver vs /vsicurl/ . The sad reality is that the web in 2026 is not yet ready for GDAL very demanding expectations, i.e. that servers in the wild would return reliably & fastly a "Accept-range: none" or "Accept-range: bytes" header to a HEAD request. So I've fallen back to documenting that whole issue in https://github.com/OSGeo/gdal/pull/14291 Even Le 27/03/2026 ? 18:08, Even Rouault via gdal-dev a ?crit?: > Hi, > > I suspect that almost every GDAL user, even the most experienced, has > made the mistake of typing "gdalinfo https://example.com/my.tif" > instead of "gdalinfo /vsicurl/https://example.com/my.tif". Both > commands work, but the first one triggers the HTTP pseudo-driver which > downloads the entire file into memory before passing it to the GeoTIFF > driver, while the second reads it in chunks. > > I would be inclined to modify the GDALOpen() logic with the following > tweak: if the passed filename starts with "http://" or "https://", > automatically prepend "/vsicurl/", unless the string has query > parameters. That restriction about not having query parameters is > because in most of the cases this is for dynamically generated > resources that don't support range requests. > > For users really wanting to go through the HTTP pseudo-driver, we'd > modify it to accept a "HTTP:" prefix before the URL or it would > trigger if using the "-if HTTP" argument of command line utilities (or > allowed_drivers = ["HTTP"] in the API) > > So this change wouldn't be fully backwards compatible, but I feel it > would still make more people happy than unhappy. > > Thoughts? > > Even > -- http://www.spatialys.com My software is free, but my time generally not. From jctoney at gmail.com Sat Apr 4 23:21:00 2026 From: jctoney at gmail.com (Chris Toney) Date: Sun, 5 Apr 2026 00:21:00 -0600 Subject: [gdal-dev] inconsistent naming for the CLI "input" argument Message-ID: A large majority of the CLI algorithms use `-i, --input ` for the input arg, and those are the names generally described in specifications. There is a lot of variation though. I'm not suggesting they should all be made entirely consistent. Various aliases make sense to have in some cases. But several cases seem worth considering. The main issue is the occasional use of "dataset" as an alias for "input". It's inconsistently available as an alias which seems not ideal, but it also shows up in unexpected ways. "raster edit" has only --dataset with no --input or -i: --dataset "raster overview add" has: -i, --dataset, --input But "raster overview delete" and "raster overview refresh" have only: --dataset A dataset-specific one "dataset check" doesn't use it: -i, --input Is the "dataset" alias really worth having? A couple others are unique cases that may not be a problem. These just stand out as different since meta_var rarely deviates from the naming pattern. "raster calc" has: -i, --input "raster blend" has: -i, --color-input, --input Those are the only cases I've found where the meta_var name is different than the long name. Nearly all have for --input even if there is an alias, e.g., "raster pansharpen" has `-i, --panchromatic, --input `. I checked several others that can take multiple input datasets, and "raster calc" is the only one I found with plural INPUTS. Maybe that's not a big deal because the meta_var is only for display in the documentation? It could still be worth making them consistent for readability. Since is almost always used for the positional input dataset(s), when I see it looks like possibly something other than a raster dataset. Thanks. Chris From even.rouault at spatialys.com Sun Apr 5 03:21:41 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Sun, 5 Apr 2026 12:21:41 +0200 Subject: [gdal-dev] inconsistent naming for the CLI "input" argument In-Reply-To: References: Message-ID: <1e4d6911-e0eb-4146-ac90-24a92a392b77@spatialys.com> Hi Chris, > The main issue is the occasional use of "dataset" as an alias for > "input". It's inconsistently available as an alias which seems not > ideal, but it also shows up in unexpected ways. > > "raster edit" has only --dataset with no --input or -i: > --dataset The rationale was that raster edit only takes a single dataset which is both input and output. Input could also suggest that it won't be modified, which is not the case here. But I see we have hesitated in different similar (or similar looking, but subtely different) situations if we needed to expose input, dataset or both. > > "raster overview add" has: > -i, --dataset, --input > > But "raster overview delete" and "raster overview refresh" have only: > --dataset > > A dataset-specific one "dataset check" doesn't use it: > -i, --input For dataset check, the dataset isn't modified. > > Is the "dataset" alias really worth having? Good question. Happy to hear about other's opinion on this. > > A couple others are unique cases that may not be a problem. These just > stand out as different since meta_var rarely deviates from the naming > pattern. > > "raster calc" has: > -i, --input Plural to suggest you can specify several ones > > "raster blend" has: > -i, --color-input, --input The metavar is important to remind the semantics because it accepts a second input dataset : --overlay > > Those are the only cases I've found where the meta_var name is > different than the long name. Nearly all have for --input even > if there is an alias, e.g., "raster pansharpen" has `-i, > --panchromatic, --input `. Similar to raster blend: ? -i, --panchromatic, --input Input panchromatic raster dataset [required] ? --spectral Input spectral band dataset [1.. values] [required] The input name helps here to remember which dataset is implicit or not when you use it in a pipeline context (input must not be specified as the result of the previous step): gdal raster pipeline read panchro.tif ! pansharpen multispectral.tif ! write out.tif > I checked several others that can > take multiple input datasets, and "raster calc" is the only one I > found with plural INPUTS. Maybe that's not a big deal because the > meta_var is only for display in the documentation? It could still be > worth making them consistent for readability. Yes we could put plural INPUTS in other situations where input accepts multiple files > Since is almost > always used for the positional input dataset(s), when I see > it looks like possibly something other than a raster > dataset. Should the metavar of INPUT be INPUT-DATASET in general case, and COLOR-INPUT-DATASET for blend / PANCHRO-DATASET for pansharpen ? -- http://www.spatialys.com My software is free, but my time generally not. From gdal at aitchison.me.uk Sun Apr 5 07:47:40 2026 From: gdal at aitchison.me.uk (Andrew C Aitchison) Date: Sun, 5 Apr 2026 15:47:40 +0100 (BST) Subject: [gdal-dev] inconsistent naming for the CLI "input" argument Message-ID: <277d6d4f-670c-3ff5-cf85-6f35e7be0a81@aitchison.me.uk> On Sun, 5 Apr 2026, Chris Toney via gdal-dev wrote: > A large majority of the CLI algorithms use `-i, --input > ` for > the input arg, and those are the names generally described > in > specifications. There is a lot of variation though. I'm not > suggesting > they should all be made entirely consistent. Various > aliases make > sense to have in some cases. But several cases seem worth > considering. > > The main issue is the occasional use of "dataset" as an > alias for > "input". It's inconsistently available as an alias which > seems not > ideal, but it also shows up in unexpected ways. > > "raster edit" has only --dataset with no --input or -i: > --dataset > > "raster overview add" has: > -i, --dataset, --input > > But "raster overview delete" and "raster overview refresh" > have only: > --dataset > > A dataset-specific one "dataset check" doesn't use it: > -i, --input > > Is the "dataset" alias really worth having? For 'raster edit' and 'raster delete' I don't see --input as appropriate (although logically raster delete --input is not wrong). -- Andrew C. Aitchison Kendal, UK andrew at aitchison.me.uk From even.rouault at spatialys.com Sun Apr 5 10:53:44 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Sun, 5 Apr 2026 19:53:44 +0200 Subject: [gdal-dev] ETRS89 issues with PROJ 9.8.0 In-Reply-To: <5d59f01f-7ef8-45c0-bd48-62e911562c6f@spatialys.com> References: <5d59f01f-7ef8-45c0-bd48-62e911562c6f@spatialys.com> Message-ID: Hi, Please read the forwarded email below if you perform ETRS89-related coordinate transformations. To mitigate those issues, I've generated Docker images based on the GDAL v3.12.3 tag reverting to PROJ 9.7.1 (note the -r1 suffix): * ghcr.io/osgeo/gdal:alpine-small-3.12.3-r1 * ghcr.io/osgeo/gdal:alpine-normal-3.12.3-r1 * ghcr.io/osgeo/gdal:ubuntu-small-3.12.3-r1 * ghcr.io/osgeo/gdal:ubuntu-full-3.12.3-r1 Note that GDAL Docker -latest images use PROJ master (still affected by those 9.8.0 issues). I don't plan to change that,?since it can be useful to test fixes as they land in PROJ master? ? . GDAL 3.12.3 (and gdal-master) Conda builds are currently at 9.8.0. Track https://github.com/conda-forge/gdal-feedstock/issues/1191 for a potential revert to 9.7.1 Even -------- Message transf?r? -------- Sujet?: [PROJ] ETRS89 issues with PROJ 9.8.0 Date?: Sun, 5 Apr 2026 18:53:01 +0200 De?: Even Rouault via PROJ R?pondre ??: Even Rouault Pour?: proj Hi, We're hearing alarm bells coming from various European users related to transformations between pre-ETRS89 national CRS an ETRS89-based CRS,? caused by significant changes in that area that have been introduced in the EPSG dataset embedded in PROJ 9.8.0. Namely the creation of ETRS89-XXX datums where XXX is the ISO code of the country. https://github.com/OSGeo/PROJ/pull/4736 exposes a few of the issues met, and a partial workaround, but not covering all cases. Please also report issues you might hit in that area. We are working with EPSG to help fix the situation. For people mastering their supply chain, reverting back to 9.7.1 might be prudent. Even -- http://www.spatialys.com My software is free, but my time generally not. _______________________________________________ PROJ mailing list PROJ at lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/proj -------------- next part -------------- An HTML attachment was scrubbed... URL: From jctoney at gmail.com Sun Apr 5 11:22:16 2026 From: jctoney at gmail.com (Chris Toney) Date: Sun, 5 Apr 2026 12:22:16 -0600 Subject: [gdal-dev] inconsistent naming for the CLI "input" argument In-Reply-To: <1e4d6911-e0eb-4146-ac90-24a92a392b77@spatialys.com> References: <1e4d6911-e0eb-4146-ac90-24a92a392b77@spatialys.com> Message-ID: Even, Thanks for the comments. That helps a lot, if I understand correctly now: "input" alone - not modified "dataset" alone - modified / is input and output "input" with "dataset" alias - the input may be modified Going back through with that in mind, it looks largely consistent with a small number of exceptions. Starting with "raster edit", it has only "dataset" which is input and output, then... "raster info" -i, --dataset, --input Makes sense, input may be modified, e.g., if --stats are computed they may be set back on the input dataset. "vector info" -i, --dataset, --input Same, input may be modified if --sql is given for UPDATE, DELETE, etc. Exceptions: "vector sql" -i, --input Should also have "dataset" alias? >Starting with GDAL 3.12, when using --update, and without an output dataset specified, this can be used to execute statements that modify the input dataset, such as UPDATE, DELETE, etc. "gdal info" -i, --input Add "dataset" alias to align with "raster info" and "vector info"? (and "mdim info" also has "dataset" alias) Then these three probably should be aligned: "raster overview add" -i, --dataset, --input Dataset (to be updated in-place, unless --external) "raster overview delete" --dataset Dataset (to be updated in-place, unless --read-only) "raster overview refresh" --dataset Dataset (to be updated in-place, unless --external) This one has "dataset" alias but does not modify input, seems to be a lone exception in that regard: "raster update" -i, --dataset, --input -o, --output I think "dataset" should be kept based on that understanding. I don't have strong feelings on the names other than consistency is good. The existing "inconsistencies" are pretty minor so not sure if changes are really needed. The aim is not to be super nitpicky over arg names and their aliases. Motivation is API usage where application code takes dataset objects as user input to CLI algorithms. The dataset objects may carry information that should be used to parameterize the algorithm call. The user may have already set properties on the object and should not have to provide those explicitly again when passing to an algorithm. The algorithm arg names must be used in parsing in some cases to infer meaning, i.e., we cannot always rely only on querying properties of the AlgorithmArg object. An example is "like" / "like-layer" / "like-sql" / "like-where". Parsing for those needs to rely on the arg names (and any potential aliases) for meaning. So the names/aliases really should be always consistent, which I believe they are in that case. "input" and "dataset" aren't quite the same since we can query the AlgorithmArg object and determine what it's for. But the more consistent they can be in usage the better IMO. Chris On Sun, Apr 5, 2026 at 4:21?AM Even Rouault wrote: > > Hi Chris, > > > The main issue is the occasional use of "dataset" as an alias for > > "input". It's inconsistently available as an alias which seems not > > ideal, but it also shows up in unexpected ways. > > > > "raster edit" has only --dataset with no --input or -i: > > --dataset > The rationale was that raster edit only takes a single dataset which is > both input and output. Input could also suggest that it won't be > modified, which is not the case here. But I see we have hesitated in > different similar (or similar looking, but subtely different) situations > if we needed to expose input, dataset or both. > > > > "raster overview add" has: > > -i, --dataset, --input > > > > But "raster overview delete" and "raster overview refresh" have only: > > --dataset > > > > A dataset-specific one "dataset check" doesn't use it: > > -i, --input > For dataset check, the dataset isn't modified. > > > > Is the "dataset" alias really worth having? > Good question. Happy to hear about other's opinion on this. > > > > A couple others are unique cases that may not be a problem. These just > > stand out as different since meta_var rarely deviates from the naming > > pattern. > > > > "raster calc" has: > > -i, --input > Plural to suggest you can specify several ones > > > > "raster blend" has: > > -i, --color-input, --input > The metavar is important to remind the semantics because it accepts a > second input dataset : --overlay > > > > Those are the only cases I've found where the meta_var name is > > different than the long name. Nearly all have for --input even > > if there is an alias, e.g., "raster pansharpen" has `-i, > > --panchromatic, --input `. > > Similar to raster blend: > > -i, --panchromatic, --input Input panchromatic raster dataset > [required] > --spectral Input spectral band dataset [1.. values] [required] > > The input name helps here to remember which dataset is implicit or not > when you use it in a pipeline context (input must not be specified as > the result of the previous step): > > gdal raster pipeline read panchro.tif ! pansharpen multispectral.tif ! > write out.tif > > > > I checked several others that can > > take multiple input datasets, and "raster calc" is the only one I > > found with plural INPUTS. Maybe that's not a big deal because the > > meta_var is only for display in the documentation? It could still be > > worth making them consistent for readability. > Yes we could put plural INPUTS in other situations where input accepts > multiple files > > Since is almost > > always used for the positional input dataset(s), when I see > > it looks like possibly something other than a raster > > dataset. > Should the metavar of INPUT be INPUT-DATASET in general case, and > COLOR-INPUT-DATASET for blend / PANCHRO-DATASET for pansharpen ? > > -- > http://www.spatialys.com > My software is free, but my time generally not. > From public at postholer.com Sun Apr 5 13:14:17 2026 From: public at postholer.com (Scott) Date: Sun, 5 Apr 2026 13:14:17 -0700 Subject: [gdal-dev] gdal raster calc and -i nested pipeline, proper usage? Message-ID: Greetings, Is the following proper usage? gdal raster pipeline \ ! calc -i [ ! stack --resolution=highest -i *.tif ! materialize ] --flatten --calc=mean --dialect=builtin \ ! write -o result.tif --co COMPRESS=DEFLATE --overwrite ...results in the error: ERROR 1: Failed to open $$nested_pipeline_0x563f54398d00$$ 0...10...20...30...40...50...60...70...80...90...100 - done. Removing materialize altogether or adding -o tmp.tif to materialize results in the same error. Debian 12 GDAL 3.13.0dev-8e81b0c5db, released 2026/03/24 Thanks! Scott -- www.postholer.com From even.rouault at spatialys.com Sun Apr 5 13:45:26 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Sun, 5 Apr 2026 22:45:26 +0200 Subject: [gdal-dev] gdal raster calc and -i nested pipeline, proper usage? In-Reply-To: References: Message-ID: <234e28c1-75ea-4c5b-b38e-02f3a211d478@spatialys.com> See https://gdal.org/en/latest/programs/gdal_raster_calc.html#programs/gdal_raster_calc-6 Le 05/04/2026 ? 22:14, Scott via gdal-dev a ?crit?: > Greetings, > > Is the following proper usage? > > gdal raster pipeline \ > ?? ! calc -i [ ! stack --resolution=highest -i *.tif ! materialize ] > --flatten --calc=mean --dialect=builtin \ > ?? ! write -o result.tif --co COMPRESS=DEFLATE --overwrite > > ...results in the error: > > ERROR 1: Failed to open $$nested_pipeline_0x563f54398d00$$ > 0...10...20...30...40...50...60...70...80...90...100 - done. > > Removing materialize altogether or adding -o tmp.tif to materialize > results in the same error. > > Debian 12 > GDAL 3.13.0dev-8e81b0c5db, released 2026/03/24 > > Thanks! > Scott > -- http://www.spatialys.com My software is free, but my time generally not. From public at postholer.com Sun Apr 5 14:04:18 2026 From: public at postholer.com (Scott) Date: Sun, 5 Apr 2026 14:04:18 -0700 Subject: [gdal-dev] gdal raster calc and -i nested pipeline, proper usage? In-Reply-To: <234e28c1-75ea-4c5b-b38e-02f3a211d478@spatialys.com> References: <234e28c1-75ea-4c5b-b38e-02f3a211d478@spatialys.com> Message-ID: <317a7dc9-63ad-4178-b18e-d4d340193c80@postholer.com> Right. RTFM. Worked perfect! On 4/5/26 13:45, Even Rouault wrote: > See https://gdal.org/en/latest/programs/gdal_raster_calc.html#programs/ > gdal_raster_calc-6 > > Le 05/04/2026 ? 22:14, Scott via gdal-dev a ?crit?: >> Greetings, >> >> Is the following proper usage? >> >> gdal raster pipeline \ >> ?? ! calc -i [ ! stack --resolution=highest -i *.tif ! materialize ] >> --flatten --calc=mean --dialect=builtin \ >> ?? ! write -o result.tif --co COMPRESS=DEFLATE --overwrite >> >> ...results in the error: >> >> ERROR 1: Failed to open $$nested_pipeline_0x563f54398d00$$ >> 0...10...20...30...40...50...60...70...80...90...100 - done. >> >> Removing materialize altogether or adding -o tmp.tif to materialize >> results in the same error. >> >> Debian 12 >> GDAL 3.13.0dev-8e81b0c5db, released 2026/03/24 >> >> Thanks! >> Scott >> From even.rouault at spatialys.com Sun Apr 5 14:16:45 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Sun, 5 Apr 2026 23:16:45 +0200 Subject: [gdal-dev] inconsistent naming for the CLI "input" argument In-Reply-To: References: <1e4d6911-e0eb-4146-ac90-24a92a392b77@spatialys.com> Message-ID: <0d599a7d-2848-4d42-abfe-aee797ef65a3@spatialys.com> Hopefully your below suggestions are captured in https://github.com/OSGeo/gdal/pull/14297 Thanks for the analysis. Consistency is hard! Even Le 05/04/2026 ? 20:22, Chris Toney a ?crit?: > Even, > Thanks for the comments. That helps a lot, if I understand correctly now: > "input" alone - not modified > "dataset" alone - modified / is input and output > "input" with "dataset" alias - the input may be modified > > Going back through with that in mind, it looks largely consistent with > a small number of exceptions. Starting with "raster edit", it has only > "dataset" which is input and output, then... > > "raster info" > -i, --dataset, --input > > Makes sense, input may be modified, e.g., if --stats are computed they > may be set back on the input dataset. > > "vector info" > -i, --dataset, --input > > Same, input may be modified if --sql is given for UPDATE, DELETE, etc. > > Exceptions: > > "vector sql" > -i, --input > > Should also have "dataset" alias? >> Starting with GDAL 3.12, when using --update, and without an output dataset specified, this can be used to execute statements that modify the input dataset, such as UPDATE, DELETE, etc. > "gdal info" > -i, --input > > Add "dataset" alias to align with "raster info" and "vector info"? > (and "mdim info" also has "dataset" alias) > > Then these three probably should be aligned: > > "raster overview add" > -i, --dataset, --input Dataset (to be updated in-place, > unless --external) > > "raster overview delete" > --dataset Dataset (to be updated in-place, unless --read-only) > > "raster overview refresh" > --dataset Dataset (to be updated in-place, unless --external) > > This one has "dataset" alias but does not modify input, seems to be a > lone exception in that regard: > > "raster update" > -i, --dataset, --input > -o, --output > > I think "dataset" should be kept based on that understanding. > > I don't have strong feelings on the names other than > consistency is good. The existing "inconsistencies" are pretty minor > so not sure if changes are really needed. > > The aim is not to be super nitpicky over arg names and their aliases. > Motivation is API usage where application code takes dataset objects > as user input to CLI algorithms. The dataset objects may carry > information that should be used to parameterize the algorithm call. > The user may have already set properties on the object and should not > have to provide those explicitly again when passing to an algorithm. > The algorithm arg names must be used in parsing in some cases to infer > meaning, i.e., we cannot always rely only on querying properties of > the AlgorithmArg object. An example is "like" / "like-layer" / > "like-sql" / "like-where". Parsing for those needs to rely on the arg > names (and any potential aliases) for meaning. So the names/aliases > really should be always consistent, which I believe they are in that > case. > > "input" and "dataset" aren't quite the same since we can query the > AlgorithmArg object and determine what it's for. But the more > consistent they can be in usage the better IMO. > > Chris > > On Sun, Apr 5, 2026 at 4:21?AM Even Rouault wrote: >> Hi Chris, >> >>> The main issue is the occasional use of "dataset" as an alias for >>> "input". It's inconsistently available as an alias which seems not >>> ideal, but it also shows up in unexpected ways. >>> >>> "raster edit" has only --dataset with no --input or -i: >>> --dataset >> The rationale was that raster edit only takes a single dataset which is >> both input and output. Input could also suggest that it won't be >> modified, which is not the case here. But I see we have hesitated in >> different similar (or similar looking, but subtely different) situations >> if we needed to expose input, dataset or both. >>> "raster overview add" has: >>> -i, --dataset, --input >>> >>> But "raster overview delete" and "raster overview refresh" have only: >>> --dataset >>> >>> A dataset-specific one "dataset check" doesn't use it: >>> -i, --input >> For dataset check, the dataset isn't modified. >>> Is the "dataset" alias really worth having? >> Good question. Happy to hear about other's opinion on this. >>> A couple others are unique cases that may not be a problem. These just >>> stand out as different since meta_var rarely deviates from the naming >>> pattern. >>> >>> "raster calc" has: >>> -i, --input >> Plural to suggest you can specify several ones >>> "raster blend" has: >>> -i, --color-input, --input >> The metavar is important to remind the semantics because it accepts a >> second input dataset : --overlay >>> Those are the only cases I've found where the meta_var name is >>> different than the long name. Nearly all have for --input even >>> if there is an alias, e.g., "raster pansharpen" has `-i, >>> --panchromatic, --input `. >> Similar to raster blend: >> >> -i, --panchromatic, --input Input panchromatic raster dataset >> [required] >> --spectral Input spectral band dataset [1.. values] [required] >> >> The input name helps here to remember which dataset is implicit or not >> when you use it in a pipeline context (input must not be specified as >> the result of the previous step): >> >> gdal raster pipeline read panchro.tif ! pansharpen multispectral.tif ! >> write out.tif >> >> >>> I checked several others that can >>> take multiple input datasets, and "raster calc" is the only one I >>> found with plural INPUTS. Maybe that's not a big deal because the >>> meta_var is only for display in the documentation? It could still be >>> worth making them consistent for readability. >> Yes we could put plural INPUTS in other situations where input accepts >> multiple files >>> Since is almost >>> always used for the positional input dataset(s), when I see >>> it looks like possibly something other than a raster >>> dataset. >> Should the metavar of INPUT be INPUT-DATASET in general case, and >> COLOR-INPUT-DATASET for blend / PANCHRO-DATASET for pansharpen ? >> >> -- >> http://www.spatialys.com >> My software is free, but my time generally not. >> -- http://www.spatialys.com My software is free, but my time generally not. From cgodkin at gmail.com Mon Apr 6 08:32:55 2026 From: cgodkin at gmail.com (Carl Godkin) Date: Mon, 6 Apr 2026 08:32:55 -0700 Subject: [gdal-dev] Trouble building GDAL 3.12.3 on Linux Message-ID: Hi, I'm updating our GDAL and other third party libraries. I'm usually pretty adept at this but I am having a problem building GDAL 3.12.3 on Linux RHEL8 with GCC 13.2. The shared library builds okay, but once we get to the apps, I am getting undefined references to two PROJ functions (proj_coordinate_metadata_create & proj_crs_has_point_motion_operation). I was struggling with this last Friday with PROJ 9.8.0 but, after this weekend's advice about ETRS89, I switched to PROJ 9.7.1 where I'm having the same problem. I haven't seen any similar questions go by and I am stuck. Any advice? My GDAL 3.12.3 cmake command looks like this: cmake \ -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_C_COMPILER:FILEPATH=/usr/local/gcc132/bin/gcc \ -DCMAKE_CXX_COMPILER:FILEPATH=/usr/local/gcc132/bin/g++ \ -DCMAKE_POSITION_INDEPENDENT_CODE=ON \ -DCMAKE_INSTALL_PREFIX=/usr/local/devlibs/gdal-3.12.3 \ -DBUILD_JAVA_BINDINGS:BOOL=OFF \ -DSQLite3_INCLUDE_DIR=/usr/local/devlibs/sqlite-3.51.3/include \ -DSQLite3_LIBRARY=/usr/local/devlibs/sqlite-3.51.3/lib/libsqlite3.so \ -DARCHIVE_INCLUDE_DIR=/usr/local/devlibs/libarchive-3.8.6/include \ -DARCHIVE_LIBRARY=/usr/local/devlibs/libarchive-3.8.6/lib64/libarchive.so \ -DCURL_INCLUDE_DIR=/usr/local/devlibs/curl-8.4.0/include \ -DCURL_LIBRARY_RELEASE=/usr/local/devlibs/curl-8.4.0/lib64/libcurl.so \ -DPROJ_INCLUDE_DIR=/usr/local/devlibs/proj-9.7.1/include \ -DPROJ_LIBRARY_RELEASE=/usr/local/devlibs/proj-9.7.1/lib64/libproj.so \ -DGDAL_USE_GEOTIFF_INTERNAL:BOOL=ON \ -DGDAL_USE_WEBP_INTERNAL:BOOL=ON \ -DMRSID_INCLUDE_DIR=/usr/local/devlibs/MrSID_DSDK-9.5.4.4709-rhel6.x86-64.gcc531/Raster_DSDK/include \ -DMRSID_LIBRARY=/usr/local/devlibs/MrSID_DSDK-9.5.4.4709-rhel6.x86-64.gcc531/Raster_DSDK/lib/libltidsdk.so \ -DGDAL_ENABLE_DRIVER_JP2MRSID=ON \ .. and my PROJ 9.7.0 is pretty basic, and looks like this: cmake \ -DCMAKE_BUILD_TYPE=Release \ -Wno-dev -Wno-deprecated \ -DCMAKE_C_COMPILER:FILEPATH=/usr/local/gcc132/bin/gcc \ -DCMAKE_CXX_COMPILER:FILEPATH=/usr/local/gcc132/bin/g++ \ -DCMAKE_POSITION_INDEPENDENT_CODE=ON \ -DCMAKE_INSTALL_PREFIX=/usr/local/devlibs/proj-9.7.1 \ .. Thank you very much, carl -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.bell.ia at gmail.com Mon Apr 6 08:47:26 2026 From: andrew.bell.ia at gmail.com (Andrew Bell) Date: Mon, 6 Apr 2026 11:47:26 -0400 Subject: [gdal-dev] Trouble building GDAL 3.12.3 on Linux In-Reply-To: References: Message-ID: Hi Carl, The actual build command from the failing step might be helpful. On Mon, Apr 6, 2026 at 11:33?AM Carl Godkin via gdal-dev wrote: > > Hi, > > I'm updating our GDAL and other third party libraries. I'm usually pretty adept at this but I am having a problem building GDAL 3.12.3 on Linux RHEL8 with GCC 13.2. > > The shared library builds okay, but once we get to the apps, I am getting undefined references to two PROJ functions (proj_coordinate_metadata_create & proj_crs_has_point_motion_operation). > > I was struggling with this last Friday with PROJ 9.8.0 but, after this weekend's advice about ETRS89, I switched to PROJ 9.7.1 where I'm having the same problem. > > I haven't seen any similar questions go by and I am stuck. Any advice? > > My GDAL 3.12.3 cmake command looks like this: > > cmake \ > -DCMAKE_BUILD_TYPE=Release \ > -DCMAKE_C_COMPILER:FILEPATH=/usr/local/gcc132/bin/gcc \ > -DCMAKE_CXX_COMPILER:FILEPATH=/usr/local/gcc132/bin/g++ \ > -DCMAKE_POSITION_INDEPENDENT_CODE=ON \ > -DCMAKE_INSTALL_PREFIX=/usr/local/devlibs/gdal-3.12.3 \ > -DBUILD_JAVA_BINDINGS:BOOL=OFF \ > -DSQLite3_INCLUDE_DIR=/usr/local/devlibs/sqlite-3.51.3/include \ > -DSQLite3_LIBRARY=/usr/local/devlibs/sqlite-3.51.3/lib/libsqlite3.so \ > -DARCHIVE_INCLUDE_DIR=/usr/local/devlibs/libarchive-3.8.6/include \ > -DARCHIVE_LIBRARY=/usr/local/devlibs/libarchive-3.8.6/lib64/libarchive.so \ > -DCURL_INCLUDE_DIR=/usr/local/devlibs/curl-8.4.0/include \ > -DCURL_LIBRARY_RELEASE=/usr/local/devlibs/curl-8.4.0/lib64/libcurl.so \ > -DPROJ_INCLUDE_DIR=/usr/local/devlibs/proj-9.7.1/include \ > -DPROJ_LIBRARY_RELEASE=/usr/local/devlibs/proj-9.7.1/lib64/libproj.so \ > -DGDAL_USE_GEOTIFF_INTERNAL:BOOL=ON \ > -DGDAL_USE_WEBP_INTERNAL:BOOL=ON \ > -DMRSID_INCLUDE_DIR=/usr/local/devlibs/MrSID_DSDK-9.5.4.4709-rhel6.x86-64.gcc531/Raster_DSDK/include \ > -DMRSID_LIBRARY=/usr/local/devlibs/MrSID_DSDK-9.5.4.4709-rhel6.x86-64.gcc531/Raster_DSDK/lib/libltidsdk.so \ > -DGDAL_ENABLE_DRIVER_JP2MRSID=ON \ > .. > > and my PROJ 9.7.0 is pretty basic, and looks like this: > > cmake \ > -DCMAKE_BUILD_TYPE=Release \ > -Wno-dev -Wno-deprecated \ > -DCMAKE_C_COMPILER:FILEPATH=/usr/local/gcc132/bin/gcc \ > -DCMAKE_CXX_COMPILER:FILEPATH=/usr/local/gcc132/bin/g++ \ > -DCMAKE_POSITION_INDEPENDENT_CODE=ON \ > -DCMAKE_INSTALL_PREFIX=/usr/local/devlibs/proj-9.7.1 \ > .. > > Thank you very much, > > carl > _______________________________________________ > gdal-dev mailing list > gdal-dev at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Andrew Bell andrew.bell.ia at gmail.com From cgodkin at gmail.com Mon Apr 6 09:12:12 2026 From: cgodkin at gmail.com (Carl Godkin) Date: Mon, 6 Apr 2026 09:12:12 -0700 Subject: [gdal-dev] Trouble building GDAL 3.12.3 on Linux In-Reply-To: References: Message-ID: Hi Andrew, Thanks for the reply. The actual command is always hidden by cmake. (I am obviously not a cmake expert!) Is there a way to get it to reveal more? But this is what I see after typing "make" following the "cmake" command I posted earlier: [ 95%] Linking CXX executable test_ogrsf /net/raid1/home/local64-rhel8/gcc132-rhel8/bin/../lib/gcc/x86_64-pc-linux-gnu/13.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: ../libgdal.so.38.3.12.3: undefined reference to `proj_coordinate_metadata_create' /net/raid1/home/local64-rhel8/gcc132-rhel8/bin/../lib/gcc/x86_64-pc-linux-gnu/13.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: ../libgdal.so.38.3.12.3: undefined reference to `proj_crs_has_point_motion_operation' collect2: error: ld returned 1 exit status make[2]: *** [apps/CMakeFiles/test_ogrsf.dir/build.make:98: apps/test_ogrsf] Error 1 make[1]: *** [CMakeFiles/Makefile2:8644: apps/CMakeFiles/test_ogrsf.dir/all] Error 2 make: *** [Makefile:146: all] Error 2 The "link.txt" file from this build is this (i.e., linux64_build/apps/CMakeFiles/test_ogrsf.dir) /usr/local/gcc132/bin/g++ -fvisibility=hidden -O3 -DNDEBUG CMakeFiles/test_ogrsf.dir/test_ogrsf.cpp.o -o test_ogrsf -Wl,-rpath,/home/carl/build/gdal-3.12.3/linux64_build ../libgdal.so.38.3.12.3 Thanks, carl On Mon, Apr 6, 2026 at 8:47?AM Andrew Bell wrote: > Hi Carl, > > The actual build command from the failing step might be helpful. > > On Mon, Apr 6, 2026 at 11:33?AM Carl Godkin via gdal-dev > wrote: > > > > Hi, > > > > I'm updating our GDAL and other third party libraries. I'm usually > pretty adept at this but I am having a problem building GDAL 3.12.3 on > Linux RHEL8 with GCC 13.2. > > > > The shared library builds okay, but once we get to the apps, I am > getting undefined references to two PROJ functions > (proj_coordinate_metadata_create & proj_crs_has_point_motion_operation). > > > > I was struggling with this last Friday with PROJ 9.8.0 but, after this > weekend's advice about ETRS89, I switched to PROJ 9.7.1 where I'm having > the same problem. > > > > I haven't seen any similar questions go by and I am stuck. Any advice? > > > > My GDAL 3.12.3 cmake command looks like this: > > > > cmake \ > > -DCMAKE_BUILD_TYPE=Release \ > > -DCMAKE_C_COMPILER:FILEPATH=/usr/local/gcc132/bin/gcc \ > > -DCMAKE_CXX_COMPILER:FILEPATH=/usr/local/gcc132/bin/g++ \ > > -DCMAKE_POSITION_INDEPENDENT_CODE=ON \ > > -DCMAKE_INSTALL_PREFIX=/usr/local/devlibs/gdal-3.12.3 \ > > -DBUILD_JAVA_BINDINGS:BOOL=OFF \ > > -DSQLite3_INCLUDE_DIR=/usr/local/devlibs/sqlite-3.51.3/include \ > > -DSQLite3_LIBRARY=/usr/local/devlibs/sqlite-3.51.3/lib/libsqlite3.so \ > > -DARCHIVE_INCLUDE_DIR=/usr/local/devlibs/libarchive-3.8.6/include \ > > > -DARCHIVE_LIBRARY=/usr/local/devlibs/libarchive-3.8.6/lib64/libarchive.so \ > > -DCURL_INCLUDE_DIR=/usr/local/devlibs/curl-8.4.0/include \ > > -DCURL_LIBRARY_RELEASE=/usr/local/devlibs/curl-8.4.0/lib64/libcurl.so > \ > > -DPROJ_INCLUDE_DIR=/usr/local/devlibs/proj-9.7.1/include \ > > -DPROJ_LIBRARY_RELEASE=/usr/local/devlibs/proj-9.7.1/lib64/libproj.so > \ > > -DGDAL_USE_GEOTIFF_INTERNAL:BOOL=ON \ > > -DGDAL_USE_WEBP_INTERNAL:BOOL=ON \ > > > -DMRSID_INCLUDE_DIR=/usr/local/devlibs/MrSID_DSDK-9.5.4.4709-rhel6.x86-64.gcc531/Raster_DSDK/include > \ > > > -DMRSID_LIBRARY=/usr/local/devlibs/MrSID_DSDK-9.5.4.4709-rhel6.x86-64.gcc531/Raster_DSDK/lib/libltidsdk.so > \ > > -DGDAL_ENABLE_DRIVER_JP2MRSID=ON \ > > .. > > > > and my PROJ 9.7.0 is pretty basic, and looks like this: > > > > cmake \ > > -DCMAKE_BUILD_TYPE=Release \ > > -Wno-dev -Wno-deprecated \ > > -DCMAKE_C_COMPILER:FILEPATH=/usr/local/gcc132/bin/gcc \ > > -DCMAKE_CXX_COMPILER:FILEPATH=/usr/local/gcc132/bin/g++ \ > > -DCMAKE_POSITION_INDEPENDENT_CODE=ON \ > > -DCMAKE_INSTALL_PREFIX=/usr/local/devlibs/proj-9.7.1 \ > > .. > > > > Thank you very much, > > > > carl > > _______________________________________________ > > gdal-dev mailing list > > gdal-dev at lists.osgeo.org > > https://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > -- > Andrew Bell > andrew.bell.ia at gmail.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastic at xs4all.nl Mon Apr 6 09:28:07 2026 From: sebastic at xs4all.nl (Sebastiaan Couwenberg) Date: Mon, 6 Apr 2026 18:28:07 +0200 Subject: [gdal-dev] Trouble building GDAL 3.12.3 on Linux In-Reply-To: References: Message-ID: On 4/6/26 6:12 PM, Carl Godkin via gdal-dev wrote: > Thanks for the reply. The actual command is always hidden by cmake. (I > am obviously not a cmake expert!) Is there a way to get it to reveal more? -DCMAKE_VERBOSE_MAKEFILE=ON https://cmake.org/cmake/help/latest/variable/CMAKE_VERBOSE_MAKEFILE.html Kind Regards, Bas -- PGP Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 From cgodkin at gmail.com Mon Apr 6 09:42:15 2026 From: cgodkin at gmail.com (Carl Godkin) Date: Mon, 6 Apr 2026 09:42:15 -0700 Subject: [gdal-dev] Trouble building GDAL 3.12.3 on Linux In-Reply-To: References: Message-ID: Thanks to Seabastiaan's advice, I've rerun the cmake command and now the "make" gives this for the failing step: [ 95%] Linking CXX executable test_ogrsf cd /home/carl/build/gdal-3.12.3/linux64_build/apps && /usr/bin/cmake -E cmake_link_script CMakeFiles/test_ogrsf.dir/link.txt --verbose=1 /usr/local/gcc132/bin/g++ -fvisibility=hidden -O3 -DNDEBUG CMakeFiles/test_ogrsf.dir/test_ogrsf.cpp.o -o test_ogrsf -Wl,-rpath,/home/carl/build/gdal-3.12.3/linux64_build ../libgdal.so.38.3.12.3 /net/raid1/home/local64-rhel8/gcc132-rhel8/bin/../lib/gcc/x86_64-pc-linux-gnu/13.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: ../libgdal.so.38.3.12.3: undefined reference to `proj_coordinate_metadata_create' /net/raid1/home/local64-rhel8/gcc132-rhel8/bin/../lib/gcc/x86_64-pc-linux-gnu/13.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: ../libgdal.so.38.3.12.3: undefined reference to `proj_crs_has_point_motion_operation' collect2: error: ld returned 1 exit status make[2]: *** [apps/CMakeFiles/test_ogrsf.dir/build.make:101: apps/test_ogrsf] Error 1 make[2]: Leaving directory '/home/carl/build/gdal-3.12.3/linux64_build' make[1]: *** [CMakeFiles/Makefile2:8647: apps/CMakeFiles/test_ogrsf.dir/all] Error 2 make[1]: Leaving directory '/home/carl/build/gdal-3.12.3/linux64_build' make: *** [Makefile:149: all] Error 2 Does that help? Thanks a lot, carl On Mon, Apr 6, 2026 at 9:28?AM Sebastiaan Couwenberg wrote: > On 4/6/26 6:12 PM, Carl Godkin via gdal-dev wrote: > > Thanks for the reply. The actual command is always hidden by cmake. (I > > am obviously not a cmake expert!) Is there a way to get it to reveal > more? > > -DCMAKE_VERBOSE_MAKEFILE=ON > > https://cmake.org/cmake/help/latest/variable/CMAKE_VERBOSE_MAKEFILE.html > > Kind Regards, > > Bas > > -- > PGP Key ID: 4096R/6750F10AE88D4AF1 > Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.bell.ia at gmail.com Mon Apr 6 10:50:49 2026 From: andrew.bell.ia at gmail.com (Andrew Bell) Date: Mon, 6 Apr 2026 13:50:49 -0400 Subject: [gdal-dev] Trouble building GDAL 3.12.3 on Linux In-Reply-To: References: Message-ID: Hi, You need to make sure that the reference to the proj library that's in libgdal can be found at link time for the test_ogrsf executable. You can do this by setting LD_LIBRARY_PATH environment variable to the directory containing the relevant proj library. You could also edit the link line to include a reference to that directory (see the -rpath-link option). I would think that an RPATH entry would be created in the GDAL library when it's built, which would take care of this, but I'm not sure why this wouldn't be happening without a bunch of investigation. This might be helpful: https://www.kaizou.org/2015/01/linux-libraries.html On Mon, Apr 6, 2026 at 12:42?PM Carl Godkin via gdal-dev wrote: > > Thanks to Seabastiaan's advice, I've rerun the cmake command and now the "make" gives this for the failing step: > > [ 95%] Linking CXX executable test_ogrsf > cd /home/carl/build/gdal-3.12.3/linux64_build/apps && /usr/bin/cmake -E cmake_link_script CMakeFiles/test_ogrsf.dir/link.txt --verbose=1 > /usr/local/gcc132/bin/g++ -fvisibility=hidden -O3 -DNDEBUG CMakeFiles/test_ogrsf.dir/test_ogrsf.cpp.o -o test_ogrsf -Wl,-rpath,/home/carl/build/gdal-3.12.3/linux64_build ../libgdal.so.38.3.12.3 > /net/raid1/home/local64-rhel8/gcc132-rhel8/bin/../lib/gcc/x86_64-pc-linux-gnu/13.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: ../libgdal.so.38.3.12.3: undefined reference to `proj_coordinate_metadata_create' > /net/raid1/home/local64-rhel8/gcc132-rhel8/bin/../lib/gcc/x86_64-pc-linux-gnu/13.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: ../libgdal.so.38.3.12.3: undefined reference to `proj_crs_has_point_motion_operation' > collect2: error: ld returned 1 exit status > make[2]: *** [apps/CMakeFiles/test_ogrsf.dir/build.make:101: apps/test_ogrsf] Error 1 > make[2]: Leaving directory '/home/carl/build/gdal-3.12.3/linux64_build' > make[1]: *** [CMakeFiles/Makefile2:8647: apps/CMakeFiles/test_ogrsf.dir/all] Error 2 > make[1]: Leaving directory '/home/carl/build/gdal-3.12.3/linux64_build' > make: *** [Makefile:149: all] Error 2 > > Does that help? Thanks a lot, > > carl > > > On Mon, Apr 6, 2026 at 9:28?AM Sebastiaan Couwenberg wrote: >> >> On 4/6/26 6:12 PM, Carl Godkin via gdal-dev wrote: >> > Thanks for the reply. The actual command is always hidden by cmake. (I >> > am obviously not a cmake expert!) Is there a way to get it to reveal more? >> >> -DCMAKE_VERBOSE_MAKEFILE=ON >> >> https://cmake.org/cmake/help/latest/variable/CMAKE_VERBOSE_MAKEFILE.html >> >> Kind Regards, >> >> Bas >> >> -- >> PGP Key ID: 4096R/6750F10AE88D4AF1 >> Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 > > _______________________________________________ > gdal-dev mailing list > gdal-dev at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Andrew Bell andrew.bell.ia at gmail.com From cgodkin at gmail.com Mon Apr 6 11:15:31 2026 From: cgodkin at gmail.com (Carl Godkin) Date: Mon, 6 Apr 2026 11:15:31 -0700 Subject: [gdal-dev] Trouble building GDAL 3.12.3 on Linux In-Reply-To: References: Message-ID: Hi everyone, OF COURSE that was the problem. I wonder why I've never run into this problem in the past. But maybe the undefined references were not in the previous PROJ (which was in my LD_LIBRARY_PATH). I'm all set now. Thanks VERY much, carl On Mon, Apr 6, 2026 at 10:51?AM Andrew Bell wrote: > Hi, > > You need to make sure that the reference to the proj library that's in > libgdal can be found at link time for the test_ogrsf executable. You > can do this by setting LD_LIBRARY_PATH environment variable to the > directory containing the relevant proj library. You could also edit > the link line to include a reference to that directory (see the > -rpath-link option). I would think that an RPATH entry would be > created in the GDAL library when it's built, which would take care of > this, but I'm not sure why this wouldn't be happening without a bunch > of investigation. > > This might be helpful: > > https://www.kaizou.org/2015/01/linux-libraries.html > > On Mon, Apr 6, 2026 at 12:42?PM Carl Godkin via gdal-dev > wrote: > > > > Thanks to Seabastiaan's advice, I've rerun the cmake command and now the > "make" gives this for the failing step: > > > > [ 95%] Linking CXX executable test_ogrsf > > cd /home/carl/build/gdal-3.12.3/linux64_build/apps && /usr/bin/cmake -E > cmake_link_script CMakeFiles/test_ogrsf.dir/link.txt --verbose=1 > > /usr/local/gcc132/bin/g++ -fvisibility=hidden -O3 -DNDEBUG > CMakeFiles/test_ogrsf.dir/test_ogrsf.cpp.o -o test_ogrsf > -Wl,-rpath,/home/carl/build/gdal-3.12.3/linux64_build > ../libgdal.so.38.3.12.3 > > > /net/raid1/home/local64-rhel8/gcc132-rhel8/bin/../lib/gcc/x86_64-pc-linux-gnu/13.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: > ../libgdal.so.38.3.12.3: undefined reference to > `proj_coordinate_metadata_create' > > > /net/raid1/home/local64-rhel8/gcc132-rhel8/bin/../lib/gcc/x86_64-pc-linux-gnu/13.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: > ../libgdal.so.38.3.12.3: undefined reference to > `proj_crs_has_point_motion_operation' > > collect2: error: ld returned 1 exit status > > make[2]: *** [apps/CMakeFiles/test_ogrsf.dir/build.make:101: > apps/test_ogrsf] Error 1 > > make[2]: Leaving directory '/home/carl/build/gdal-3.12.3/linux64_build' > > make[1]: *** [CMakeFiles/Makefile2:8647: > apps/CMakeFiles/test_ogrsf.dir/all] Error 2 > > make[1]: Leaving directory '/home/carl/build/gdal-3.12.3/linux64_build' > > make: *** [Makefile:149: all] Error 2 > > > > Does that help? Thanks a lot, > > > > carl > > > > > > On Mon, Apr 6, 2026 at 9:28?AM Sebastiaan Couwenberg > wrote: > >> > >> On 4/6/26 6:12 PM, Carl Godkin via gdal-dev wrote: > >> > Thanks for the reply. The actual command is always hidden by > cmake. (I > >> > am obviously not a cmake expert!) Is there a way to get it to reveal > more? > >> > >> -DCMAKE_VERBOSE_MAKEFILE=ON > >> > >> > https://cmake.org/cmake/help/latest/variable/CMAKE_VERBOSE_MAKEFILE.html > >> > >> Kind Regards, > >> > >> Bas > >> > >> -- > >> PGP Key ID: 4096R/6750F10AE88D4AF1 > >> Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 > > > > _______________________________________________ > > gdal-dev mailing list > > gdal-dev at lists.osgeo.org > > https://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > -- > Andrew Bell > andrew.bell.ia at gmail.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Thu Apr 9 10:54:08 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Thu, 9 Apr 2026 19:54:08 +0200 Subject: [gdal-dev] Integrating AI assisted code review for PR in OSGeo/GDAL? In-Reply-To: <9a74143e-3fcd-4c18-b229-be9afb55d2b4@spatialys.com> References: <9a74143e-3fcd-4c18-b229-be9afb55d2b4@spatialys.com> Message-ID: <8bf568e3-2252-4e69-8c42-2c9569cc45ca@spatialys.com> Hi, I went ahead and enabled Gemini code assist in the repo. It should (hopefully) triggers?only?if you type "/gemini review" in a PR comment. It is enabled for issues at Medium or High priority. Let's see how it goes Even Le 02/04/2026 ? 15:42, Even Rouault via gdal-dev a ?crit?: > Hi, > > I think it could be worth to have the *possibility* of requiring an AI > assisted review for pull requests, directly available from our > canonical repo. I've been occasionaly experimenting Gemini Code Assist > and Copilot in my personal fork. Copilot had repeated failures a few > weeks ago but seems to have been fixed recently, so I've more > experience with /gemini review. I find it useful and it has spotted > real issues, some of them would have probably went unnoticed during > classic human review, and with an acceptable rate of false positives > or debatable remarks. > > So my proposal would be to have the tool(s)? enabled in OSGeo/GDAL > repo, *on demand* (not sure if that's possible for Copilot. Is that a > setting? Although I'm not trusting github enough to be sure if we want > to increase our use of it.? Gemini review is definitely on demand and > an external github app we can disable in one click) for developers or > reviewers that want to trigger them. I don't think having them to run > systematically is a good idea, because some PRs are too trivial to get > any benefit from them, and having them enabled systematically lead to > noise as PR comments and notifications. > > I definitely don't think those tools should replace human review. AI > tools are instructed to flatter your ego and will never say your PR is > a bad idea, which a human reviewer will occasionally say. Or they lack > the global picture, etc. I see them as additional tools on top of our > CI instrumentation and human review. > > Anyone with experience in that area and thoughts? > > Even > -- http://www.spatialys.com My software is free, but my time generally not. From even.rouault at spatialys.com Fri Apr 10 06:12:16 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Fri, 10 Apr 2026 15:12:16 +0200 Subject: [gdal-dev] PROJ 9.8.1 is released Message-ID: It?s my pleasure to announce the release of PROJ 9.8.1! The release includes a few updates, bug fixes and a major regression fix for ETRS89-related coordinates operations. See the release notes below. Download the archives here: https://download.osgeo.org/proj/proj-9.8.1.tar.gz https://download.osgeo.org/proj/proj-9.8.1.zip /Even ## 9.8.1 ### Warning It was discovered after the PROJ 9.8.0 release that several EPSG updates introduced after EPSG v12.033 - notably the introduction of national realizations of ETRS89 (ETRS89-XXX [?] where XXX is the 3-letter ISO country code) - caused backward incompatibilities in some workflows involving the ETRS89 CRS. In particular, transformations between ETRS89 and national CRSs based on other datums are known to be affected for Austria, Belgium, Catalonia, the Netherlands, Romania, and Serbia. See #4736 for more details. While we intend to resume tracking the latest EPSG releases in future PROJ versions, the safest solution identified so far to address these regressions is to **revert the EPSG related content of its database from EPSG v12.049 to v12.029**, where v12.029 was the version distributed with PROJ 9.7.1 As a consequence of this revert, the EPSG datum and CRS records introduced in PROJ 9.8.0, which are mostly related to the new ETRS89-XXX datum and CRS, are no longer available in PROJ 9.8.1. ### Updates * Database: **Revert content from EPSG v12.049 to v12.029** (#4741). ? See above warning for more details. * CMake: handle deprecated SQLite::SQLite3 target in CMake 4.3 (#4694) ### Bug Fixes * Make sure that epoch is set in more scenarios of time-dependent transformations (#4688) * pj_obj_create: use database context if already open for grid name resolution (#4703) * Chain vertical CRS transformations through intermediate same-datum vertical CRS (#4711) ? Helps for example for **EPSG:5705** (Baltic 1977 height) to **EPSG:5706** (Caspian depth) ? by using intermediate operation from Baltic 1977 height to Caspian *height* * gie: various fixes around crs_src/crs_dst support and bootstrap ? test/gie/epsg_grid.gie and test/gie/epsg_no_grid.gie (#4740) -- http://www.spatialys.com My software is free, but my time generally not. From michael.smith.erdc at gmail.com Sat Apr 11 06:20:02 2026 From: michael.smith.erdc at gmail.com (Michael Smith) Date: Sat, 11 Apr 2026 09:20:02 -0400 Subject: [gdal-dev] Parquet error/warning on large list columns Message-ID: In our stac geoparquet files, we are getting warning/errors (depending on cli vs python) on unhandled type:large list Warning 1: Field proj.shape of unhandled type large_list ignored Warning 1: Field stac_extensions of unhandled type large_list ignored Or GDAL_ERROR 1: b'Field stac_extensions of unhandled type large_list ignored' I?m using polars and pyogrio (polars-st) to write the data and the schema is defined as extensionschema = pl.List(pl.Utf8) proj.shape = pl.List(pl.Int64) The columns are not reported in the column list and are not present when converting the data to another parquet file. This is GDAL 3.12.3 "Chicoutimi", released 2026/03/17 installed via conda forge. -- Michael Smith RSGIS Center ? ERDC CRREL NH US Army Corps -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Sat Apr 11 06:56:38 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Sat, 11 Apr 2026 15:56:38 +0200 Subject: [gdal-dev] Parquet error/warning on large list columns In-Reply-To: References: Message-ID: Hi Mike, fix in https://github.com/OSGeo/gdal/pull/14326 Even Le 11/04/2026 ? 15:20, Michael Smith via gdal-dev a ?crit?: > > In our stac geoparquet files, we are getting warning/errors (depending > on cli vs python) on unhandled type:large list > > Warning 1: Field proj.shape of unhandled type large_list int64> ignored > > Warning 1: Field stac_extensions of unhandled type large_list large_string> ignored > > Or > > GDAL_ERROR 1: b'Field stac_extensions of unhandled type > large_list ignored' > > I?m using polars and pyogrio (polars-st) to write the data and the > schema is defined as > > extensionschema = pl.List(pl.Utf8) > > proj.shape = pl.List(pl.Int64) > > The columns are not reported in the column list and are not present > when converting the data to another parquet file. > > This is GDAL 3.12.3 "Chicoutimi", released 2026/03/17 installed via > conda forge. > > -- > > Michael Smith > > RSGIS Center ? ERDC CRREL NH > > US Army Corps > > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Sun Apr 12 12:48:52 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Sun, 12 Apr 2026 21:48:52 +0200 Subject: [gdal-dev] AI/LLM tool policy: failure Message-ID: <36ac03e6-c1df-4468-b6ec-9e927ee703ab@spatialys.com> Hi, It was nice trying but I believe we can close the experiment as a failure. At least I personally cannot deal with the mental consequences in term of reviewing. To make it short, I believe humans aren't designed to be at the receiving end of LLM generated content. This is a too unnatural relationship. More details in this thread: https://lists.osgeo.org/pipermail/qgis-developer/2026-April/068204.html So what to do now... ? Personally I believe I'll give up on reviewing LLM generated PRs. If there are other devs with merge rights who want to give them a try, please raise your arm. Otherwise, if there are not, we'll have to revise the policy to better reflect our wishes and abilities. Even -- http://www.spatialys.com My software is free, but my time generally not. From j1 at jimenezshaw.com Mon Apr 13 02:46:16 2026 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Mon, 13 Apr 2026 11:46:16 +0200 Subject: [gdal-dev] AI/LLM tool policy: failure In-Reply-To: <36ac03e6-c1df-4468-b6ec-9e927ee703ab@spatialys.com> References: <36ac03e6-c1df-4468-b6ec-9e927ee703ab@spatialys.com> Message-ID: Thanks Even. I found the previous AI policy too na?ve. I am totally fine with a much more strict policy. As you and other people explained, the situation PR-producer vs reviewer is completely unbalanced with AI. Cheers Javier On Sun, 12 Apr 2026 at 21:49, Even Rouault via gdal-dev < gdal-dev at lists.osgeo.org> wrote: > Hi, > > It was nice trying but I believe we can close the experiment as a > failure. At least I personally cannot deal with the mental consequences > in term of reviewing. To make it short, I believe humans aren't designed > to be at the receiving end of LLM generated content. This is a too > unnatural relationship. More details in this thread: > https://lists.osgeo.org/pipermail/qgis-developer/2026-April/068204.html > > So what to do now... ? Personally I believe I'll give up on reviewing > LLM generated PRs. If there are other devs with merge rights who want to > give them a try, please raise your arm. Otherwise, if there are not, > we'll have to revise the policy to better reflect our wishes and abilities. > > Even > > -- > http://www.spatialys.com > My software is free, but my time generally not. > > _______________________________________________ > 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: From even.rouault at spatialys.com Wed Apr 15 04:05:45 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 15 Apr 2026 13:05:45 +0200 Subject: [gdal-dev] Code name for 3.13.0 ? Message-ID: <0c50729c-5498-4a38-88e9-1e1d3c91881d@spatialys.com> Hi, we don't have a code name yet for GDAL 3.13.0. Happy to hear suggestions Random ideas jumping in my head from recent news: - "Parsecs accepted" (*) - Full moon joy" Even (*) for those who don't have followed Artemis live stream,?reference to astronauts making fun of Houston communicating distances in miles... -- http://www.spatialys.com My software is free, but my time generally not. Highly recommend OxiGDAL if you want to live in the 21th century and cure Bixonimania From joana at doublebyte.net Wed Apr 15 04:58:09 2026 From: joana at doublebyte.net (Joana Simoes) Date: Wed, 15 Apr 2026 12:58:09 +0100 Subject: [gdal-dev] =?utf-8?q?Registrations_open_for_the_next_OGC_Code_Sp?= =?utf-8?b?cmludCDwn5Oj?= Message-ID: <6cd94c59-7402-4a1e-82a5-87ac319f745a@doublebyte.net> Good morning, The OGC "Builder Days" will take place at Geovation , London (UK), on May 11-13.? This?will be a collaborative and inclusive event to support the development of OpenStandards?and applications implementing?those standards./Non-coding activities such as testing, working on //documentation//?or reporting issues are welcome?and encouraged?during the?Sprint/. Code Sprints also provide?an opportunity to onboard those who are new to the standards, through the sprint?s mentor stream . This sprint focuses on three key topics, although participants are welcome to work on other Standards: * The GEOINT Imagery Media for Intelligence, Surveillance, and Reconnaissance (GIMI) standard. * The development of a JSON encoding for the Geoscience Markup Language (GeoSciML) standard. * The 3D Tiles community standard and glTF - the primary tile format of 3D Tiles. Registration for onsite and remote participation is now live at: https://events.ogc.org/OGCBuilderDaysCodeSprint#/?lang=en Thanks to our sponsors , prospective participants can apply for funding to offset their travel costs. ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Looking forward to meeting you at the event, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? All the Best, Joana -- This email was not written using AI. Apologies for the conciseness. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.smith.erdc at gmail.com Wed Apr 15 05:36:25 2026 From: michael.smith.erdc at gmail.com (Michael Smith) Date: Wed, 15 Apr 2026 08:36:25 -0400 Subject: [gdal-dev] Code name for 3.13.0 ? In-Reply-To: <0c50729c-5498-4a38-88e9-1e1d3c91881d@spatialys.com> References: <0c50729c-5498-4a38-88e9-1e1d3c91881d@spatialys.com> Message-ID: <15090DD4-8002-4417-897E-0E3BEF47D0CA@gmail.com> Not going with hometowns of significant developers? Mike -- Michael Smith RSGIS Center ? ERDC CRREL NH US Army Corps ?On 4/15/26, 7:10 AM, "gdal-dev on behalf of Even Rouault via gdal-dev" on behalf of gdal-dev at lists.osgeo.org > wrote: Hi, we don't have a code name yet for GDAL 3.13.0. Happy to hear suggestions Random ideas jumping in my head from recent news: - "Parsecs accepted" (*) - Full moon joy" Even (*) for those who don't have followed Artemis live stream, reference to astronauts making fun of Houston communicating distances in miles... -- http://www.spatialys.com My software is free, but my time generally not. Highly recommend OxiGDAL if you want to live in the 21th century and cure Bixonimania _______________________________________________ gdal-dev mailing list gdal-dev at lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev From even.rouault at spatialys.com Wed Apr 15 05:41:49 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 15 Apr 2026 14:41:49 +0200 Subject: [gdal-dev] Code name for 3.13.0 ? In-Reply-To: <15090DD4-8002-4417-897E-0E3BEF47D0CA@gmail.com> References: <0c50729c-5498-4a38-88e9-1e1d3c91881d@spatialys.com> <15090DD4-8002-4417-897E-0E3BEF47D0CA@gmail.com> Message-ID: <98597b7f-faf0-47a3-8246-ed02b355598a@spatialys.com> The next names on his list are unknown to me / don't know how to reach them. Le 15/04/2026 ? 14:36, Michael Smith a ?crit?: > Not going with hometowns of significant developers? > > Mike > -- http://www.spatialys.com My software is free, but my time generally not. Highly recommend OxiGDAL if you want to live in the 21th century and cure Bixonimania From michael.smith.erdc at gmail.com Wed Apr 15 05:55:47 2026 From: michael.smith.erdc at gmail.com (Michael Smith) Date: Wed, 15 Apr 2026 08:55:47 -0400 Subject: [gdal-dev] Code name for 3.13.0 ? In-Reply-To: <98597b7f-faf0-47a3-8246-ed02b355598a@spatialys.com> References: <0c50729c-5498-4a38-88e9-1e1d3c91881d@spatialys.com> <15090DD4-8002-4417-897E-0E3BEF47D0CA@gmail.com> <98597b7f-faf0-47a3-8246-ed02b355598a@spatialys.com> Message-ID: Filter by still active developers? Iowa City? Mike -- Michael Smith RSGIS Center ? ERDC CRREL NH US Army Corps ?On 4/15/26, 8:41 AM, "Even Rouault" > wrote: The next names on his list are unknown to me / don't know how to reach them. Le 15/04/2026 ? 14:36, Michael Smith a ?crit : > Not going with hometowns of significant developers? > > Mike > -- http://www.spatialys.com My software is free, but my time generally not. Highly recommend OxiGDAL if you want to live in the 21th century and cure Bixonimania From ijturton at gmail.com Wed Apr 15 06:19:15 2026 From: ijturton at gmail.com (Ian Turton) Date: Wed, 15 Apr 2026 14:19:15 +0100 Subject: [gdal-dev] Code name for 3.13.0 ? In-Reply-To: <0c50729c-5498-4a38-88e9-1e1d3c91881d@spatialys.com> References: <0c50729c-5498-4a38-88e9-1e1d3c91881d@spatialys.com> Message-ID: There's always Sara Safavi's release-namer which will give you random names like Able Aarakocra or Common-Kissing Clotpole https://github.com/sarasafavi/release-namer Ian On Wed, 15 Apr 2026 at 12:10, Even Rouault via gdal-dev < gdal-dev at lists.osgeo.org> wrote: > Hi, > > we don't have a code name yet for GDAL 3.13.0. Happy to hear suggestions > > Random ideas jumping in my head from recent news: > > - "Parsecs accepted" (*) > > - Full moon joy" > > Even > > (*) for those who don't have followed Artemis live stream, reference to > astronauts making fun of Houston communicating distances in miles... > > -- > http://www.spatialys.com > My software is free, but my time generally not. > Highly recommend OxiGDAL if you want to live in the 21th century and cure > Bixonimania > > _______________________________________________ > gdal-dev mailing list > gdal-dev at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > -- Ian Turton -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Wed Apr 15 06:31:22 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 15 Apr 2026 15:31:22 +0200 Subject: [gdal-dev] Code name for 3.13.0 ? In-Reply-To: References: <0c50729c-5498-4a38-88e9-1e1d3c91881d@spatialys.com> <15090DD4-8002-4417-897E-0E3BEF47D0CA@gmail.com> <98597b7f-faf0-47a3-8246-ed02b355598a@spatialys.com> Message-ID: <33d30dfe-9184-4bf6-8d49-642267226a57@spatialys.com> Thanks. let's go for Iowa City Le 15/04/2026 ? 14:55, Michael Smith a ?crit?: > Filter by still active developers? Iowa City? > > Mike > > -- http://www.spatialys.com My software is free, but my time generally not. Highly recommend OxiGDAL if you want to live in the 21th century and cure Bixonimania From howard at hobu.co Wed Apr 15 06:54:11 2026 From: howard at hobu.co (Howard Butler) Date: Wed, 15 Apr 2026 08:54:11 -0500 Subject: [gdal-dev] Code name for 3.13.0 ? In-Reply-To: <33d30dfe-9184-4bf6-8d49-642267226a57@spatialys.com> References: <0c50729c-5498-4a38-88e9-1e1d3c91881d@spatialys.com> <15090DD4-8002-4417-897E-0E3BEF47D0CA@gmail.com> <98597b7f-faf0-47a3-8246-ed02b355598a@spatialys.com> <33d30dfe-9184-4bf6-8d49-642267226a57@spatialys.com> Message-ID: um, I thought we were doing *in order*, and according to that, I would be quite a bit down the list. Maybe Valient is still following the mailing list and could provide his geography > Frank Warmerdam > Daniel Morissette > Valient Gough > Sylvain Rioux > Ken Shih > git log --reverse --use-mailmap --format='%aN%x09%aE' | awk -F '\t' 'function v(e,l){l=tolower(e);return e ~ /^[[:alnum:].!#$%&*+\/=?^_{|}~-]+@[[:alnum:]-]+(\.[[:alnum:]-]+)+$/ && l !~ /(^|@)(unknown|invalid)(\.|@|$)|not-a-valid-email|fakeisthenewreal/} !s[$1]++{print v($2)?$1" <"$2">":$1}' > On Apr 15, 2026, at 8:31?AM, Even Rouault via gdal-dev wrote: > > Thanks. let's go for Iowa City > > Le 15/04/2026 ? 14:55, Michael Smith a ?crit : >> Filter by still active developers? Iowa City? >> >> Mike >> >> > -- > http://www.spatialys.com > My software is free, but my time generally not. > Highly recommend OxiGDAL if you want to live in the 21th century and cure Bixonimania > > _______________________________________________ > gdal-dev mailing list > gdal-dev at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev From mdsumner at gmail.com Wed Apr 15 07:07:32 2026 From: mdsumner at gmail.com (Michael Sumner) Date: Thu, 16 Apr 2026 00:07:32 +1000 Subject: [gdal-dev] Code name for 3.13.0 ? In-Reply-To: References: <0c50729c-5498-4a38-88e9-1e1d3c91881d@spatialys.com> <15090DD4-8002-4417-897E-0E3BEF47D0CA@gmail.com> <98597b7f-faf0-47a3-8246-ed02b355598a@spatialys.com> <33d30dfe-9184-4bf6-8d49-642267226a57@spatialys.com> Message-ID: Two Outlooks On Wed, Apr 15, 2026 at 11:54?PM Howard Butler via gdal-dev < gdal-dev at lists.osgeo.org> wrote: > um, I thought we were doing *in order*, and according to that, I would be > quite a bit down the list. Maybe Valient is still following the mailing > list and could provide his geography > > > Frank Warmerdam > > Daniel Morissette > > Valient Gough > > Sylvain Rioux > > Ken Shih > > > > git log --reverse --use-mailmap --format='%aN%x09%aE' | awk -F '\t' > 'function v(e,l){l=tolower(e);return e ~ > /^[[:alnum:].!#$%&*+\/=?^_{|}~-]+@[[:alnum:]-]+(\.[[:alnum:]-]+)+$/ && l !~ > /(^|@)(unknown|invalid)(\.|@|$)|not-a-valid-email|fakeisthenewreal/} > !s[$1]++{print v($2)?$1" <"$2">":$1}' > > > > > On Apr 15, 2026, at 8:31?AM, Even Rouault via gdal-dev < > gdal-dev at lists.osgeo.org> wrote: > > > > Thanks. let's go for Iowa City > > > > Le 15/04/2026 ? 14:55, Michael Smith a ?crit : > >> Filter by still active developers? Iowa City? > >> > >> Mike > >> > >> > > -- > > http://www.spatialys.com > > My software is free, but my time generally not. > > Highly recommend OxiGDAL if you want to live in the 21th century and > cure Bixonimania > > > > _______________________________________________ > > 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 Sumner Ordinary Member, Streets People Love Hobart Association Research Software Engineer Australian Antarctic Division Hobart, Australia 0438489030 e-mail: mdsumner at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From joep.keijsers at sogelink.com Wed Apr 15 07:53:51 2026 From: joep.keijsers at sogelink.com (Joep Keijsers) Date: Wed, 15 Apr 2026 14:53:51 +0000 Subject: [gdal-dev] ExportToGML with compound CRS Message-ID: Greetings, I'm trying to export a geometry object to GML using the Python API. The geometry has a compound CRS (EPSG:5973). When exporting to GML, the vertical component of the compound CRS is dropped, although the Z-values are still there.?For example: from osgeo import ogr, osr # Create geometry from WKT string srs = osr.SpatialReference() srs.ImportFromEPSG(5973) wkt = "POINT (30 10 5)" geometry = ogr.CreateGeometryFromWkt(wkt, srs) # Export to GML xml = geometry.ExportToGML(options=['FORMAT=GML32', 'SRSDIMENSION_LOC=GEOMETRY', 'SRSNAME_FORMAT=SHORT', 'GMLID=TestPoint-1']) print(xml) ... which returns EPSG:11023 instead of EPSG:5973: 30 10 5 I believe this EPSG code change happens in this line: https://github.com/OSGeo/gdal/blob/30e7918f245022983d84f93f1a53641fd50337ed/ogr/ogr2gmlgeometry.cpp#L562. Is there a way to keep the compound CRS in the GML output? Version info: gdal 3.12.3? Thanks! Joep ? From even.rouault at spatialys.com Wed Apr 15 08:25:02 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 15 Apr 2026 17:25:02 +0200 Subject: [gdal-dev] ExportToGML with compound CRS In-Reply-To: References: Message-ID: <9bbdfaff-7d7b-4b5c-b2bb-e63cb5819bc8@spatialys.com> Hi, no other workaround but applying https://github.com/OSGeo/gdal/pull/14367 (or post patching the output) Even Le 15/04/2026 ? 16:53, Joep Keijsers via gdal-dev a ?crit?: > Greetings, > > I'm trying to export a geometry object to GML using the Python API. The geometry has a compound CRS (EPSG:5973). When exporting to GML, the vertical component of the compound CRS is dropped, although the Z-values are still there.?For example: > > from osgeo import ogr, osr > > # Create geometry from WKT string > srs = osr.SpatialReference() > srs.ImportFromEPSG(5973) > wkt = "POINT (30 10 5)" > geometry = ogr.CreateGeometryFromWkt(wkt, srs) > > # Export to GML > xml = geometry.ExportToGML(options=['FORMAT=GML32', 'SRSDIMENSION_LOC=GEOMETRY', 'SRSNAME_FORMAT=SHORT', 'GMLID=TestPoint-1']) > print(xml) > > ... which returns EPSG:11023 instead of EPSG:5973: > > 30 10 5 > > I believe this EPSG code change happens in this line: https://github.com/OSGeo/gdal/blob/30e7918f245022983d84f93f1a53641fd50337ed/ogr/ogr2gmlgeometry.cpp#L562. > > Is there a way to keep the compound CRS in the GML output? > > Version info: gdal 3.12.3 > > Thanks! > > Joep > > > _______________________________________________ > 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. Highly recommend OxiGDAL if you want to live in the 21th century and cure Bixonimania From jukka.rahkonen at maanmittauslaitos.fi Wed Apr 15 08:28:41 2026 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka) Date: Wed, 15 Apr 2026 15:28:41 +0000 Subject: [gdal-dev] ExportToGML with compound CRS In-Reply-To: <9bbdfaff-7d7b-4b5c-b2bb-e63cb5819bc8@spatialys.com> References: <9bbdfaff-7d7b-4b5c-b2bb-e63cb5819bc8@spatialys.com> Message-ID: Hi Even made a fix already but here is a command for testing with the old school CLI. ogr2ogr -f gml -a_srs EPSG:5973 compound.gml :memory: -sql "select 1 as id, st_geomfromtext('POINTZ (1 1 1)') as geom" -nln test "boundedBy" seems to receive srsName="urn:ogc:def:crs:EPSG::5973 but the geometry itself srsName="urn:ogc:def:crs:EPSG::11023" -Jukka Rahkonen- ________________________________________ L?hett?j?: gdal-dev k?ytt?j?n Even Rouault via gdal-dev puolesta L?hetetty: Keskiviikko 15. huhtikuuta 2026 18.25 Vastaanottaja: Joep Keijsers ; gdal-dev at lists.osgeo.org Aihe: Re: [gdal-dev] ExportToGML with compound CRS HUOM! Ulkoinen l?hett?j?. ?l? avaa linkkej? tai liitteit?, ellet tunnista l?hett?j??. OBS! Extern avs?ndare. ?ppna inte l?nkar eller bilagor om du inte k?nner igen avs?ndaren. NOTE! External sender. Do not open links or attachments unless you recognize the sender. Hi, no other workaround but applying https://github.com/OSGeo/gdal/pull/14367 (or post patching the output) Even Le 15/04/2026 ? 16:53, Joep Keijsers via gdal-dev a ?crit : > Greetings, > > I'm trying to export a geometry object to GML using the Python API. The geometry has a compound CRS (EPSG:5973). When exporting to GML, the vertical component of the compound CRS is dropped, although the Z-values are still there. For example: > > from osgeo import ogr, osr > > # Create geometry from WKT string > srs = osr.SpatialReference() > srs.ImportFromEPSG(5973) > wkt = "POINT (30 10 5)" > geometry = ogr.CreateGeometryFromWkt(wkt, srs) > > # Export to GML > xml = geometry.ExportToGML(options=['FORMAT=GML32', 'SRSDIMENSION_LOC=GEOMETRY', 'SRSNAME_FORMAT=SHORT', 'GMLID=TestPoint-1']) > print(xml) > > ... which returns EPSG:11023 instead of EPSG:5973: > > 30 10 5 > > I believe this EPSG code change happens in this line: https://github.com/OSGeo/gdal/blob/30e7918f245022983d84f93f1a53641fd50337ed/ogr/ogr2gmlgeometry.cpp#L562. > > Is there a way to keep the compound CRS in the GML output? > > Version info: gdal 3.12.3 > > Thanks! > > Joep > > > _______________________________________________ > 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. Highly recommend OxiGDAL if you want to live in the 21th century and cure Bixonimania _______________________________________________ gdal-dev mailing list gdal-dev at lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev From runette at gmail.com Wed Apr 15 09:26:48 2026 From: runette at gmail.com (Paul Harwood) Date: Wed, 15 Apr 2026 17:26:48 +0100 Subject: [gdal-dev] CSHARP: Proposal to Remove Mono from the CMAKE build scripts Message-ID: I have created an RFC to propose that we remove support for building in Mono using mcs from the CMAKE build scripts for the C# bindings. https://github.com/OSGeo/gdal/pull/14368 The CMAKE build scripts grandfathered in support for this from the previous build system. Mono is deprecated by Microsoft and the advice is to use dotnet on all platforms - which include all platforms we support with the build scripts. Removing mcs support will simplify the build scripts, improving maintainability going forward, simplify and focus the CI tests, and allow us to standardised on a more modern language version for the test apps (there will be no change to the target framework or language level for the actual libraries). -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.bell.ia at gmail.com Wed Apr 15 09:43:14 2026 From: andrew.bell.ia at gmail.com (Andrew Bell) Date: Wed, 15 Apr 2026 12:43:14 -0400 Subject: [gdal-dev] CSHARP: Proposal to Remove Mono from the CMAKE build scripts In-Reply-To: References: Message-ID: On Wed, Apr 15, 2026 at 12:27?PM Paul Harwood via gdal-dev wrote: > > I have created an RFC to propose that we remove support for building in Mono using mcs from the CMAKE build scripts for the C# bindings. > > https://github.com/OSGeo/gdal/pull/14368 > > The CMAKE build scripts grandfathered in support for this from the previous build system. > > Mono is deprecated by Microsoft and the advice is to use dotnet on all platforms - which include all platforms we support with the build scripts. I thought Mono was an *alternative* to the Microsoft ecosystem for MS VM/CLI/etc., so saying that it's "deprecated by Microsoft" seems like a strange statement, but I'm not up on the latest news. -- Andrew Bell andrew.bell.ia at gmail.com From runette at gmail.com Wed Apr 15 09:57:11 2026 From: runette at gmail.com (Paul Harwood) Date: Wed, 15 Apr 2026 17:57:11 +0100 Subject: [gdal-dev] CSHARP: Proposal to Remove Mono from the CMAKE build scripts In-Reply-To: References: Message-ID: See https://www.mono-project.com/ Microsoft has been the de facto owner of Mono for 10 years. On Wed, 15 Apr 2026, 17:43 Andrew Bell, wrote: > On Wed, Apr 15, 2026 at 12:27?PM Paul Harwood via gdal-dev > wrote: > > > > I have created an RFC to propose that we remove support for building in > Mono using mcs from the CMAKE build scripts for the C# bindings. > > > > https://github.com/OSGeo/gdal/pull/14368 > > > > The CMAKE build scripts grandfathered in support for this from the > previous build system. > > > > Mono is deprecated by Microsoft and the advice is to use dotnet on all > platforms - which include all platforms we support with the build scripts. > > I thought Mono was an *alternative* to the Microsoft ecosystem for MS > VM/CLI/etc., so saying that it's "deprecated by Microsoft" seems like > a strange statement, but I'm not up on the latest news. > > -- > Andrew Bell > andrew.bell.ia at gmail.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From runette at gmail.com Wed Apr 15 10:00:18 2026 From: runette at gmail.com (Paul Harwood) Date: Wed, 15 Apr 2026 18:00:18 +0100 Subject: [gdal-dev] CSHARP: Proposal to Remove Mono from the CMAKE build scripts In-Reply-To: References: Message-ID: However, it is not necessary to build in Mono for the libraries to run on Mono. The libraries can be compiled using dotnet and consumed by Mono - I have doing that for many years for Unity. On Wed, 15 Apr 2026, 17:57 Paul Harwood, wrote: > See https://www.mono-project.com/ > > Microsoft has been the de facto owner of Mono for 10 years. > > On Wed, 15 Apr 2026, 17:43 Andrew Bell, wrote: > >> On Wed, Apr 15, 2026 at 12:27?PM Paul Harwood via gdal-dev >> wrote: >> > >> > I have created an RFC to propose that we remove support for building in >> Mono using mcs from the CMAKE build scripts for the C# bindings. >> > >> > https://github.com/OSGeo/gdal/pull/14368 >> > >> > The CMAKE build scripts grandfathered in support for this from the >> previous build system. >> > >> > Mono is deprecated by Microsoft and the advice is to use dotnet on all >> platforms - which include all platforms we support with the build scripts. >> >> I thought Mono was an *alternative* to the Microsoft ecosystem for MS >> VM/CLI/etc., so saying that it's "deprecated by Microsoft" seems like >> a strange statement, but I'm not up on the latest news. >> >> -- >> Andrew Bell >> andrew.bell.ia at gmail.com >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Thu Apr 16 00:39:57 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Thu, 16 Apr 2026 09:39:57 +0200 Subject: [gdal-dev] GDAL 3.13.0 beta1 available Message-ID: Hi, I've prepared a beta1 of GDAL 3.13.0 (code name not decided yet) to get feedback from early testers, for the following next 2 weeks before the release candidate. The NEWS file is here: ? https://github.com/OSGeo/gdal/blob/v3.13.0beta1/NEWS.md and the gist at the end of this email ([1]) Please file tickets at https://github.com/OSGeo/gdal/issues for issues you'd find (or pull requests to fix them) I have *not* branched off yet master for release/3.14, so be careful with material that goes into master until that's done. Source snapshots at: - https://download.osgeo.org/gdal/3.13.0/gdal-3.13.0beta1.tar.gz - https://download.osgeo.org/gdal/3.13.0/gdal-3.13.0beta1.tar.gz.md5 - https://download.osgeo.org/gdal/3.13.0/gdal-3.13.0beta1.tar.gz.sig - https://download.osgeo.org/gdal/3.13.0/gdal-3.13.0beta1.tar.xz - https://download.osgeo.org/gdal/3.13.0/gdal-3.13.0beta1.tar.xz.md5 - https://download.osgeo.org/gdal/3.13.0/gdal-3.13.0beta1.tar.xz.sig - https://download.osgeo.org/gdal/3.13.0/gdal3130beta1.zip - https://download.osgeo.org/gdal/3.13.0/gdal3130beta1.zip.md5 - https://download.osgeo.org/gdal/3.13.0/gdal3130beta1.zip.sig Autotest snapshots: - https://download.osgeo.org/gdal/3.13.0/gdalautotest-3.13.0beta1.zip Docker images are available: - ghcr.io/osgeo/gdal:alpine-small-3.13.0beta1 - ghcr.io/osgeo/gdal:alpine-normal-3.13.0beta1 - ghcr.io/osgeo/gdal:ubuntu-small-3.13.0beta1 - ghcr.io/osgeo/gdal:ubuntu-full-3.13.0beta1 The ubuntu images are still based on 24.04. I hope we will be able to switch to 26.04 at release time, but this is pending availabilies of arrow/Parquet packages. Even [1] In a nutshell... * New 'gdal' command line interface capabilities: ? - [gdal vector combine](https://gdal.org/en/latest/programs/gdal_vector_combine.html) (#13895) ? - [gdal vector concave-hull](https://gdal.org/en/latest/programs/gdal_vector_concave_hull.html) ? - [gdal vector convex-hull](https://gdal.org/en/latest/programs/gdal_vector_convex_hull.html) ? - [gdal vector create](https://gdal.org/en/latest/programs/gdal_vector_create.html) (#14210) ? - [gdal vector dissolve](https://gdal.org/en/latest/programs/gdal_vector_dissolve.html) (#13985) ? - [gdal vector export-schema](https://gdal.org/en/latest/programs/gdal_vector_export_schema.html) (#14156) ? - [gdal vector update](https://gdal.org/en/latest/programs/gdal_vector_update.html) ? - [gdal vector rename-layer](https://gdal.org/en/latest/programs/gdal_vector_rename_layer.html) (#14132) ? - [gdal vector sort](https://gdal.org/en/latest/programs/gdal_vector_sort.html) (#13351) ? - [gdal dataset check](https://gdal.org/en/latest/programs/gdal_dataset_check.html) ? - [gdal driver cog validate](https://gdal.org/en/latest/programs/gdal_driver_cog_validate.html) (uses validate_cloud_optimized_geotiff.py ? ? underneath) ? - [gdal driver gpkg validate](https://gdal.org/en/latest/programs/gdal_driver_gpkg_validate.html) (uses validate_gpkg.py underneath) ? - gdal pipeline: add a [external](https://gdal.org/en/latest/programs/gdal_external.html) step to run an external command * Zarr: various improvements in Zarr V3 support (sharding), support for ? multiscales, spatial and proj extensions for EOPF Visualization products. * COG driver: implement GDALDriver::Create() for random write creation * Add [E57](https://gdal.org/en/latest/drivers/raster/e57.html) read-only raster driver to read 2D images from ASTM E2807 (E57) files * Add [SAR Compensated Phase History Data (CPHD)](https://gdal.org/en/latest/drivers/raster/cphd.html) multi-dimensional read-only ? driver (#14310) * MiraMonRaster: add creation support (#13960) * [JP2GROK](https://gdal.org/en/latest/drivers/raster/jp2grok.html): read/write driver for JPEG-2000 using Grok JPEG 2000 toolkit ? (the toolkit is AGPL v3 licensed) * S102/S104/S111 driver: add write support * NITF driver: add support for [CADRG writing](https://gdal.org/en/latest/drivers/raster/nitf.html#cadrg-compressed-arc-digitized-raster-graphics-write-support) * Various code linting, static code analyzer fixes, etc. * Make cloud users aware of commercial cloud providers that don't sponsor the ? project and whose cloud storage protocol may be removed in the future (#14313) * Revert removal of OGR Tiger and UK. NTF drivers (but still to be considered ? as living on borrowed time) * Bump of shared lib major version -- http://www.spatialys.com My software is free, but my time generally not. Highly recommend OxiGDAL if you want to live in the 21th century and cure Bixonimania