Frank,
I agree that the amount is small per file, but in our application we need to
keep thousands of files open, and keep memory consumption to a certain limit.
I have another question regarding the stripped file. When I open a large
stripped file, the memory rises by almost 1 MB. I assume this
Livneh Yehiyam wrote:
Hi I'm sorry if I was misunderstood, but these are not leaks I'm worried
about, but rather I'm trying to understand the memory consumption of the
various GDAL calls I use. I didn't notice any leak, and I trust you test for
leaks all the time.
Livney,
We don't check for m
Hi
I'm sorry if I was misunderstood, but these are not leaks I'm worried about,
but rather I'm trying to understand the memory consumption of the various GDAL
calls I use.
I didn't notice any leak, and I trust you test for leaks all the time.
Take for example the first two examples below. These t
Livneh Yehiyam wrote:
Hi
After further investigation I think the situation is more complex, as the
results I'm getting depends on the file opened.
I ran the test with several tiff files and I'm getting completly different
results, as described below.
Also, to rest my mind that this is not a pro
Hi
After further investigation I think the situation is more complex, as the
results I'm getting depends on the file opened.
I ran the test with several tiff files and I'm getting completly different
results, as described below.
Also, to rest my mind that this is not a problem with the C# binding
Le lundi 04 octobre 2010 17:23:47, Frank Warmerdam a écrit :
> > gdal_translate, gdalwarp, ...
>
> Even,
>
> I would suggest "-tap" for "target aligned pixels" to go with "-tr". I
> would think that gdalwarp, gdal_rasterize, and perhaps gdal_merge.py and
> gdalbuildvrt would be appropriate appl
Ah yes, I can see what you mean now. OK, maybe not tautological, but it
certainly made me stop for a moment to figure it out!
-JD
-Original Message-
From: Frank Warmerdam [mailto:warmer...@pobox.com]
Sent: 05 October 2010 15:54
To: John Donovan
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [
John Donovan wrote:
Hi all,
I was just perusing the gdalwarp page on www.gdal.org/gdalwarp.html,
when I noticed this tautological sentence:
"Mosaicing into an existing output file is supported if the output file
already exists."
Any idea what it is meant to say? I presume it is something to do
Hi all,
I was just perusing the gdalwarp page on www.gdal.org/gdalwarp.html,
when I noticed this tautological sentence:
"Mosaicing into an existing output file is supported if the output file
already exists."
Any idea what it is meant to say? I presume it is something to do with
the bounds of an
So I now changed the code to just use the geos library and it works:
Point* kdTreeMgmtServer::process_polygon(string line, string path) {
WKTReader* wkt_reader = new WKTReader();
Geometry* geom = wkt_reader->read(line);
if(!geom->isValid()) {
log_error("no
Moritz,
Then we can probably rule out the geos library. Just make sure it was
recognized by the configure script by looking at its output or in the
config.log file.
We need to have some info on the get_Area() error.
Build gdal after configuring with the --enable-debug switch and run the
applicati
Hey,
I checked gdal out from the svn repos and build it with:
./configure --libdir=/usr/lib --with-geos=yes
make -j3
make install
Installed geos stuff:
dpkg -l | grep geos
ii libgeos-3.2.0 3.2.0-1
Geometry engine for Geographic Information S
Moritz,
Did you compile GDAL/OGR with GEOS library support? IsValid() will fail
without this.
I can't tell why get_Area() crashes.
On Tue, Oct 5, 2010 at 3:03 PM, moritzzz wrote:
>
> Hey guys,
>
> I just started using gdal/ogr and am running into a lot of problems. The
> main one right now com
Hey guys,
I just started using gdal/ogr and am running into a lot of problems. The
main one right now comes up when I'm trying to create a geometry from a
string that I read from a file. The line I'm reading looks like this:
MULTIPOLYGON(((1 1,5 1,5 5,1 5,1 1),(2 2,2 3,3 3,3 2,2 2)),((6 3,9 2,9 4
Even,
Thanks for the suggestions. I'll be working through them and will try to
factor out into a standalone test case if possible.
Best regards,
Brian
On Thu, Sep 30, 2010 at 6:01 PM, Even Rouault
wrote:
> Brian,
>
> This is indeed going be difficult to help you in an efficient way without a
>
Livneh,
I am assuming the 80KB refers to the memory change for getting the
projection and not the whole dataset.
Can you check if the 80KB memory is freed and not leaked if the dataset is
closed?
On Mon, Oct 4, 2010 at 10:41 PM, Livneh Yehiyam wrote:
> Hi
> We are using Gdal 1.7.0b from FWTools
16 matches
Mail list logo