[GRASS-dev] Re: [bug #3877] (grass) r.to.vect, v.in.ascii use too much memory for millions of points

[Andrew Danner]

Maciek,

 My initial guess is that r.to.vect suffers from a similar bug/feature
that plagued v.in.ascii awhile ago and that is the building of vector
topology. As it stands now, r.to.vect calls Vect_build after processing
all the features and this is the same function call that ate all the
memory in v.in.ascii. The solution for v.in.ascii was to add another
flag "-b" to skip topology building in points mode. The rest of the
r.to.vect code looks pretty clean and I don't immediately expect memory
leaks.  Radim has said many times that there are not leaks in the
Vect_build code, but the memory requirements are high for the topology
building. Without looking into the Vect_build code, I tend to believe
Radim, so if you want to extract 5 000 000 points from a raster you will
need to skip the topology. Note that many vector modules are not able to
use vector layers without topology (v.surf.rst being the primary
execption), so the "-b" flag is more of a workaround than a long term
solution.

 I haven't had a chance to look into the Vect_build code and see if
there is a way to reduce memory usage. Is there any white paper or
technical specs on how the new vector library is organized and what the
vector topology looks like?

-Andy
  
   
On Wed, 2006-07-05 at 20:39 +0200, Maciek Sieczka via RT wrote:
> Markus wrote:
> 
> > New patch submitted, see
> > 
> >  https://intevation.de/rt/webrt?serial_num=3354&display=History
> > 
> > Does it solve the problem?
> 
> So I checked with current CVS and the same problem still applies to r.to.vect.
> 
> "r.to.vect -z feature=point input=dem_5 output=dem_5_pt" eats up all 1GB RAM +
> 1GB SWAP at about 5 000 000 points.
> 
> The above mentioned Andrew Danner's fix for v.in.ascii is great stuff but
> r.to.vect problem remains (in my bug report I was complaining about only
> r.to.vect, few days later Hamish changed the subject, as v.in.ascii issue
> popped up during discussion).
> 
> Is it possible that r.to.vect suffers from a similar problem as v.in.ascii
> did, so a similar fix would do? Andrew?
> 
> Maciek
> 
> 
> -------------------------------------------- Managed by Request Tracker