[GRASS-dev] proposed improvements to v.select

[Michael Barton]

On 9/20/07 9:43 AM, "Wolf Bergenheim" <wolf+grass at bergenheim.net> wrote:

>> 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).

Thanks. I hope that this can energize some new vector coding sometime soon.
SoC seems like a good way to do this for projects where others don't have
time.

> 
> 
>> 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.

I like the 2nd idea best, because it is simplest and goes along with other
GRASS code: selector=<vector map> and input=<vector[,vector,vector,...]>

> 
>> 
>> 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?

Adding an attribute query option would make this even more powerful. It's
definitely an additional amount of coding, but there should be enough
examples already there to follow (e.g., in d.vect).

> 
> 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.
> 

Thanks for the enthusiastic support.

Michael


__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton