[GRASS5] Re: [GRASSLIST:3976] Re: intersect sites with polygons?

[Christoph Simon]

On Mon, 1 Jul 2002 13:23:15 +0200
Radim Blazek <blazek at itc.it> wrote:

> > So it *should* be possible to write 'v.points.in.polygon' reading a
> > vector points map (eventually generated with s.to.vect) and a
> > polygon vector file.
> > Maybe we find a volunteer to code that?
> 
> As this is one of MANY spatial analysis, it should go to
> v.mapcalc (already started) and function available is:
> int Vect_point_in_area (struct Map_info *, int, double, double);  
> (takes into account islands)
> then 
> v.mapcalc "selpol =  pol CONTAINS sites"

Radim, how could we use these functions in v.mapcalc? I'm thinking to
integrate them like I did with the math functions. But also
dynamically loading (this is already working), eventually using a
wrapper, could be a good approach, as it seems that those functions
are in active development. I think we could get a bunch of quite
useful things to work quickly in v.mapcalc.

To make work the above syntax

> v.mapcalc "selpol =  pol CONTAINS sites"

v.mapcalc's lexical scanner needs to reconize the word CONTAINS and
the parser will have to know which function to call. If there is a
substantial set of applications this can and should be done. More
operator words like this? A syntax which allows immediate
implementation of such a function would be:

	v.mapcalc "selpol = contains (pol, sites);"

In this form it will be enough to write an external module which
provides a function called "contains", accepting two MAPs as argument,
and creating and returning a new MAP which will get the name selpol.

The way v.mapcalc pretends to deal with this, is that until a function
point_in_poly() or contains() becomes active, no test is made wether
the given maps actually have something which can contain something
else, or which can be contained. This is to minimize the number of
different types v.mapcalc's scanner and parser have to deal with. But
thinking of this problem, I could imagine that it might be useful to
extend the syntax a bit:

	mymap.p[3]	select third polygone
	mymap.l(45)	select all lines with attribute 45
	mymap.a		use only areas (closed polygons)

Within v.mapcalc, e.g., before performing the action, only a struct of
type MAP is moved around. This struct is defined in v.mapcalc only and
different from any struct of such name in Grass, if that exists. The
lexical scanner could extract these suffices and add it as a new
member of MAP. Of course, the above syntax could get confused by a map
which is actually called "mymap.a", but I think, maps do not have any
extension normally. OTOH,

	mymap.pl

could be acceptible to choose any polygon or line, eventually followed
by an object or attribute specification, which might also allow for
other extensions like

	[2,4-6,9]

to select the objects 2, 4, 5, 6, and 9. The most complex syntax I can
think here, would be several letters for each acceptible type of
object, an expression to select a set of objects and another to select
a set of attributes, all combined by logical OR. And if an exclamation
mark preceds a letter or digit or range, that could be excluded.

For instance, this could allow to visualize the object another
program/function reported to have an error, and with an apropriate
replace function, that only object could be changed (non)interactively
and nongraphically.

Would there be enough application to do this? Which are the letters
beside p, l, a we would need? Are brackets and parenths OK or should
there be anything else? I chose them, as [] should remind of an array,
i.e., the nth object in this map, and () is like a function, as the
attribute is given in function of what is associated to an object.

Also, if we allow to select a particular object (first suffix) or
attribute (second suffix), how useful would it be to be able to
perform a loop in v.mapcalc? Loops and conditionals are not being
considered for now, but could be done with some effort. Then all or a
certain number or type of objects can be scanned in the map and,
according to certain conditions, processed in a dependent way. I would
probably try to mimic a "for" and "if" construct of the C
language. Interesting enough to spend the time?

-- 
Christoph Simon
ciccio at kiosknet.com.br
---
^X^C
q
quit
:q
^C
end
x
exit
ZZ
^D
?
help
.