Thanks Even. From a bit of testing, I can see the time scaling linearly with
the requested number of threads despite inputting only 9 pixels, so I suspect
that feature is newer than 3.0.4. I'll have a look in the changelogs and keep
it in mind.
Dr Daniel Evans
Software Developer
From: gdal-dev
On mardi 6 octobre 2020 13:54:30 CEST Daniel Evans wrote:
> From reading the documentation more closely, I notice that NUM_THREADS is a
> separate bit of functionality from -multithread (which only refers to IO),
> so any thoughts of load balancing weren't correct.
>
> I suspect GDAL is simply doi
>From reading the documentation more closely, I notice that NUM_THREADS is a
>separate bit of functionality from -multithread (which only refers to IO), so
>any thoughts of load balancing weren't correct.
I suspect GDAL is simply doing exactly as instructed - spawning X threads, even
if it won'
I currently have GDAL 2.2.3. `gdalinfo --formats` includes "DODS -raster- (ro): DAP
3.x servers". However, if I download a small MERRA-2 DODS file from NASA with this
OPeNDAP URL
wget
'http://opendap.nccs.nasa.gov/dods/merra2_gmi/tavg1_2d_aer_Nx.dods?pm25[1:3][1:3][1:3]'
-O out.dods
then `gd
Hello,
I've found today that when calling gdal.Warp (from Python, though I doubt it
matters) with multithreading enabled, setting the option NUM_THREADS=ALL_CPUS
results in increased runtime. I find there to be a minimum runtime of ~0.3-0.4s
with NUM_THREADS set like this, compared to a runtime
On mardi 6 octobre 2020 14:36:44 CEST Brad Hards wrote:
> While looking at some NITF test data, Ive found a problem in how we handle
> ECS-A (and ECS) characters. BCS-A (essentially ASCII) is fine. However
> MIL-STD-2500C CN2 allows some header fields to be ECS-A, and the test data
> does this.
>
