Le jeudi 24 mai 2012 23:47:14, Chris Barker a écrit :
> On Thu, May 24, 2012 at 2:40 PM, Even Rouault
>
> wrote:
> > Ok, see http://trac.osgeo.org/gdal/ticket/4682 for a fix. Basically, the
> > current caching strategy is maintained (cache all bands that have been
> > accessed), until a threshold
On Thu, May 24, 2012 at 2:40 PM, Even Rouault
wrote:
> Ok, see http://trac.osgeo.org/gdal/ticket/4682 for a fix. Basically, the
> current caching strategy is maintained (cache all bands that have been
> accessed), until a threshold is reached (arbitrarly set to 100 MB by default).
seems reasonabl
Ok, see http://trac.osgeo.org/gdal/ticket/4682 for a fix. Basically, the
current caching strategy is maintained (cache all bands that have been
accessed), until a threshold is reached (arbitrarly set to 100 MB by default).
When the threshold is reached, then we only cache one band at a time. Tha
Even,
Thanks so much!
> ok I reproduce your issue.
>
> The GRIB driver actually caches all the raster data from a band the first type
> you access it, and never releases it.
I just tested reading only a subset of teh band (because I don't need
the whole thing), and it used exactly the same amoun
Chris,
ok I reproduce your issue.
The GRIB driver actually caches all the raster data from a band the first type
you access it, and never releases it. This is to speed-up successive RasterIO
operations on a band, which is a nice feature generally. But if you iterate
over all the bands, it mean
Hi folks,
I"m finding what appears to be a memory leak, using the GRIB reader,
with the python bindings.
What I'm trying to do is read the data one band at a time, then throw
it away and read the next band -- there are 1129 bands in the file at
hand, and I can't hold it all in memory (32 bit stil
