[GRASS5] Re: intersect sites with polygons?

[Radim Blazek]

On Tuesday 02 July 2002 07:06 pm, Christoph Simon wrote:
> > 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.

Then we need second set of constants for operators in v.mapcalc,
somehow mapped to GV_O_*. (?)

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

Grass knows just areas, which may or may not contain islands. 
Areas are formed by list of boundaries.

> interpret the "new" as a selector. How frequent do you think are dots
> in mapnames?

For example list of vectors in my first mapset, I looked into:
cabla.1  cabla.base  cabla.base.lid  cabla.base.nodes  cabla.base.raw  pok 

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

Yes, I ment, order number defined in [] are not used.
("Category" is used in grass for attribute attached directly to elements.)

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

Internaly, order numbers are used, but because, such number may change
during the life of an element, should not be used by users. To identify
any element, category number should be used in user interface.

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

Why not use similar function for type/category?

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

We should not deal with this in v.mapcalc at all. As I mentioned in other
mail, some 
Vect_list_elements ( 
    struct Map_info *Map,
    char   *where, // sql where condition
    struct ilist *list_of_elements)
should create list of (order) numbers of elements, we want to process.

> > I would expect AND.
> No. There is no attribute which satisfies the condition "2 AND 4".

Of course, but I thought "a AND 2" (areas of cat 2)

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

Boundaries (edges) and centroids (area labels) define areas, see 
"Programmer's manual: 6 Vector Maps"

Radim