[GRASS5] Re: intersect sites with polygons?

[Radim Blazek]

On Monday 01 July 2002 03:53 pm, Christoph Simon wrote:
> > 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.

The basic framework is Vect_overlay(); lib/vector/Vlib/overlay.c
where should go all standard ovelay operators because may be used
also in other modules. 

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

I started in dig_defines.h :
/* Overlay operators */
#define GV_ON_AND     "AND"     /* intersect */
#define GV_ON_OVERLAP "OVERLAP"
 
typedef enum {
    GV_O_AND,
    GV_O_OVERLAP,
} OVERLAY_OPERATOR;

Here we can add CONTAINS, as it is standard operator. There is 
also Vect_overlay_str_to_operator ( char *str ); to convert
operator name to code; Then Vect_overlay() may be called with this code.

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

Yes, that would be useful, at least types (BTW polygons are not used,
just areas and "." (dot) may be used in map names). 
Order numbers are not used, just categories like mymap.l(45)
Also SQL statement would be useful: mymap.l(flow > 50). We already
discussed this and I don't know conclusion, this scheme
c = a.a(12) AND b.p
may be replaced by:
c = select(a, AREAS, 12) AND select(b,POINTS)
which is less effective but easier to develop and maintain.

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

Use Vect_str_to_cat_list();

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

I would expect AND.

> 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? 
Should be:
p - point
l - line
b - boundary
c - centroid
a - area

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

Probably, but "." may not be used. It could be possible to put 
type also to parentheses: map(pl;1-3)

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

Cannot say, but to implement more overlay operators seems to have
higher priority.

Radim