[GRASS5] v.in.ascii

[Helena]

While fixing an unrelated bug 3381 in v.surf.rst the topology issue for point data came up.

Do we need topology for point data? If yes, what is in the topo file for points?
Would it make sense to implement -b option (no topology built) for v.in.ascii
as Radim has suggested and then change the check for level 2 in v.surf.rst main.c from fatal error to warning?

if (open_check < 2)
         G_fatal_error("You first need to run v.build on vector file <%s>", input);

I assume that this check is in all of the vector modules, would it make sense to change them
for point data (e.g. in v.info or v.univar) for modules where topology is not needed,
so that one does not have to run v.build and get the memory problem?

Or would it be better to look at V_build and modify it for point data so that the topology
for points (which I must admit do not know what means) does not use excessive memory?
We need spatial index for point data but topology is not quite clear,


Helena

   Radim Blazek wrote:
> On 6/30/05, Hamish <hamish_nospam at yahoo.com> wrote:
> 
>>>There is no leak in the library, the memory is not released by default
>>>because it takes long time. You can force the library to release the
>>>memory if you want using Vect_set_release_support().
> 
> 
> No, to build topology you need spatial index for all points. 
> 
> Radim 
>  
> 
>>Perhaps then a clean & non-invasive solution is to add a check to run
>>Vect_set_release_support() once after each 100,000 points or so? or after
>>each time the allocation grows to > 50~100mb.
>>
>>
>>Can you safely run Vect_set_release_support() mid process?
>>
>>
>>?
>>Hamish
>>