[GRASS-user] v.surf.rst limitations?

[Hamish]

> > PS Yes, v.surf.bspline is much faster than v.surf.rst. But more   
> > importantly, it seems to step through the data to prevent memory   
> > allocation errors. Is this true? Nice!!! :-)

do you mean steps through input points?

> Yes, that's totally true. If the current region is too large, it  
> divides the whole region into smaller regions and it works with them  
> one at a time.

does this use GRASS's lib/segment/ library?

> The module also considered overlapped zones between sub-regions to
> avoid discontinuities in the dtm heights.

this is something that has frustrated me about the RST modules when
dealing with data which rapidly changes density. it's hard to get the
tuning right, auto-balance would be nice.

> you didn't update the CVS, did you? Don't do it.

no, I didn't.

> I uploaded it on my version and I'll send altogether today :)

it seems to be there now.

> Now one question. Due to allocation memory problems with raster on my
> pc some weeks ago, I introduced a limitation on the raster dimensions
> only in my v.surf.bspline version.
..
> So, I decide to set a limitation in the number of raster cells: about
> 30mill. I think it is high enough.
>
> But, which is the best way to controll these kinds of things? Should I
> set a limitation in the number of cells? If afirmative, which one? 
> Maybe, considering float cells instead double? As a possible thing I 
> would like to allocate the whole raster (as It works now) instead of 
> considering smaller rasters and merge them at the end.

Please remove the limitation. If the user has 28GB RAM and compiled with
large file support, they should be able to use it. If you use G_alloc*()
and friends, they should exit with a nice "out of memory" message if you
don't have enough- let them do their job. If you don't alloc the memory
until the end of your program, you might alloc() then free() it right at
the beginning as a test to save the annoyance of waiting for 30 minutes
before it crashes.

Is is really necessary to allocate memory for the entire raster map at
one time? Can you allocate and free|clear+reuse for each segment?
>From your statement that it runs in segments this sounds plausable. (?)

If the method demands that you must store the entire raster in memory,
you might be able to use a percent= option like r.in.xyz, then run it in
multiple passes.

You can allocate float instead of double to save memory, but if you do
that you should give users a choice. e.g. r.in.xyz defaults to
type=FCELL.


Hamish