I think for gdal_translate I need both open and creation options (-oo and
-co), right?
On Tue, 29 Jul 2025 at 18:30, Even Rouault
wrote:
> Javier,
>
> for gdal_translate to COG, both should be equivalent.
>
> for gdalwarp, -wo NUM_THREADS=ALL_CPUS -co NUM_THREADS=ALL_CPUS (ie
> enabling multit
Javier,
for gdal_translate to COG, both should be equivalent.
for gdalwarp, -wo NUM_THREADS=ALL_CPUS -co NUM_THREADS=ALL_CPUS (ie
enabling multithreading for warping and GeoTIFF output) will be
equivalent to --config GDAL_NUM_THREADS=ALL_CPUS
Note that you can also do gdalwarp directly t
Hi
I am running a gdalwarp from UTM xx to EPSG:3857 and later a gdal_translate
to COG (the input is a normal GeoTIFF). Two steps. All inputs and outputs
are TIFF.
Is there any difference between using the config variable
GDAL_NUM_THREADS=ALL_CPUS
than using the creation option for the TIFFs
NUM_T
Thank you so much Even, it is working now!
I will check the link and send my driver code soon.
Javier.
-Original Message-
From: Even Rouault [mailto:even.roua...@spatialys.com]
Sent: 30 July, 2016 17:10
To: Francisco Javier Calzado
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev
Javier,
> I have attached a simple code to reproduce it (Test.cpp). If you need the
> whole solution just ask me, although it is a very simple console test. I
> have also shared with you the zipped datasets through this link:
> https://drive.google.com/file/d/0B-OCl1FjBi0YblRPRGZlQWx4eEE/view?usp=
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Multithreading issue on pixel-based intensive access
(GDAL 2.1.0)
On Thursday 28 July 2016 13:11:13 Francisco Javier Calzado wrote:
> Thanks Even,
>
> I don't want to waste your time, so just before sending any code to be
> tested I w
On Thursday 28 July 2016 13:11:13 Francisco Javier Calzado wrote:
> Thanks Even,
>
> I don't want to waste your time, so just before sending any code to be
> tested I would like to be sure it is not a bug from my side. Although I
> usually work with GDAL compiled in 64bits, I had to swap to x86 fo
Thanks Even,
I don't want to waste your time, so just before sending any code to be tested I
would like to be sure it is not a bug from my side. Although I usually work
with GDAL compiled in 64bits, I had to swap to x86 for these tests. When trying
to compile in 32bits with Visual Studio 2015 I
Javier,
Your use case looks like a legit use case of the API. I'm not aware of bugs
regarding to locking of the raster block cache, but that doesn't mean that
they aren't any. Could you prepare a self contained source code + dataset that
would reproduce the issue ?
As far as I can see, GDALRas
Hi guys, I'm experiencing an issue when running some simple tests
involving multithreading. I would like to know if it is something I am
not doing correctly with GDAL or it is a GDAL business dealing with
threads and block cache.
To make long story short, just imagine two threads accessing dif
Selon Roger Phillips :
You didn't mention which OS you are using, but if it is Windows, I believe you
are running into this proj4 bug : http://trac.osgeo.org/proj/ticket/63
It is now fixed, but no 4.7.1 or 4.8.0 release has been made since the fix has
been applied, so you have to patch it manuall
Hello folks,
I recently tried to use the GDAL 1.9.0 API from multiple threads. However, they
may arise a deadlock situation
where one thread hangs in the cpl_multithread.cpp CPLAcquireMutex function and
others hang in the pj_acquire_lock() function of the proj.4 4.7.0 API blocking
each other.
Martin Dobias wrote:
On Fri, Jun 25, 2010 at 5:55 PM, Frank Warmerdam wrote:
My intent is to use two OGRLayer instances of the same layer: one
instance for handling various stuff in main thread, the other one in
worker thread for rendering. Can I expect the GetNextFeature calls to
be reentrant,
On Fri, Jun 25, 2010 at 5:55 PM, Frank Warmerdam wrote:
>> My intent is to use two OGRLayer instances of the same layer: one
>> instance for handling various stuff in main thread, the other one in
>> worker thread for rendering. Can I expect the GetNextFeature calls to
>> be reentrant, i.e. can th
Martin Dobias wrote:
Hi Frank
On Wed, Jun 23, 2010 at 4:58 PM, Frank Warmerdam wrote:
Martin,
Generally speaking it is not safe to have multiple threads making calls
into a single OGRLayer at the same time. At the very least you will
encounter the "messing up" effect on GetNextFeature(), eve
Hi Frank
On Wed, Jun 23, 2010 at 4:58 PM, Frank Warmerdam wrote:
> Martin,
>
> Generally speaking it is not safe to have multiple threads making calls
> into a single OGRLayer at the same time. At the very least you will
> encounter the "messing up" effect on GetNextFeature(), even if you
> seri
Martin Dobias wrote:
So my only problem is to avoid concurrent reads from
both main thread and worker thread. How can be this
best accomplished without serializing the access?
Your reads are eventually going to be serialized by the disk controller
anyway, so what is the problem with serializing
Hi Ed
On Wed, Jun 23, 2010 at 3:18 PM, Grissom, Edward (Ed)
wrote:
> In a previous message, Martin said:
>
>> So my only problem is to avoid concurrent reads from
>> both main thread and worker thread. How can be this
>> best accomplished without serializing the access?
>
> Your reads are eventua
Hi Ari
On Wed, Jun 23, 2010 at 7:32 AM, Ari Jolma wrote:
> Martin,
>
> Just a comment. In Geoinformatica, which uses GTK+, I've begun to address
> the same kind of problem using the functions provided by GTK+. So far I've
> not used this on rendering and I've not thought about all the consequenci
Martin,
Just a comment. In Geoinformatica, which uses GTK+, I've begun to
address the same kind of problem using the functions provided by GTK+.
So far I've not used this on rendering and I've not thought about all
the consequencies. In some expectedly lengthly GDAL operations it
provides a m
Hi all,
in my GSoC project [1] I'm trying to employ multithreading to make
rendering in QGIS both faster (on multi-core machines) and more
pleasant to use (not blocking GUI thread while rendering). I've been
successful with making that work in "ideal" conditions (no concurrent
reads/writes) and no
hello,
our system reads a large amount of images and used LIBTIFF directly.
to quicken things up we implemented prefetching of whole images which
resided on a different OS-thread.
we moved to GDAL for better format support and now the prefetching mechanism
isn't helpful anymore.
actually now it is
22 matches
Mail list logo
