I ran into sort of an odd problem with some rasterization code that changed
between 3.10.0 and 3.10.1. The problem also exists with 3.10.2. The core of
the problem is flushing data to disk but it seems that threading and
compression also have something to do with it.
Here's a way to reproduce it..
Thanks Even!
On Tue, Mar 4, 2025 at 7:51 AM Even Rouault
wrote:
> Tim,
>
> wil be solved (in 3.11 only) per https://github.com/OSGeo/gdal/pull/11915
>
> In the meantime, check for gdal.Warp() return value: if None, an error
> occurred
>
> Even
> Le 01/03/2025 à 01:00
TermProgress,
multithread=True)
On Sat, Mar 1, 2025 at 7:58 AM Javier Jimenez Shaw
wrote:
> Does it also happen without S3, just with local files?
> It would simplify the analysis
>
> On Sat, 1 Mar 2025, 01:01 Tim Harris via gdal-dev, <
> gdal-dev@lists.osgeo.org> wrote:
>
Hi, I'm having some trouble warping a VRT to a TIF where the VRT and its
constituent rasters are in S3. It stems from a random read error, but the
real problem is that the gdal.Warp call didn't throw an exception when it
was supposed to.
I saw there's this pretty old GitHub issue that may be relat
Not sure if this is a bug, or expected behavior, or user error. If I warp
one TIF into another, and both have nodata masks, it seems that gdalwarp
isn't updating the destination TIF's nodata mask to unmask the new pixels.
Here's a short script to generate two example TIFs. One has a red box in
its
I am using Python and translating small chunks of imagery out of S3 and
occasionally run into errors like this:
2024-12-17 18:06:16.201 MST: ERROR 1: Request for 372390946-372700449
failed with response_code=0
2024-12-17 18:06:16.201 MST: ERROR 1: Request for 2028508162-2028817665
failed with r
