[GRASS-dev] proposed improvements to v.select (was: How to find all vectors that overlay a given region)

On 9/19/07 7:46 AM, "Patton, Eric" <epatton@nrcan.gc.ca> wrote:

Michael Barton wrote:

beware the case where the bounding boxes overlap but the vector features
within
do not.

Good point. I don't know how to account for that since vectors are not a
continuous field.

Michael

Using v.select on the list of candidate maps whose regions superficially
overlap and then v.info -t on the output will tell you if you have any vector
geometry in the region.

~ Eric.

Eric's question and the very convoluted way of getting at an answer points
out a major weakness in the GRASS vector processing tool set. GRASS 6 is a
LOT better at dealing with vectors than any prior version. But there is
still a lack of sufficient vector query tools. 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?

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

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.

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.

Opinions?

Michael

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

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

This question is only tangentially related to Michael's topic but what
triggers it is his reference to C programmers. The pool of potential
programmers would be widened if there was some way to combine java code with
C code. Not combine as in within a particular module, but combine as having
some modules written in java compiled at the same time that the C modules
were compiled and ending up with one binary. Is this at all in the realm of
possibility?

Jerry

-----Original Message-----
From: grass-dev-bounces@grass.itc.it [mailto:grass-dev-bounces@grass.itc.it]
On Behalf Of Michael Barton
Sent: Wednesday, September 19, 2007 10:57 AM
To: Patton, Eric; Hamish; grass developers list
Subject: [GRASS-dev] proposed improvements to v.select (was: How to find all
vectors that overlay a given region)

On 9/19/07 7:46 AM, "Patton, Eric" <epatton@nrcan.gc.ca> wrote:

Michael Barton wrote:

beware the case where the bounding boxes overlap but the vector features
within
do not.

Good point. I don't know how to account for that since vectors are not a
continuous field.

Michael

Using v.select on the list of candidate maps whose regions superficially
overlap and then v.info -t on the output will tell you if you have any

vector

geometry in the region.

~ Eric.

Eric's question and the very convoluted way of getting at an answer points
out a major weakness in the GRASS vector processing tool set. GRASS 6 is a
LOT better at dealing with vectors than any prior version. But there is
still a lack of sufficient vector query tools. 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?

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

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.

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.

Opinions?

Michael

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

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

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

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. :slight_smile: 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 :slight_smile: 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 :wink: 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:>

On 9/20/07 9:43 AM, "Wolf Bergenheim" <wolf+grass@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. :slight_smile: 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 :slight_smile: 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 :wink: 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