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
By the way, it looks like this works fine with an XML .osm file, just not the
binary .pbf.
From: gdal-dev [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Tim Harris
Sent: Tuesday, July 25, 2017 10:36 AM
To: gdal-dev@lists.osgeo.org
Subject: [gdal-dev] OSM conversion failure
I placed a
I placed a small test file here: https://s3.amazonaws.com/osm-test-data/test.pbf
With the latest trunk, when I run this command:
ogr2ogr test.shp test.pbf multipolygons
The result shapefile I get appears to be empty. I've also tried with release
2.1.2 and that result shapefile is not empty. So
, new max size is 608
OSM: Switching to 'lines' as they are no more feature in 'points'
OSM: Switching to 'multipolygons' as they are no more feature in 'lines'
OSM: Switching to 'other_relations' as they are no more feature in
'multip
I'm trying to extract water vectors from OSM using my own local Overpass API
server and OGR. It works for the most part, but there are some water features
missing in my output. One particularly large omission is Lake Huron.
I put an example OSM file here:
https://s3.amazonaws.com/gdal-osm-data/
I'm trying to use gdal.FileFromMemBuffer to do some in-memory processing, but I
ran into what seems to be a 2 GB limit.
If I create a TIF on disk that is just below 2 GB, things work fine:
import gdal
drv = gdal.GetDriverByName("GTiff")
ds = drv.Create("45000.tif", 45000, 45000, 1, gdal.GDT_Byte)
11 matches
Mail list logo
