[GRASS5] [bug #3877] (grass) r.to.vect: severe memory leaks, I'm helpless

[Radim Blazek]

Hi,

please read old mails on this problem. I dont have time to explain it
again and again. AFAIK there are no big memory leaks.

Radim

On 12/4/05, Request Tracker <grass-bugs at intevation.de> wrote:
> this bug's URL: http://intevation.de/rt/webrt?serial_num=3877
> -------------------------------------------------------------------------
>
> Subject: r.to.vect: severe memory leaks, I'm helpless
>
> Platform: GNU/Linux/i386
> grass obtained from: CVS
> grass binary for platform: Compiled from Sources
> GRASS Version: 2005-11-16
>
> r.to.vect -z feature=point input=dem_5 output=dem_5_pt
>
> The input is a 5m floating point DEM, 6305x7930 cells.
>
> I need to convert it to 3D points and reproject them into another coordinate system to re-interpolate my DEM there. However, r.to.vect consumes all my RAM (1GB) and swap (1GB) and hangs the system at the "Registering lines:" stage with about 5 000 000 points already processed out of almost 50 000 000 total.
>
> Trying without "-z" flag is even worse of course - not only many times slower, but the dbf driver eats whole memory much erlier - r.to.vect doesn't even make it to "Registering lines:"!
>
> Please do something about it. It's been several months now since well known problems with memory leaks in vectors and dbf driver remain. This issue renders Grass useless for processing large vector datasets. In my case it is a definite show stoper. And I wonder: even if I make it to convert my DEM into vector points with another software and reproject it with ogr2ogr, would Grass alone manage to:
> 1. import this 50 000 000 point vector shapefile with v.in.ogr?
> 2. interpolate a 5m DEM out of it with v.surf.rst?
>
> Maciek
>
> -------------------------------------------- Managed by Request Tracker
>
> _______________________________________________
> grass5 mailing list
> grass5 at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
>