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

[Hamish]

Maciek Sieczka wrote:
> 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?


does it happen during the "building lines" (or "registering lines"?)
step?

(watch the memory use using 'top' in another xterm, use "M" to sort by
memory use)


if so, it's the same problem as v.in.ascii building topology.
I added a -b flag to r.to.vect (in CVS) to skip building topology for
this reason. Only tested with raster cells->vector points in mind.
(r.in.xyz -> r.to.vect -> v.surf.rst)


Hamish