Le mardi 13 septembre 2016 21:22:20, James Ramm a écrit :
> I think you can call SWIG with the -threads argument on the command line so
> it will always release the GIL. Could be an easy option if it works
That's mostly what I've done. See my other message :
https://lists.osgeo.org/pipermail/gdal
Le mardi 13 septembre 2016 17:09:30, Wood, Alexander a écrit :
> Hi,
> I've encountered what appears to be a concurrency issue when calling
> OGRCoordinateTransformation::Transform from multiple threads. What I've
> found is that when Transform is called from multiple asynchronous tasks,
> I'm get
I think you can call SWIG with the -threads argument on the command line so
it will always release the GIL. Could be an easy option if it works
On Tuesday, 13 September 2016, Even Rouault
wrote:
> Le mardi 13 septembre 2016 11:07:39, Rutger a écrit :
> > I overlooked the fact that it still moves
Hi,
I've encountered what appears to be a concurrency issue when calling
OGRCoordinateTransformation::Transform from multiple threads. What I've found
is that when Transform is called from multiple asynchronous tasks, I'm getting
inconsistent results given the same inputs. This is pronounced w
Hi,
In the recent discussion about the VRT Python new capability, I realized that
the Python global interpreter lock wasn't released in the osgeo.gdal bindings
when going from Python to GDAL native code, thus making threaded Python code
inefficient.
I've committed a change to improve that. Bas
Le mardi 13 septembre 2016 14:25:59, Sean Gillies a écrit :
> Hi Even,
>
> On Wed, Aug 31, 2016 at 1:48 PM, Even Rouault
>
> wrote:
> > Sean,
> >
> > We ended up cancelling the BoF.
> > I had a discussion with someone (Dmitry perhaps ?) and there was some
> > concerns
> > expressed by turning o
>Ari Wrote:
>At FOSS4G my conclusion was that my first approach was not good for many
>reasons, most >importantly because it did not scale to several bands in one
>operation. So I've trying with the >following ideas/decisions:
>
>The problem is to compute y=f(x1, x2, ...), where y is a new datase
Hi Even,
On Wed, Aug 31, 2016 at 1:48 PM, Even Rouault
wrote:
> Sean,
>
> We ended up cancelling the BoF.
> I had a discussion with someone (Dmitry perhaps ?) and there was some
> concerns
> expressed by turning on RFC 7946 by default, even in the case of a source
> dataset in EPSG:4326. Particu
13.09.2016, 13:14, Even Rouault kirjoitti:
Le mardi 13 septembre 2016 10:15:42, Ari Jolma a écrit :
There's been some discussion here about doing pixel function
calculations in VRT derived bands, so I thought I'd let you know what
are my thoughts and what I've done regarding RFC 62.
At FOSS4G m
Le mardi 13 septembre 2016 10:15:42, Ari Jolma a écrit :
> There's been some discussion here about doing pixel function
> calculations in VRT derived bands, so I thought I'd let you know what
> are my thoughts and what I've done regarding RFC 62.
>
> At FOSS4G my conclusion was that my first appro
Le mardi 13 septembre 2016 11:42:10, Gane R a écrit :
> gdalinfo for a file is as
>
> Driver: PDF/Geospatial PDF
> Files: C:\la plata_final_sept8-1.pdf
> Size is 5100, 3300
> Coordinate System is:
> PROJCS["unnamed",
> GEOGCS["unknown",
> DATUM["WGS_1984 based datum",
> SPH
Le mardi 13 septembre 2016 11:07:39, Rutger a écrit :
> I overlooked the fact that it still moves through Python, is that the
> 'only' hurdle preventing parallel IO?
Not sure to understand your question. But if you have several sources, you
could potentially do parallelized reading of them from t
gdalinfo for a file is as
Driver: PDF/Geospatial PDF
Files: C:\la plata_final_sept8-1.pdf
Size is 5100, 3300
Coordinate System is:
PROJCS["unnamed",
GEOGCS["unknown",
DATUM["WGS_1984 based datum",
SPHEROID["Sphere",6378137,0],
TOWGS84[0,0,0,0,0,0,0]],
PR
I overlooked the fact that it still moves through Python, is that the 'only'
hurdle preventing parallel IO? Since gdalwarp for example has the -multi
flag, it seems as if GDAL is capable of it, or is that a
specific/specialized implementation?
Numba has several options which might eliminate using
Le mardi 13 septembre 2016 09:02:09, Rutger a écrit :
> Hi Even,
>
> This is really amazing. I'm becoming more and more a fan of Numba for
> number crunching, so this certainly makes my day. As soon as i can find a
> Win x64 dev version on a Conda channel I'll give it a try.
>
> A use case that c
There's been some discussion here about doing pixel function
calculations in VRT derived bands, so I thought I'd let you know what
are my thoughts and what I've done regarding RFC 62.
At FOSS4G my conclusion was that my first approach was not good for many
reasons, most importantly because it
Le lundi 12 septembre 2016 23:38:41, James Ramm a écrit :
> Incredible
> Really cool initiative.
>
> I had a play around and wanted a way to be able to write the pixel function
> in a 'stand alone' python module and generate the VRT from it. This would
> allow independent testing and easier ma
Hi Even,
This is really amazing. I'm becoming more and more a fan of Numba for number
crunching, so this certainly makes my day. As soon as i can find a Win x64
dev version on a Conda channel I'll give it a try.
A use case that comes to mind, and which i run into regularly, is when i
want to do s
18 matches
Mail list logo
