[GRASS-dev] About v.distance, v.what.vect (wrt "count points within...").

[Markus Metz]

Moritz Lennert wrote:
> Markus Metz wrote:
>>
>> Start from scratch:
>>
>> I've put a new module in grass-addons, called v.vect.stats. It counts
>> points in polygons, fairly fast, but, as the name implies, can do a
>> bit more. Optionally, it calculates statistics for areas based on the
>> attributes of all points falling into an area. Currently supported
>> methods are sum, average, median, mode, min, min_cat, max, max_cat,
>> range, stddev, variance, diversity. The meaning of min_cat and max_cat
>> is the category value corresponding to the observed minimum/maximum
>> value, e.g. the hospital with the largest number of beds and not the
>> largest number of beds.
>>
>> The module is meant as the companion to v.rast.stats, update area
>> attributes from raster: v.vect.stats, update area attributes from
>> vector
>>
>> Have fun,
>>
>> Markus M
>>
>> PS: No entry on wiki because I am not sure what will happen with the
>> module. If it's regarded nonsense, it will be removed again. OTOH, it
>> might end up in trunk.
>
> No nonsense in my eyes. Very nice and useful little module.
>
> In terms of usage time, the parts that take most time with large files (the
> 600,000 points and 100x100 grid used before) are the creation of the spatial
> index

That's why it's faster in grass 7

> and (if a stats method is applied) the collecting of attributes from
> the points vector (at one point we will probably have to attack db driver
> efficiency issues in GRASS... example: do we really have to create a select
> cursor and loop through every line this returns ?). The actual
> point-in-areas is very fast !
>
> A few small questions/remarks:
>
> - Any special reason why you construct a whole SQL statement to add the
> columns, instead of using db_add_column() (defined in
> lib/db/dbmi_client/c_add_col.c) ?
>
No special reason, I simply forgot about db_add_column(), thanks for the tip!

> - Maybe add a key to point_column_opt to call it point_column (instead of
> the default "column")
>
Yes. I was also thinking about pcolumn, ccolumn, scolumn as keys,
these would allow shortcuts like pc, cc, sc. Other modules also use
e.g. qcolumn instead of query_column.

> - If one sets a method and a stats_column, but no point_column, the first
> two settings are simply ignored. Maybe a fatal error would be better (I took
> me a bit of time to understand that I had forgotten the point_column.

Ah, ok, will do.
>
> No time for more, but I really think this would be a useful addition to
> trunk...
>

Thanks for testing!

Markus M