[GRASS5] Re: intersect sites with polygons?

[Christoph Simon]

On Wed, 3 Jul 2002 11:36:04 +0200
Radim Blazek <blazek at itc.it> wrote:

> > 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_*. (?)

Don't worry about them. In the end, it will always be a function
call. The transformation of what the user types to the functions
actually called is exactly what the parser is for. Your function will
not have to know about it.

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

And boundaries are polygons which can be open or closed?

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

OK. For now, the useful choices seem to be $ or :, though I have a
slight preference for the colon.

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

Hm. When a user mentions a map in v.mapcalc, this map is not supposed
to be changed, but a new map should be created, right? If not, this
represents a problem, for instance, if I create a list of objects to
work only on that list from there on. If it is changed before or after
a v.mapcalc session, this wouldn't be a problem. Under which
circunstances this orderal number can change?

> > 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 also reached this point, but I will need to know more details. Is it
enough to use a character string for any complete SQL statement, or do
I need to split it up into FROM and WHERE clauses?

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

My problem here is, that I suspect that the SQL people are still at
the very beginning ant that they are likely to change mind in this
point. What if one map is associated with more than one table/column
in the database? what, if certain attributes need to use SQL-computed
values which need to go into the FROM clause? The global setting of
table and column is a very sever restriction.

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

Right. We need OR if it's the same type and AND if they are different
types.

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

Yep. Lot's of homework I haven't done yet.


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