From snigdha.lee75 at gmail.com Tue Mar 3 05:16:33 2026 From: snigdha.lee75 at gmail.com (Sionigdha Sadhukhan) Date: Tue, 3 Mar 2026 18:46:33 +0530 Subject: [gdal-dev] GSoC Proposal Idea: Strengthening GDAL Python Stub Generation via Runtime Consistency Validation Message-ID: Hello GDAL developers, Over the past weeks, while contributing to GDAL and working on Python binding-related issues and PRs, I have been studying the current Python stub generation pipeline in detail. In particular, I explored the docstub integration and the implementation in _analysis.py, _docstrings.py, and _stubs.py, along with recent PRs related to docstring cleanup and stub generation. >From examining the code, I understand that: - .pyi files are generated entirely from docstrings using a custom Lark grammar. - Type resolution is handled through TypeMatcher and import reconstruction. - Unresolved types fall back to _typeshed.Incomplete. - There is currently no mechanical validation step ensuring that generated stubs remain consistent with the actual runtime callable signatures produced by SWIG. This means the stub layer is structurally decoupled from the runtime bindings, and drift between: C++ ? SWIG ? Python runtime ? docstrings ? generated stubs is theoretically possible without automated detection. For GSoC, I would like to explore a project focused on hardening and modernizing this pipeline through runtime?stub consistency validation and stricter enforcement mechanisms. A possible scope could include: *Runtime?Stub Signature Validator* - Import osgeo modules and inspect public callables using inspect.signature(). - Parse generated .pyi files. - Detect mismatches in parameter names, counts, defaults, and return presence. - Produce structured reports of inconsistencies. *Stricter Stub Generation Mode* - Optionally fail (or emit stronger diagnostics) on unresolved types instead of silently aliasing to _typeshed.Incomplete. - Provide measurable metrics on annotation coverage and unresolved types. *CI Integration* - Integrate validation checks into CI to prevent silent drift over time. - Keep the approach incremental and compatible with the existing docstring-driven workflow. The goal would not be to redesign SWIG bindings or replace the current system, but to introduce a validation and enforcement layer that increases confidence in typing correctness, IDE support, and long-term maintainability of the Python bindings. Before developing this into a formal proposal, I would really appreciate feedback on: - Whether runtime?stub consistency validation aligns with current Python binding priorities. - Whether there are known constraints or prior efforts in this direction. - Whether this scope would be appropriate and realistic for a GSoC project. Thank you very much for your time. I would be happy to refine or narrow this idea based on feedback. Best regards, Sionigdha -------------- next part -------------- An HTML attachment was scrubbed... URL: From dklaus at carlsonsw.com Fri Mar 6 09:40:48 2026 From: dklaus at carlsonsw.com (David Klaus) Date: Fri, 6 Mar 2026 12:40:48 -0500 Subject: [gdal-dev] OGRCoordinateTransformation::Transform() memory usage clarification Message-ID: Hello GDAL Community, I am currently optimizing a routine that transforms a large number of points using OGRCoordinateTransformation::Transform(). As it stands, this function requires separate arrays for the x, y, z (optional), and t (optional) data. From a memory perspective, it seems that this approach requires the CPU to fetch cache lines from multiple different memory pools to process a single coordinate tuple. I am concerned this might lead to cache thrashing and degraded performance for massive arrays. Is there an existing method or best practice to provide point data to GDAL in an interleaved, cache-friendly manner? I believe that this can be done using proj directly, but I don't see a solution with GDAL. Alternatively is this separation intentional, making my cache concerns less of an issue in practice? Thank you for your time and any insights you can provide, -- David Klaus Carlson Software Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Fri Mar 6 10:00:38 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Fri, 6 Mar 2026 19:00:38 +0100 Subject: [gdal-dev] OGRCoordinateTransformation::Transform() memory usage clarification In-Reply-To: References: Message-ID: <7e8a38a2-0b6f-4386-a975-86a71d380afb@spatialys.com> Hi, It would be interesting if you could bench using proj_trans() or proj_trans_array() vs OGRCoordinateTransformation::Transform(). My gut feeling would be that the CPU cost of most coordinate transformations would be the dominant part, but I might be wrong. Even Le 06/03/2026 ? 18:40, David Klaus via gdal-dev a ?crit?: > Hello GDAL Community, > > I am currently optimizing a routine that transforms a large number of > points using OGRCoordinateTransformation::Transform(). > > As it stands, this function requires separate arrays for the x, y, z > (optional), and t (optional) data. From a memory perspective, it seems > that this approach requires the CPU to fetch cache lines from multiple > different memory pools to process a single coordinate tuple. I am > concerned this might lead to cache thrashing and degraded performance > for massive arrays. > > Is there an existing method or best practice to provide point data to > GDAL in an interleaved, cache-friendly manner? I believe that this can > be done using proj directly, but I don't see a solution with GDAL. > > Alternatively is this separation intentional, making my cache concerns > less of an issue in practice? > > Thank you for your time and any insights you can provide, > > -- > David Klaus > Carlson Software > > > *Disclaimer* > > The information contained in this communication from the sender is > confidential. It is intended solely for use by the recipient and > others authorized to receive it. If you are not the recipient, you are > hereby notified that any disclosure, copying, distribution or taking > action in relation of the contents of this information is strictly > prohibited and may be unlawful. > > > _______________________________________________ > 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 dklaus at carlsonsw.com Fri Mar 6 11:11:27 2026 From: dklaus at carlsonsw.com (David Klaus) Date: Fri, 6 Mar 2026 14:11:27 -0500 Subject: [gdal-dev] OGRCoordinateTransformation::Transform() memory usage clarification In-Reply-To: <7e8a38a2-0b6f-4386-a975-86a71d380afb@spatialys.com> References: <7e8a38a2-0b6f-4386-a975-86a71d380afb@spatialys.com> Message-ID: Even, I could give this a try. I will add it as a subtask to my current case. I will update once I have more information -- hopefully sometime next week, On Fri, Mar 6, 2026 at 1:00?PM Even Rouault wrote: > Hi, > > It would be interesting if you could bench using proj_trans() or > proj_trans_array() vs OGRCoordinateTransformation::Transform(). My gut > feeling would be that the CPU cost of most coordinate transformations would > be the dominant part, but I might be wrong. > > Even > Le 06/03/2026 ? 18:40, David Klaus via gdal-dev a ?crit : > > Hello GDAL Community, > > I am currently optimizing a routine that transforms a large number of > points using OGRCoordinateTransformation::Transform(). > > As it stands, this function requires separate arrays for the x, y, z > (optional), and t (optional) data. From a memory perspective, it seems that > this approach requires the CPU to fetch cache lines from multiple different > memory pools to process a single coordinate tuple. I am concerned this > might lead to cache thrashing and degraded performance for massive arrays. > > Is there an existing method or best practice to provide point data to GDAL > in an interleaved, cache-friendly manner? I believe that this can be done > using proj directly, but I don't see a solution with GDAL. > > Alternatively is this separation intentional, making my cache concerns > less of an issue in practice? > > Thank you for your time and any insights you can provide, > > -- > David Klaus > Carlson Software > > > *Disclaimer* > > The information contained in this communication from the sender is > confidential. It is intended solely for use by the recipient and others > authorized to receive it. If you are not the recipient, you are hereby > notified that any disclosure, copying, distribution or taking action in > relation of the contents of this information is strictly prohibited and may > be unlawful. > > _______________________________________________ > gdal-dev mailing listgdal-dev at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev > > -- http://www.spatialys.com > My software is free, but my time generally not. > > -- David Klaus Carlson Software Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. -------------- next part -------------- An HTML attachment was scrubbed... URL: From snigdha.lee75 at gmail.com Mon Mar 9 08:21:39 2026 From: snigdha.lee75 at gmail.com (Sionigdha Sadhukhan) Date: Mon, 9 Mar 2026 20:51:39 +0530 Subject: [gdal-dev] GSoC Proposal Idea: Strengthening GDAL Python Stub Generation via Runtime Consistency Validation In-Reply-To: References: Message-ID: I also wanted to ask is GDAL planning to participate under the OSGeo GSoC 2026 umbrella this year? I noticed there isn't a GDAL-specific ideas page yet and wanted to check before finalizing my proposal. I have also shared my introduction and proposal direction on the OSGeo Discourse here: https://discourse.osgeo.org/t/introduction-sionigdha-sadhukhan-gsoc-2026-proposal-gdal-python-stub-hardening-runtime-validation-type-coverage/152757 If any maintainer would be open to mentoring or giving feedback on the proposal draft, I would be very grateful. On Tue, 3 Mar 2026 at 18:46, Sionigdha Sadhukhan wrote: > Hello GDAL developers, > > Over the past weeks, while contributing to GDAL and working on Python > binding-related issues and PRs, I have been studying the current Python > stub generation pipeline in detail. In particular, I explored the docstub integration > and the implementation in _analysis.py, _docstrings.py, and _stubs.py, > along with recent PRs related to docstring cleanup and stub generation. > > From examining the code, I understand that: > > - > > .pyi files are generated entirely from docstrings using a custom Lark > grammar. > - > > Type resolution is handled through TypeMatcher and import > reconstruction. > - > > Unresolved types fall back to _typeshed.Incomplete. > - > > There is currently no mechanical validation step ensuring that > generated stubs remain consistent with the actual runtime callable > signatures produced by SWIG. > > This means the stub layer is structurally decoupled from the runtime > bindings, and drift between: > > C++ ? SWIG ? Python runtime ? docstrings ? generated stubs > > is theoretically possible without automated detection. > > For GSoC, I would like to explore a project focused on hardening and > modernizing this pipeline through runtime?stub consistency validation and > stricter enforcement mechanisms. > > A possible scope could include: > > *Runtime?Stub Signature Validator* > > - > > Import osgeo modules and inspect public callables using > inspect.signature(). > - > > Parse generated .pyi files. > - > > Detect mismatches in parameter names, counts, defaults, and return > presence. > - > > Produce structured reports of inconsistencies. > > *Stricter Stub Generation Mode* > > - > > Optionally fail (or emit stronger diagnostics) on unresolved types > instead of silently aliasing to _typeshed.Incomplete. > - > > Provide measurable metrics on annotation coverage and unresolved types. > > *CI Integration* > > - > > Integrate validation checks into CI to prevent silent drift over time. > - > > Keep the approach incremental and compatible with the existing > docstring-driven workflow. > > The goal would not be to redesign SWIG bindings or replace the current > system, but to introduce a validation and enforcement layer that increases > confidence in typing correctness, IDE support, and long-term > maintainability of the Python bindings. > > Before developing this into a formal proposal, I would really appreciate > feedback on: > > - > > Whether runtime?stub consistency validation aligns with current Python > binding priorities. > - > > Whether there are known constraints or prior efforts in this direction. > - > > Whether this scope would be appropriate and realistic for a GSoC > project. > > Thank you very much for your time. I would be happy to refine or narrow > this idea based on feedback. > > Best regards, > Sionigdha > -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Tue Mar 10 01:59:34 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Tue, 10 Mar 2026 09:59:34 +0100 Subject: [gdal-dev] GSoC Proposal Idea: Strengthening GDAL Python Stub Generation via Runtime Consistency Validation In-Reply-To: References: Message-ID: <2acedd70-7f4d-4e19-8c39-b38eca2ba6b2@spatialys.com> Sionigdha, Thanks for your proposal. We've discussed among several maintainers, but no one appears to be available to mentor a GSoC project. Even Le 09/03/2026 ? 16:21, Sionigdha Sadhukhan via gdal-dev a ?crit?: > > I also wanted to ask is GDAL planning to participate under the OSGeo > GSoC 2026 umbrella this year? I noticed there isn't a GDAL-specific > ideas page yet and wanted to check before finalizing my proposal. I > have also shared my introduction and proposal direction on the OSGeo > Discourse here: > https://discourse.osgeo.org/t/introduction-sionigdha-sadhukhan-gsoc-2026-proposal-gdal-python-stub-hardening-runtime-validation-type-coverage/152757 > > > If any maintainer would be open to mentoring or giving feedback on the > proposal draft, I would be very grateful. > > > On Tue, 3 Mar 2026 at 18:46, Sionigdha Sadhukhan > wrote: > > Hello GDAL developers, > > Over the past weeks, while contributing to GDAL and working on > Python binding-related issues and PRs, I have been studying the > current Python stub generation pipeline in detail. In particular, > I explored the |docstub|?integration and the implementation in > |_analysis.py|, |_docstrings.py|, and |_stubs.py|, along with > recent PRs related to docstring cleanup and stub generation. > > From examining the code, I understand that: > > * > > |.pyi|?files are generated entirely from docstrings using a > custom Lark grammar. > > * > > Type resolution is handled through |TypeMatcher|?and import > reconstruction. > > * > > Unresolved types fall back to |_typeshed.Incomplete|. > > * > > There is currently no mechanical validation step ensuring that > generated stubs remain consistent with the actual runtime > callable signatures produced by SWIG. > > This means the stub layer is structurally decoupled from the > runtime bindings, and drift between: > > C++ ? SWIG ? Python runtime ? docstrings ? generated stubs > > is theoretically possible without automated detection. > > For GSoC, I would like to explore a project focused on hardening > and modernizing this pipeline through runtime?stub consistency > validation and stricter enforcement mechanisms. > > A possible scope could include: > > *Runtime?Stub Signature Validator* > > * > > Import |osgeo|?modules and inspect public callables using > |inspect.signature()|. > > * > > Parse generated |.pyi|?files. > > * > > Detect mismatches in parameter names, counts, defaults, and > return presence. > > * > > Produce structured reports of inconsistencies. > > *Stricter Stub Generation Mode* > > * > > Optionally fail (or emit stronger diagnostics) on unresolved > types instead of silently aliasing to |_typeshed.Incomplete|. > > * > > Provide measurable metrics on annotation coverage and > unresolved types. > > *CI Integration* > > * > > Integrate validation checks into CI to prevent silent drift > over time. > > * > > Keep the approach incremental and compatible with the existing > docstring-driven workflow. > > The goal would not be to redesign SWIG bindings or replace the > current system, but to introduce a validation and enforcement > layer that increases confidence in typing correctness, IDE > support, and long-term maintainability of the Python bindings. > > Before developing this into a formal proposal, I would really > appreciate feedback on: > > * > > Whether runtime?stub consistency validation aligns with > current Python binding priorities. > > * > > Whether there are known constraints or prior efforts in this > direction. > > * > > Whether this scope would be appropriate and realistic for a > GSoC project. > > Thank you very much for your time. I would be happy to refine or > narrow this idea based on feedback. > > Best regards, > Sionigdha > > > _______________________________________________ > 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 dklaus at carlsonsw.com Tue Mar 10 06:19:23 2026 From: dklaus at carlsonsw.com (David Klaus) Date: Tue, 10 Mar 2026 09:19:23 -0400 Subject: [gdal-dev] OGRCoordinateTransformation::Transform() memory usage clarification In-Reply-To: References: <7e8a38a2-0b6f-4386-a975-86a71d380afb@spatialys.com> Message-ID: All, I had a chance to write up and time a comparison. It looks like Even's guess was correct. I compared the runtime of proj_trans_generic() vs. OGRCoordinateTransformation::Transform() when transforming 1 million points. Here are the results: proj_trans_generic(): 0.211000 seconds OGRCoordinateTransformation::Transform(): 0.212000 seconds So it looks like the two approaches are very comparable, at least on my machine. For larger arrays, memory thrashing might become more noticeable. But, I don't have a dataset to test that on, On Fri, Mar 6, 2026 at 2:11?PM David Klaus wrote: > Even, > > I could give this a try. I will add it as a subtask to my current case. I > will update once I have more information -- hopefully sometime next week, > > On Fri, Mar 6, 2026 at 1:00?PM Even Rouault > wrote: > >> Hi, >> >> It would be interesting if you could bench using proj_trans() or >> proj_trans_array() vs OGRCoordinateTransformation::Transform(). My gut >> feeling would be that the CPU cost of most coordinate transformations would >> be the dominant part, but I might be wrong. >> >> Even >> Le 06/03/2026 ? 18:40, David Klaus via gdal-dev a ?crit : >> >> Hello GDAL Community, >> >> I am currently optimizing a routine that transforms a large number of >> points using OGRCoordinateTransformation::Transform(). >> >> As it stands, this function requires separate arrays for the x, y, z >> (optional), and t (optional) data. From a memory perspective, it seems that >> this approach requires the CPU to fetch cache lines from multiple different >> memory pools to process a single coordinate tuple. I am concerned this >> might lead to cache thrashing and degraded performance for massive arrays. >> >> Is there an existing method or best practice to provide point data to >> GDAL in an interleaved, cache-friendly manner? I believe that this can be >> done using proj directly, but I don't see a solution with GDAL. >> >> Alternatively is this separation intentional, making my cache concerns >> less of an issue in practice? >> >> Thank you for your time and any insights you can provide, >> >> -- >> David Klaus >> Carlson Software >> >> >> *Disclaimer* >> >> The information contained in this communication from the sender is >> confidential. It is intended solely for use by the recipient and others >> authorized to receive it. If you are not the recipient, you are hereby >> notified that any disclosure, copying, distribution or taking action in >> relation of the contents of this information is strictly prohibited and may >> be unlawful. >> >> _______________________________________________ >> gdal-dev mailing listgdal-dev at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev >> >> -- http://www.spatialys.com >> My software is free, but my time generally not. >> >> > > -- > David Klaus > Carlson Software > -- David Klaus Carlson Software Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gdal at aitchison.me.uk Tue Mar 10 07:17:47 2026 From: gdal at aitchison.me.uk (Andrew C Aitchison) Date: Tue, 10 Mar 2026 14:17:47 +0000 (GMT) Subject: [gdal-dev] CPL_LSBSINT64PTR and CPL_LSBUINT64PTR ? Message-ID: port/cpl_port.h says /** Return a Int16 from the 2 bytes ordered in LSB order at address x. * @deprecated Use rather CPL_LSBSINT16PTR or CPL_LSBUINT16PTR for explicit * signedness. */ #define CPL_LSBINT16PTR(x) and /** Return a Int32 from the 4 bytes ordered in LSB order at address x. * @deprecated Use rather CPL_LSBSINT32PTR or CPL_LSBUINT32PTR for explicit * signedness. */ #define CPL_LSBINT32PTR(x) ... but I cannot find any of CPL_LSBINT64PTR CPL_LSBSINT64PTR or CPL_LSBUINT64PTR. I have the address of a 64bit unsigned integer in little endian order. Which macro should I use to put it into a uint64_t variable ? Thanks, -- Andrew C. Aitchison Kendal, UK andrew at aitchison.me.uk From even.rouault at spatialys.com Tue Mar 10 07:22:09 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Tue, 10 Mar 2026 15:22:09 +0100 Subject: [gdal-dev] CPL_LSBSINT64PTR and CPL_LSBUINT64PTR ? In-Reply-To: References: Message-ID: <08c66080-53e0-4209-a90e-e529262e2db1@spatialys.com> Andrew, > > I have the address of a 64bit unsigned integer in little endian order. > Which macro should I use to put it into a uint64_t variable ? Something like: uint64_t x; memcpy(&x, ptr, sizeof(x)); CPL_LSBPTR64(&x); Even -- http://www.spatialys.com My software is free, but my time generally not. From peter.townsend at maplarge.com Tue Mar 10 11:17:13 2026 From: peter.townsend at maplarge.com (Peter Townsend) Date: Tue, 10 Mar 2026 13:17:13 -0500 Subject: [gdal-dev] GDAL Process Exit Codes and stderr Message-ID: I thought it'd be easiest to just ask. When you run any of the GDAL executables, is it a safe assumption to say that if the process exit code is 0 that it really did succeed at whatever you told it to do? Despite whether it wrote anything out to stderr? To word it a bit differently, if the process code is not zero, can I assume that it didn't work out and I should stop whatever I was doing with GDAL? I'm using v3.9.3 if that helps narrow down the behavior. Thanks! -- Peter Townsend Senior Software Developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Tue Mar 10 12:17:12 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Tue, 10 Mar 2026 20:17:12 +0100 Subject: [gdal-dev] GDAL Process Exit Codes and stderr In-Reply-To: References: Message-ID: Le 10/03/2026 ? 19:17, Peter Townsend via gdal-dev a ?crit?: > I thought it'd be easiest to just ask. > > When you run any of the GDAL executables, is it a safe assumption to > say that if the process exit code is 0 that it really did succeed at > whatever you told it to do? Despite whether it wrote anything out to > stderr? > > To word it a bit differently, if the process code is not zero, can I > assume that it didn't work out and I should stop whatever I was doing > with GDAL? As a principle, yes, that's how things are supposed to work. But as bugs happen, from time to time we fix issues where a 0 error code was returned whereas a failure occurs. -- http://www.spatialys.com My software is free, but my time generally not. From peter.townsend at maplarge.com Tue Mar 10 12:19:13 2026 From: peter.townsend at maplarge.com (Peter Townsend) Date: Tue, 10 Mar 2026 14:19:13 -0500 Subject: [gdal-dev] GDAL Process Exit Codes and stderr In-Reply-To: References: Message-ID: Great, thanks! On Tue, Mar 10, 2026 at 2:17?PM Even Rouault wrote: > > Le 10/03/2026 ? 19:17, Peter Townsend via gdal-dev a ?crit : > > I thought it'd be easiest to just ask. > > > > When you run any of the GDAL executables, is it a safe assumption to > > say that if the process exit code is 0 that it really did succeed at > > whatever you told it to do? Despite whether it wrote anything out to > > stderr? > > > > To word it a bit differently, if the process code is not zero, can I > > assume that it didn't work out and I should stop whatever I was doing > > with GDAL? > As a principle, yes, that's how things are supposed to work. But as bugs > happen, from time to time we fix issues where a 0 error code was > returned whereas a failure occurs. > > -- > http://www.spatialys.com > My software is free, but my time generally not. > > -- Peter Townsend Senior Software Developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From gdal at aitchison.me.uk Tue Mar 10 12:58:44 2026 From: gdal at aitchison.me.uk (Andrew C Aitchison) Date: Tue, 10 Mar 2026 19:58:44 +0000 (GMT) Subject: [gdal-dev] CPL_LSBSINT64PTR and CPL_LSBUINT64PTR ? In-Reply-To: <08c66080-53e0-4209-a90e-e529262e2db1@spatialys.com> References: <08c66080-53e0-4209-a90e-e529262e2db1@spatialys.com> Message-ID: <16821064-e068-465c-b6b0-0559ab712b03@aitchison.me.uk> On Tue, 10 Mar 2026, Even Rouault wrote: > Andrew, >> >> I have the address of a 64bit unsigned integer in little endian order. >> Which macro should I use to put it into a uint64_t variable ? > > Something like: > > uint64_t x; > memcpy(&x, ptr, sizeof(x)); > CPL_LSBPTR64(&x); Thanks. -- Andrew C. Aitchison Kendal, UK andrew at aitchison.me.uk From public at postholer.com Wed Mar 11 06:31:56 2026 From: public at postholer.com (Scott) Date: Wed, 11 Mar 2026 06:31:56 -0700 Subject: [gdal-dev] GDAL & AI In-Reply-To: References: Message-ID: <2727d21f-8bce-4cb6-a7c1-a3cd60ff5ff0@postholer.com> This is a bit off-topic, but it's a heads up as we dive into the AI world. Here's an item of note from Amazon and AWS: "Amazon is holding a mandatory meeting about AI breaking its systems. The official framing is "part of normal business." The briefing note describes a trend of incidents with "high blast radius" caused by "Gen-AI assisted changes" for which "best practices and safeguards are not yet fully established." Translation to human language: we gave AI to engineers and things keep breaking? The response for now? Junior and mid-level engineers can no longer push AI-assisted code without a senior signing off. AWS spent 13 hours recovering after its own AI coding tool, asked to make some changes, decided instead to delete and recreate the environment (the software equivalent of fixing a leaky tap by knocking down the wall). Amazon called that an "extremely limited event" (the affected tool served customers in mainland China)." https://x.com/lukOlejnik/status/2031257644724342957/photo/1 Scott On 3/10/26 11:17, Peter Townsend via gdal-dev wrote: > I thought it'd be easiest to just ask. > > When you run any of the GDAL executables, is it a safe assumption to say > that if the process exit code is 0 that it really did succeed at > whatever you told it to do? Despite whether it wrote anything out to stderr? > > To word it a bit differently, if the process code is not zero, can I > assume that it didn't work out and I should stop whatever I was doing > with GDAL? > > I'm using v3.9.3 if that helps narrow down the behavior. > > Thanks! > > -- > Peter Townsend > Senior Software Developer > > _______________________________________________ > gdal-dev mailing list > gdal-dev at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev From even.rouault at spatialys.com Thu Mar 12 11:53:50 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Thu, 12 Mar 2026 19:53:50 +0100 Subject: [gdal-dev] gdal2tiles: use gdal raster tile underneath Message-ID: <238b290d-3133-4a99-a4df-e8b2358732fc@spatialys.com> Hi, for those not tracking github, you may want to have a look at https://github.com/OSGeo/gdal/pull/14117 Even -- http://www.spatialys.com My software is free, but my time generally not. From schut at satelligence.com Mon Mar 16 08:58:13 2026 From: schut at satelligence.com (Vincent Schut) Date: Mon, 16 Mar 2026 16:58:13 +0100 Subject: [gdal-dev] optimizing GTI performance (follow-up on #14063) Message-ID: This is a follow-up on https://github.com/OSGeo/gdal/issues/14063. I decided to take it to the list instead, because I'm not sure whether this is an issue or simply a discussion on performance. (Let me know if you rather take this to gh issues again; happy to do so). Please read the original issue first, to avoid wasting time on questions that were already answered there :-) Short context: trying to get good performance out of a GTI mosaic which wraps (potentially a lot of) remote tifs (on AWS S3). The tifs are in UTM, the mosaic is reprojecting to epgs:4326. After the performance optimizations made by Even as response to #14063 (https://github.com/OSGeo/gdal/pull/14089 and https://github.com/OSGeo/gdal/pull/14094), I did some testing. The results were rather... confusing. All these tests were done with a fresh gdal master build (GDAL 3.13.0dev-28b33d81c7, released 2026/03/15). What I expected (hoped): - wrapping a (single) remote tif with a GTI should not affect performance too much - gdal_translate to have better or similar performance on the GTI than gdalwarp, especially with using -oo WARPING_MEMORY_SIZE. As Even said, using gdalwarp means the warping logic is used twice, where it is only needed once. Using gdal_translate should therefore show better performance. What I found: - gdalwarp on the GTI is about 50% slower than on the remote tiff directly (but maybe that is simply the cost of having a GTI wrapper? I hoped it would be less) - gdal_translate is still waaay slower (10x) than gdal_warp. Using WARPING_MEMORY_SIZE hardly seems to make a difference. - this is only/mainly when targeting remote tifs. When using local files, the timings are very different. But: the remote case is the case we need, and what want to optimize. So I focus on that. My tests were on a 22-core (according to "nproc") machine, 64G ram. Results will probably vary with number of cores, network speed, physical location (I'm in Europe, these tifs are probably in a bucket in the US), and also the size of the block extracted. All tests below extract the same 0.2 degree block. These are the commands I ran as test: # export config options export GDAL_CACHEMAX=1GB GDAL_NUM_THREADS=ALL_CPUS DISABLE_READDIR_ON_OPEN=EMPTY_DIR CPL_VSIL_CURL_ALLOWED_EXTENSIONS="tiff" AWS_NO_SIGN_REQUEST=YES # create a GTI wrapping 1 remote tif gdal driver gti create --resolution 0.00006,0.00006 --ot Int8 --band-count 64 --nodata -128 --dst-crs epsg:4326 --of gpkg /vsis3/us-west-2.opendata.source.coop/tge-labs/aef/v1/annual/2024/30N/xpzba7dllw4la2007-0000008192-0000000000.tiff test_1tiff.gti.gpkg # start of tests # each test extracts the same 0.2 x 0.2 degree block. # gdal_warp on the remote tif directly, doing the exact same reprojecting as the GTI is doing gdalwarp -overwrite -te -5.8 5.6 -5.6 5.8 -tr 0.00006 -0.00006 -t_srs epsg:4326 -wm 1G? -co tiled=yes -co blockxsize=512 -co blockysize=512 -co interleave=band /vsis3/us-west-2.opendata.source.coop/tge-labs/aef/v1/annual/2024/30N/xpzba7dllw4la2007-0000008192-0000000000.tiff result_tiff_allbands.tif # time: 0m33s # gdalwarp on the GTI which wraps the same tif gdalwarp -overwrite -te -5.8 5.6 -5.6 5.8 -wm 1G? -co tiled=yes -co blockxsize=512 -co blockysize=512 -co interleave=band test_1tiff.gti.gpkg result_gti_allbands.tif # time: 0m47s # gdal_translate on the GTI with -oo WARPING_MEMORY_SIZE set to 1G gdal_translate -oo WARPING_MEMORY_SIZE=1GB -projwin -5.8 5.8 -5.6 5.6 -co tiled=yes -co blockxsize=512 -co blockysize=512 -co interleave=band test_1tiff.gti.gpkg gt_result_gti_allbands.tif # time: 5m31s # gdal_translate on the GTI without the -oo WARPING_MEMORY_SIZE option gdal_translate -projwin -5.8 5.8 -5.6 5.6 -co tiled=yes -co blockxsize=512 -co blockysize=512 -co interleave=band test_1tiff.gti.gpkg gt_result_gti_allbands.tif # time: 5m16s -- Vincent Schut Remote Sensing Software Engineer +31 302272679 ~ Maliebaan 22 | 3581CP | Utrecht | Netherlands Linkedin ~ satelligence.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Mon Mar 16 10:47:43 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Mon, 16 Mar 2026 18:47:43 +0100 Subject: [gdal-dev] optimizing GTI performance (follow-up on #14063) In-Reply-To: References: Message-ID: <79401451-9fa8-41cd-977d-52300beb13fe@spatialys.com> Vincent, The recent pull requests #14089 and #14094 were mostly tested on local datasets because it is faster&more easily reproducible w.r.t. timings, but it is true there's a significant difference in performance with remote datasets. This comes from the fact the gdal_translate (and the underlying GDALDatasetCopyWholeRaster()? methd) and gdalwarp have different strategies in the way the compute their processing chunks. From my testing, you can significantly improve performance with gdal_translate?on the GTI?by using : * -co INTERLEAVE=PIXEL. otherwise as both the input and output datasets are band interleaved, GDALDatasetCopyWholeRaster() will proceed band by band, which will not leave much opportunity to the GTiff driver to parallelize pixel acquisition. This is the main factor at play. * and -co COMPRESS=ZSTD (or another?method?of your liking). This will force?GDALDatasetCopyWholeRaster() to?operate?on chunks that are at least the block height tall * and increase the tile height to 1024 for example Even Le 16/03/2026 ? 16:58, Vincent Schut via gdal-dev a ?crit : > This is a follow-up on https://github.com/OSGeo/gdal/issues/14063. > > I decided to take it to the list instead, because I'm not sure > whether this is an issue or simply a discussion on performance. (Let > me know if you rather take this to gh issues again; happy to do so). > > Please read the original issue first, to avoid wasting time on > questions that were already answered there :-) > > Short context: trying to get good performance out of a GTI mosaic > which wraps (potentially a lot of) remote tifs (on AWS S3). The tifs > are in UTM, the mosaic is reprojecting to epgs:4326. > > After the performance optimizations made by Even as response to > #14063 (https://github.com/OSGeo/gdal/pull/14089 and https:// > github.com/OSGeo/gdal/pull/14094), I did some testing. The results > were rather... confusing. > > All these tests were done with a fresh gdal master build (GDAL > 3.13.0dev-28b33d81c7, released 2026/03/15). > > What I expected (hoped): - wrapping a (single) remote tif with a GTI > should not affect performance too much - gdal_translate to have > better or similar performance on the GTI than gdalwarp, especially > with using -oo WARPING_MEMORY_SIZE. As Even said, using gdalwarp > means the warping logic is used twice, where it is only needed once. > Using gdal_translate should therefore show better performance. > > What I found: - gdalwarp on the GTI is about 50% slower than on the > remote tiff directly (but maybe that is simply the cost of having a > GTI wrapper? I hoped it would be less) - gdal_translate is still > waaay slower (10x) than gdal_warp. Using WARPING_MEMORY_SIZE hardly > seems to make a difference. - this is only/mainly when targeting > remote tifs. When using local files, the timings are very different. > But: the remote case is the case we need, and what want to optimize. > So I focus on that. > > My tests were on a 22-core (according to "nproc") machine, 64G ram. > Results will probably vary with number of cores, network speed, > physical location (I'm in Europe, these tifs are probably in a > bucket in the US), and also the size of the block extracted. All > tests below extract the same 0.2 degree block. > > These are the commands I ran as test: > > # export config options export GDAL_CACHEMAX=1GB > GDAL_NUM_THREADS=ALL_CPUS DISABLE_READDIR_ON_OPEN=EMPTY_DIR > CPL_VSIL_CURL_ALLOWED_EXTENSIONS="tiff" AWS_NO_SIGN_REQUEST=YES > > # create a GTI wrapping 1 remote tif gdal driver gti create -- > resolution 0.00006,0.00006 --ot Int8 --band-count 64 --nodata -128 -- > dst-crs epsg:4326 --of gpkg /vsis3/us-west-2.opendata.source.coop/ > tge-labs/aef/v1/annual/2024/30N/ > xpzba7dllw4la2007-0000008192-0000000000.tiff test_1tiff.gti.gpkg > > # start of tests # each test extracts the same 0.2 x 0.2 degree > block. > > # gdal_warp on the remote tif directly, doing the exact same > reprojecting as the GTI is doing gdalwarp -overwrite -te -5.8 5.6 > -5.6 5.8 -tr 0.00006 -0.00006 -t_srs epsg:4326 -wm 1G -co tiled=yes > -co blockxsize=512 -co blockysize=512 -co interleave=band /vsis3/us- > west-2.opendata.source.coop/tge-labs/aef/v1/annual/2024/30N/ > xpzba7dllw4la2007-0000008192-0000000000.tiff > result_tiff_allbands.tif # time: 0m33s > > # gdalwarp on the GTI which wraps the same tif gdalwarp -overwrite - > te -5.8 5.6 -5.6 5.8 -wm 1G -co tiled=yes -co blockxsize=512 -co > blockysize=512 -co interleave=band test_1tiff.gti.gpkg > result_gti_allbands.tif # time: 0m47s > > # gdal_translate on the GTI with -oo WARPING_MEMORY_SIZE set to 1G > gdal_translate -oo WARPING_MEMORY_SIZE=1GB -projwin -5.8 5.8 -5.6 > 5.6 -co tiled=yes -co blockxsize=512 -co blockysize=512 -co > interleave=band test_1tiff.gti.gpkg gt_result_gti_allbands.tif # > time: 5m31s > > # gdal_translate on the GTI without the -oo WARPING_MEMORY_SIZE > option gdal_translate -projwin -5.8 5.8 -5.6 5.6 -co tiled=yes -co > blockxsize=512 -co blockysize=512 -co interleave=band > test_1tiff.gti.gpkg gt_result_gti_allbands.tif # time: 5m16s > > -- > > > > Vincent Schut > > Remote Sensing Software Engineer > > +31 302272679 ~ Maliebaan 22 | 3581CP | Utrecht | Netherlands > > Linkedin ~ > satelligence.com www.satelligence.com> > > > _______________________________________________ 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 Mon Mar 16 13:23:23 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Mon, 16 Mar 2026 21:23:23 +0100 Subject: [gdal-dev] GDAL 3.12.3 release candidate Message-ID: <6e4bfc7f-dd01-448c-a9db-12a2fa170151@spatialys.com> Hi, I have prepared a GDAL/OGR 3.12.3 bugfix release candidate. Pick up an archive among the following ones (by ascending size): ? https://download.osgeo.org/gdal/3.12.3/gdal-3.12.3rc1.tar.xz ? https://download.osgeo.org/gdal/3.12.3/gdal-3.12.3rc1.tar.gz ? https://download.osgeo.org/gdal/3.12.3/gdal3123rc1.zip A snapshot of the gdalautotest suite is also available: https://download.osgeo.org/gdal/3.12.3/gdalautotest-3.12.3rc1.zip The NEWS file is here: ? https://github.com/OSGeo/gdal/blob/v3.12.3RC1/NEWS.md I'll call for a vote in a couple days if no serious issues are reported before. Best regards, Even -- http://www.spatialys.com My software is free, but my time generally not. From even.rouault at spatialys.com Wed Mar 18 03:28:48 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 18 Mar 2026 11:28:48 +0100 Subject: [gdal-dev] GDAL 3.12.3 rc2 is available (was Re: GDAL 3.12.3 release candidate) In-Reply-To: <6e4bfc7f-dd01-448c-a9db-12a2fa170151@spatialys.com> References: <6e4bfc7f-dd01-448c-a9db-12a2fa170151@spatialys.com> Message-ID: <1ecb277f-0eb0-4b6a-882a-036a0870dc04@spatialys.com> Hi, A regression with a potential security impact slipped into RC1, hence this RC2 which?only change since RC1 is https://github.com/OSGeo/gdal/commit/c4c0e8b61c31bacdcca15c71af53e8c8afb12f91 New download links: ? https://download.osgeo.org/gdal/3.12.3/gdal-3.12.3rc2.tar.xz ? https://download.osgeo.org/gdal/3.12.3/gdal-3.12.3rc2.tar.gz ? https://download.osgeo.org/gdal/3.12.3/gdal3123rc2.zip https://download.osgeo.org/gdal/3.12.3/gdalautotest-3.12.3rc2.zip Even Le 16/03/2026 ? 21:23, Even Rouault via gdal-dev a ?crit?: > Hi, > > I have prepared a GDAL/OGR 3.12.3 bugfix release candidate. > > Pick up an archive among the following ones (by ascending size): > > ? https://download.osgeo.org/gdal/3.12.3/gdal-3.12.3rc1.tar.xz > ? https://download.osgeo.org/gdal/3.12.3/gdal-3.12.3rc1.tar.gz > ? https://download.osgeo.org/gdal/3.12.3/gdal3123rc1.zip > > A snapshot of the gdalautotest suite is also available: > > https://download.osgeo.org/gdal/3.12.3/gdalautotest-3.12.3rc1.zip > > The NEWS file is here: > > ? https://github.com/OSGeo/gdal/blob/v3.12.3RC1/NEWS.md > > I'll call for a vote in a couple days if no serious issues are > reported before. > > Best regards, > > Even > -- http://www.spatialys.com My software is free, but my time generally not. From even.rouault at spatialys.com Wed Mar 18 08:43:25 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 18 Mar 2026 16:43:25 +0100 Subject: [gdal-dev] Motion: approve GDAL 3.12.3 rc2 as final release Message-ID: Motion: approve GDAL 3.12.3 rc2 as final release Starting with my +1 Even -- http://www.spatialys.com My software is free, but my time generally not. From j1 at jimenezshaw.com Wed Mar 18 09:09:21 2026 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Wed, 18 Mar 2026 17:09:21 +0100 Subject: [gdal-dev] Motion: approve GDAL 3.12.3 rc2 as final release In-Reply-To: References: Message-ID: +1 Javier On Wed, 18 Mar 2026 at 16:43, Even Rouault via gdal-dev < gdal-dev at lists.osgeo.org> wrote: > Motion: approve GDAL 3.12.3 rc2 as final release > > Starting with my +1 > > 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 Mar 18 09:37:09 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 18 Mar 2026 17:37:09 +0100 Subject: [gdal-dev] shapelib 1.6.3 is released Message-ID: <54ee710a-cb76-4078-8124-a32ce7887236@spatialys.com> Hi, shapelib 1.6.3 is released: - https://download.osgeo.org/shapelib/shapelib-1.6.3.tar.gz - https://download.osgeo.org/shapelib/shapelib-1.6.3.zip Changes since 1.6.2: -? ?Fix GCC 15 build failure on dbfadd.c -? ?shpgeo.c: fix wrong comparison operator in debug code (#189) Even -- http://www.spatialys.com My software is free, but my time generally not. From howard at hobu.co Wed Mar 18 11:52:43 2026 From: howard at hobu.co (Howard Butler) Date: Wed, 18 Mar 2026 13:52:43 -0500 Subject: [gdal-dev] Motion: approve GDAL 3.12.3 rc2 as final release In-Reply-To: References: Message-ID: <34132FBC-736A-4EDB-9B61-E923500A16F9@hobu.co> +1 Howard > On Mar 18, 2026, at 11:09?AM, Javier Jimenez Shaw via gdal-dev wrote: > > +1 Javier > > On Wed, 18 Mar 2026 at 16:43, Even Rouault via gdal-dev > wrote: >> Motion: approve GDAL 3.12.3 rc2 as final release >> >> Starting with my +1 >> >> 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 > _______________________________________________ > 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 norman.barker at gmail.com Wed Mar 18 11:53:47 2026 From: norman.barker at gmail.com (Norman Barker) Date: Wed, 18 Mar 2026 13:53:47 -0500 Subject: [gdal-dev] Motion: approve GDAL 3.12.3 rc2 as final release In-Reply-To: <34132FBC-736A-4EDB-9B61-E923500A16F9@hobu.co> References: <34132FBC-736A-4EDB-9B61-E923500A16F9@hobu.co> Message-ID: +1 Norman On Wed, Mar 18, 2026 at 1:53?PM Howard Butler via gdal-dev < gdal-dev at lists.osgeo.org> wrote: > +1 Howard > > On Mar 18, 2026, at 11:09?AM, Javier Jimenez Shaw via gdal-dev < > gdal-dev at lists.osgeo.org> wrote: > > +1 Javier > > On Wed, 18 Mar 2026 at 16:43, Even Rouault via gdal-dev < > gdal-dev at lists.osgeo.org> wrote: > >> Motion: approve GDAL 3.12.3 rc2 as final release >> >> Starting with my +1 >> >> 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 >> > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.smith.erdc at gmail.com Wed Mar 18 11:59:13 2026 From: michael.smith.erdc at gmail.com (Michael Smith) Date: Wed, 18 Mar 2026 14:59:13 -0400 Subject: [gdal-dev] Motion: approve GDAL 3.12.3 rc2 as final release In-Reply-To: References: <34132FBC-736A-4EDB-9B61-E923500A16F9@hobu.co> Message-ID: +1 Mike From: gdal-dev on behalf of Norman Barker via gdal-dev Reply-To: Norman Barker Date: Wednesday, March 18, 2026 at 2:54?PM Cc: "gdal-dev at lists.osgeo.org" Subject: Re: [gdal-dev] Motion: approve GDAL 3.12.3 rc2 as final release +1 Norman On Wed, Mar 18, 2026 at 1:53?PM Howard Butler via gdal-dev wrote: +1 Howard On Mar 18, 2026, at 11:09?AM, Javier Jimenez Shaw via gdal-dev wrote: +1 Javier On Wed, 18 Mar 2026 at 16:43, Even Rouault via gdal-dev wrote: Motion: approve GDAL 3.12.3 rc2 as final release Starting with my +1 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 _______________________________________________ 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 _______________________________________________ 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 rykovd at gmail.com Thu Mar 19 05:36:32 2026 From: rykovd at gmail.com (Denis Rykov) Date: Thu, 19 Mar 2026 13:36:32 +0100 Subject: [gdal-dev] WFS-T Transaction serializes Date/DateTime fields in non-ISO format Message-ID: Hi, I've found that GDAL 3.12.1 serializes Date and DateTime fields incorrectly in WFS-T Transaction requests ? using / as date separators and a space instead of T between date and time components. This is not compliant with W3C XML Schema Part 2, which defines the formats required by OGC WFS: YYYY-MM-DD and YYYY-MM-DDTHH:MM:SSZ. A similar issue was previously fixed in the GML driver: https://github.com/OSGeo/gdal/issues/2897 - should the same fix be applied to the WFS-T writer? -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Thu Mar 19 08:21:10 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Thu, 19 Mar 2026 16:21:10 +0100 Subject: [gdal-dev] WFS-T Transaction serializes Date/DateTime fields in non-ISO format In-Reply-To: References: Message-ID: Fix queued in https://github.com/OSGeo/gdal/pull/14182 Le 19/03/2026 ? 13:36, Denis Rykov via gdal-dev a ?crit?: > Hi, > > I've found that GDAL 3.12.1 serializes Date and DateTime fields > incorrectly in WFS-T Transaction requests ? using / as date separators > and a space instead of T between date and time components. This is not > compliant with W3C XML Schema Part 2, which defines the formats > required by OGC WFS: YYYY-MM-DD and YYYY-MM-DDTHH:MM:SSZ. > > A similar issue was previously fixed in the GML driver: > https://github.com/OSGeo/gdal/issues/2897 - should the same fix be > applied to the WFS-T writer? > > _______________________________________________ > 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. From rykovd at gmail.com Thu Mar 19 10:47:47 2026 From: rykovd at gmail.com (Denis Rykov) Date: Thu, 19 Mar 2026 18:47:47 +0100 Subject: [gdal-dev] WFS-T Transaction serializes Date/DateTime fields in non-ISO format In-Reply-To: References: Message-ID: Thank you! On Thu, Mar 19, 2026 at 4:21?PM Even Rouault wrote: > Fix queued in https://github.com/OSGeo/gdal/pull/14182 > > Le 19/03/2026 ? 13:36, Denis Rykov via gdal-dev a ?crit : > > Hi, > > > > I've found that GDAL 3.12.1 serializes Date and DateTime fields > > incorrectly in WFS-T Transaction requests ? using / as date separators > > and a space instead of T between date and time components. This is not > > compliant with W3C XML Schema Part 2, which defines the formats > > required by OGC WFS: YYYY-MM-DD and YYYY-MM-DDTHH:MM:SSZ. > > > > A similar issue was previously fixed in the GML driver: > > https://github.com/OSGeo/gdal/issues/2897 - should the same fix be > > applied to the WFS-T writer? > > > > _______________________________________________ > > 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 jukka.rahkonen at maanmittauslaitos.fi Thu Mar 19 13:31:29 2026 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka) Date: Thu, 19 Mar 2026 20:31:29 +0000 Subject: [gdal-dev] Motion: approve GDAL 3.12.3 rc2 as final release In-Reply-To: References: Message-ID: +1 -Jukka Rahkonen- ________________________________________ L?hett?j?: gdal-dev k?ytt?j?n Even Rouault via gdal-dev puolesta L?hetetty: Keskiviikko 18. maaliskuuta 2026 17.43 Vastaanottaja: gdal-dev at lists.osgeo.org Aihe: [gdal-dev] Motion: approve GDAL 3.12.3 rc2 as final release Motion: approve GDAL 3.12.3 rc2 as final release Starting with my +1 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 From even.rouault at spatialys.com Fri Mar 20 06:01:30 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Fri, 20 Mar 2026 14:01:30 +0100 Subject: [gdal-dev] Motion: approve GDAL 3.12.3 rc2 as final release In-Reply-To: References: Message-ID: Passed with +1 from PSC members JavierJS, HowardB, NormanB, MikeS, JukkaR and me Le 18/03/2026 ? 16:43, Even Rouault via gdal-dev a ?crit?: > Motion: approve GDAL 3.12.3 rc2 as final release > > Starting with my +1 > > Even > -- http://www.spatialys.com My software is free, but my time generally not.