[GRASS-dev] Re: [GRASS-user] GRASS 7 vector topology format changed

[Markus Metz]

Hamish wrote:
> Markus Metz wrote:
>> IOW, the bounding boxes are not
>> gone, they are still there, but no longer stored in two
>> different locations, only in one location.
> ...
>> No, the new, reduced format performs better with larger
>> datasets. For small datasets, there should be not much of a
>> difference in terms of speed, only in terms of memory
>> requirements.
>
> (formerly we'd get to about 3 million points on a system with
> ~ 2gb ram)
>
If GRASS_VECTOR_LOWMEM is set, hundreds of millions of points should
be possible. These changes should generally push up the limits for
processing larger vector datasets.
>
>> > is time to run d.vect in a sub-region of the overall
>> > map a good way to test the performance difference?
>> >
>> Maybe, but d.vect is not very efficient: it goes through
>> all features, checks if a feature is inside the current region
>> and reads e.g. every area and the area's isles twice instead of
>> only once.
>> v.what, v.build, v.in.* are also good to test performance
>> differences.
>
> ok, I meant something which made heavy use of the bounding boxes.
> I guess the others do it in a less obvious way to the end-user.
>
In general, any modifications to areas, e.g. v.generalize with
boundaries, v.clean tool=rmarea, v.select.
Building topology for areas also makes heavy use of bounding boxes.

v.what is not fair to use for performance differences because GRASS
6.x needs to build the spatial index on the fly and will thus always
take much longer in 6.x than in 7.

BTW, I have reduced file I/O for d.vect type=area in GRASS 7, now
waiting for d.mon to come back...

Markus M