[GRASS5] Re: intersect sites with polygons?

[Radim Blazek]

On Wednesday 03 July 2002 02:09 pm, Christoph Simon wrote:
> And boundaries are polygons which can be open or closed?

Boundaries are lines (polylines). One isolated area may be formed
by one closed boundary, though it is not typical case.

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

Colon is nicer.

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

Yes, if the list is created for old map, it may not change until
the map is updated and topo is rebuilt. If the list is created 
by v.mapcalc, it is OK. What I want to avoid is to enter order
numbers by user:
lista = select_by_box( mapa, (0,0,5,5) ) - is ok 
listb = list( 1,5,8 ) -  could cause some problems, for example:
user found somehow list 1,5,8, then rebuilt topology, and these
numbers changed to 1,2,3. 
OTOH, if user knows about this, it is powerful tool.

> > 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 need WHERE, because FROM is defined in DB file for each map/field.

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

Who are "SQL people"?

> What if one map is associated with more than one table/column
> in the database?

Defined by field + DB file. (I think, that there is realy timem, to
test grass51.)

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

OK, may be it is, but if you allow optional TABLE/KEY, you must support
these options in each module. In most cases, one map is associated with
on table and user does not even want to know, how it is done.
I think, that in v.mapcalc is possible to create list of categories
by sql select statement and then use this list to select features:
mapb = extract_by_cat ( mapa, sql_select ( "select id from x where f > 1") );
but in most cases:
mapb = extract( mapa, "f > 1");

Radim