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

[Maciek Sieczka]

On Fri, 7 Jul 2006 01:19:42 +1200
Hamish <hamish_nospam at yahoo.com> wrote:

> 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?

Yes.

> 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)

I'm not sure if this is right the way to go. If we proceed this way then
v.proj, v.in.*, v.perturb, v.to.points and other would require the
same. Do we want it? Double standards will be confusing, expecially for
newcommers. Shouldn't the vector engine be fixed instead not to use all
memory? Every no-topology hack will reduce the chance for a real
solution.

(On the other hand, sure I will bless your "r.to.vect -b" having no
other solution handy. But really this is not a sustainable approach.)

Maciek

--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.panoramainternetu.pl/