[GRASS-dev] proposed improvements to v.select

[Wolf Bergenheim]

> So I want to suggest a kind
> of roadmap to upgrading vector querying so that perhaps someone with C
> programming skills, time, and an interest in vectors could perhaps take this
> up (if I haven't eliminated everyone already). Maybe a summer of code
> project?
>

Michael,

I like these ideas, and I think that this could be a very good SoC
project (that was my first thought when I first read this mail).


> v.select (query using a vector map):
> 1. add flags -p and -g for text output instead of creating a new map. It
> would report which map(s) and feature(s)/cat(s) meet the query criteria.
> 2. allow multiple maps to be selected. This would directly address Eric's
> question. If the output is a map, it would be the equivalent of v.patch on
> all queried vector elements.
> 3. add operators "contains" and "adjacent". Contains=all vector features
> whose nodes are completely inside a polygon (or inside or touching the
> boundary). Adjacent=all vector features who share a node/point or
> line/boundary with the selecting feature. Because GRASS is topologically
> correct, adjacency information is readily available.
> 4. maybe change option names from ainput and binput to selector and selected
> or queried. This would have to wait until GRASS 7, of course. I find ainput
> and binput not very clear where used in other vector operations either
> (maybe I'm just dense).

If you are dense, then so am I ;). I always have a hard time remembering
which is which. How about this: remove parameter operator, and instead
have it like this: ainput becomes input, and binput becomes, depending
on what one wants to be done, either overlap, contains or adjacent.
Another alternative could be ainput ==> input and binput ==> selector.
It would be cool if in input would support multiple maps.

> 
> v.what (query using coordinates):
> 1. add flags -p and -g for current behavior (-pg could be the default if we
> wanted to do this before GRASS 7)
> 2. add "output=" option to allow v.what to create a new map from the results
> of its query, like v.select does
> 3. allow multiple maps for input, as with the suggestion for v.select
> 4. allow coordinates to be read optionally as a line or area boundary (-l or
> -a?) instead of only as individual points.
> 5. add operators overlap, contains, adjacent.
> (This also would make possible interactive vector selection with a mouse
> drawn box or polygon from the GUI)
> 
> In other words, have v.select and v.what work the same except that v.select
> uses a vector map for querying and v.what uses a set of coordinate points.

Yess!! This is something I've missed. :) Don't forget the where
parameter, which allows one to query by a db where clause. (I know this
is part of d.vect, but IMHO it belongs here). Also perhaps rename this
module to v.query.

> 
> v.overlay (boolean combination of maps):
> 1. drop the ainput and binput. Replace with just input.
> 2. allow multiple maps to be entered into input, not just 2
> 3. deprecate v.patch because v.overlay with the OR operator replaces it.
> (If we wanted to do this before GRASS 7, we'd have to create a new module,
> maybe named v.combine or something like that because this changes the
> default behavior of v.overlay).
> 
> I think that this should give us a full range of vector data spatial
> management tools.

Support for multiple maps would be really cool :) Do you think it would
add value to add a where parameter to allow restriction by attribute query?

Actually I've been thinking about having where and cats parameters
available for most vector commands. What do you think, would it be too
much work, and not enough gain?

In summary I think that these improvements would be a great enhancement
to GRASS vector operations, and I'm all for supporting them. If all else
fails I'll eventually code them myself ;) But I think it is a nice idea
to make this into a SoC project next summer, if you feel you can wait
that long.

--Wolf

-- 

<:3 )---- Wolf Bergenheim ----( 8:>