[GRASS5] Re: vector point dataset
Radim Blazek
blazek at itc.it
Tue Nov 16 11:44:30 EST 2004
I tried to change the library so that spatial index is not
stored to file and it is built only if needed.
Test on vector : 149971 boundaries, 99972 areas, 99972 centroids
module | Old version | New version |
v.build | 55s | 54s |
v.distance (from 1 point ) | 6s | 29s |
v.distance (from 100 points) | 3m50s | 4m30s |
It means, that if a module needs spatial index, it takes
5 times more time to get it ready then before, but the difference
is less important in real applications, because usually it is
not used just once.
There are circa 10 modules from 60 which needs spatial index.
We can have either faster 10 modules or we can spare the space occupied
by spatial index file.
What is your opinion?
Radim
Radim Blazek wrote:
> It is normal.
> Spatial index is important also for points, I think. Otherwise
> v.distance for example
> must always go through all points. Say that you have another vector with
> 4,000,000
> and you want to find the nearst in the first one. Withou spatial index it
> must do 4,000,000 x 4,000,000 checks.
> Spatial index is stored as tree of boxes, 6x8 bytes each, so 430 M is
> possible.
>
> Any advice appreciated....
>
>
> Brent Wood wrote:
>
>> I have a vector point dataset (ascii XYZ, the basis of a DEM).
>>
>> I'm importing into GRASS5.7 with
>>
>> cat <file> | v.in.ascii -Z output=nzxyz xcol=1 ycol=2 zcol=2 catcol=0
>>
>> There are about 4,000,000 XYZ points.
>>
>> The vector coor file is 150Mb. GRASS is now building the topology &
>> index.
>> The topo file is almost 200Mb and the sidx is at 430Mb and growing.
>>
>> Is this normal? It seems very excessive for a point dataset. A spatial
>> index & topology make more sense for line/polygon data, with over 4x the
>> actual data volume to store this extra info doesn't look right somehow...
>>
>> The system is a SuSE Linux 9.1 23 bit OS on A64 3500 with 1Gb memory.
>> Swapped out 1.4Gb & still using 800Mb main memory.
>>
>>
>> Any advice appreciated....
>>
>>
>> Brent Wood
>>
>>
>
More information about the grass-dev
mailing list