[GRASS5] Re: intersect sites with polygons?

[Christoph Simon]

On Tue, 2 Jul 2002 11:16:56 +0200
Radim Blazek <blazek at itc.it> wrote:
> 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.

Would be a question of joining a list and unifying calls.

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

Hm. These operators need to be recognized by the lexical scanner and
processed by the parser. It's usually bison who defines an integer
value for them.

> 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 operators are handled is this:
- lexical scanner converts character sequence to integer value (token)
- parser recognizes sequence of tokens which is associated with an action
- the action performs the function call.

This means, at any point, there must be an association between the
operator and the function performing the operation: Any binary
operator will always yield a function call. This can be context bound,
i.e., the CONATINS operator may have a different meaning (calling a
different function) according to the operator type which might be a
map or not. It's more, I plan to allow creating arrays of operator to
function association, so a user could create her own context, loading
for instance a function which will always/never deal with attributes
in a certain way (like accessing SQL). Unless there is a fixed and
clearly defined set of standard operators, I really think we should
wait with this until having something working and a minimum set of
functions. To test these functions, we always can use the function
call syntax rather than the operator syntax. In any case, the operator
syntax basically is programmed, it's just a question of replicating
the things for CONTAINS as they are done with '+'.

> Yes, that would be useful, at least types (BTW polygons are not used,
> just areas

Hm. I thought there is a difference between polygone and area, as the
area is only a closed polygon. So which are actually the types of
objects which may be found in a vector map?

> and "." (dot) may be used in map names). 

I did think about this, but there are very few characters which are
not allowed in the filesystem and which are not already used else
(like / which is used for division). I chose the dot because I thought
it's not very common for map names and there is a way out: First one
could say "map.new.[]". Only the last dot is used, and an empty
bracket would indicate all. When the lexical scanner is working, there
will be a special object called string, which can be really anything
within double or quotes. So quoting "map.new" means that "new" is an
extension and not a selection, while just map.new would try to
interpret the "new" as a selector. How frequent do you think are dots
in mapnames?

> Order numbers are not used, just categories like mymap.l(45)

I guess you ment mymap.p[3], as this is actually an orderal
number. mymap.l(45) was the example to select an object having
attribute 45.

If I run v.support, I thought to have remembered that it tells which
object caused any problems. How else could you identify an object? In
any case, I think it might be useful to leave such a syntax, at least
internally, as it might allow to process object by object in a loop.

> Also SQL statement would be useful: mymap.l(flow > 50).

I think SQL statements should not enter the parser scope. This is far
too unlimited. We need to deal with them somehow else.

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

My suggestion was to provide a function with an SQL statement (or a
piece of that) as a string. I didn't start implementing this, as I
wanted to wait for input from you.

I think the easiest way to deal with this is using a loop with
conditionals. I don't know how much SQL knowledge we can assume from a
grass user, but you can always form an SQL statement in such a way
that it returns only a boolean or at least a numerical value. This
would free us from having to deal with date strings or other more
complicated stuff.

In any case, it is obvious that SQL needs still much more thought.

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

Certainly a good idea. I'll have a look at that.

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

No. There is no attribute which satisfies the condition "2 AND 4".

> Should be:
> p - point
> l - line
> b - boundary
> c - centroid
> a - area

Fine. This is what I can work with. But I didn't know about boundary
and centeroid. What's that?

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

I can't do this with parenths, as this looks like a function call. The
semicolon doesn't help here, as the parser must work with at most one
token of look ahead. But I could use braces, though I think this looks
ugly:

	map{p[1-3]}

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

I agree. I think it's good to keep this things in mind, but I plan for
the next weekend, what I announced on sunday. When all that is done,
we can publish the whole thing, it'll be possible to integrate real
world functions, and I'll still be able to extend the syntax.

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