[GRASS5] 5.7.1

[Radim Blazek]

Helena wrote:
> it is not v.surf.rst that is the problem, it is v.in.sites that takes 
> extremely
> long even for medium size site files. So it is hard to test it when one 
> cannot
> get his data imported - it was already meantioned in the list.
>>
>> Idea of 6.0.0 is to give people what is available now.
> 
> what is available now is still a development version,
> at least for the applications that use substantial work with point data
> (Jaro says that he has to use 5.4 because he just can't get the work 
> done in 5.7)
> But I think that at least the developers should use 5.7 extensively so 
> that it
> can be released and provide the functionality that people expect.
> If all of us currently involved keep working at this pace we can have a 
> much
> better version that could be released for Christmas - it is really 
> mostly small things that are needed,
> the biggest problem that really prevents me using it is converting 
> larger site files.

5.7 is used more by normal users than by developers and they want stable 
version in their distributions. If 5.7 is slow with large data sets it 
does not mean that it cannot become stable version. It is ok with me to 
write in announcement that 6.0 is not suitable for making dems from 
datasets > ?00000 points.

Users working with large datases did not seem to be interested in 5.7 
development and testing.

I have cca 35 items on TODO > 6.0 and most of them have higher priority 
(for me and most users, I believe) than optimisation for large point 
data sets.

Can you post here times consumed by?:
s.in.ascii
v.in.ascii -t
v.in.ascii / dbf
v.in.ascii / postgres
insert attributes using insert statements + db.execute (in one step)
   / dbf
   / postgres
v.in.sites / dbf
v.in.sites / postgres
v.surf.rst layer=0 (i.e. z coor)
v.surf.rst / dbf
v.surf.rst / postgres
s.surf.rst (5.4)

so that we can better identify a problem?

How many values (columns) do you need for LIDAR interpolation, zcol only 
or scol too?

Radim