[GRASS5] Re: intersect sites with polygons?

[Radim Blazek]

On Friday 05 July 2002 03:59 pm, Christoph Simon wrote:
> Max is a classic example for an aggregate function. That's why I
> mentioned it. Right now, I'm not sure to use the terms attribute and
> category correctly. In a DEM, say we have 15 different elevation
> values, so each would be one of 15 categories, but then, we might have
> an association such that category 5 means 250m, which would be the
> attribute. Is this correct? In case it is, I was talking about
> attributes, not categories.

Yes, 5 is category, 250 attribute.

> 	SELECT myfunc (col1, col3, col7) FROM tableX WHERE ....;
>
> (Of course, myfunc() needs to have been defined before, but this
> varies from RDBMS to RDBMS and is usually persistent to different SQL
> sessions.) Then, SQL would call myfunc() for each row included by the
> WHERE clause, and myfunc() would return a value which represents a
> computed (aggregate) column.
>
> Here col1, col3, col7 could be the different climate values at three
> different moments. Following the above example, myfunc() would use
> col1 and col3 to predict what should have happend at the moment stored
> in col7. After applying a prediction algorithm to these two columns,
> the result is compared with the value of col7, computing a number with
> reflects the degree of match in some useful scale, or maybe forming
> cluster ranges. Then you can draw a map where each cluster range is
> associated with a certain color. Or you take the individual values and
> create a height field, showing in a 3D space where the algorithm was
> specially good or bad. This way you have a visual impact over the
> quality of the algorithm you applied initially in myfunc.

It should be possible:
d.vect where="myfunc (col1, col3, col7) > 0.5 AND ..."

> The whole point is, that I don't believe that you can freeze some
> parts of an SQL statement which are actually variable. If you do,
> you'll lose SQL power. And setting the columns globally is essentially
> a freeze, because if I would have to change it all the time, I would
> prefer to do so directly in the statement. OTOH, using such a global
> value as default still could be a good idea, as I agree that there
> will be many cases, where you don't use that additional power.

You can ALWAYS use the trick I mentioned in my last mail:
where cat in ( select ... )

Radim