[GRASS5] Re: intersect sites with polygons?

[Christoph Simon]

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

> On Wednesday 03 July 2002 06:34 am, Glynn Clements wrote:
> > Dots are very common, probably more common than underscore or dash
> > (minus). I suggest choosing a character which has meaning to the shell
> > (e.g. "$"), as people tend to avoid using map names which require
> > quoting.
> 
> Can scanner recognize more combinations separated by one char?:
> (I think so because type is char, and cat is number)
> map
> map$lp
> map$2,5
> map$lp$2,5

These suffices are not implemented yet, and the scanner I'm using in
the program is not more than a simulation of a flex scanner which I've
prepared so far as a skeleton only.

The logic will be this: If a token is found which is a `string', it
will be looked up in a symbol table still in the scanner, trying to
decide wether it is a variable name (of a certain type), a map, a
function name, etc. This is not always possible, as "a = ..." can not
tell the type of "a" if that hasn't been used before, and the user
might not have typed more at this time. If that string happens to be
the name of an existing vmap, which will always be known already in
the scanner, the extension will also be interpreted in the scanner,
added to a map-descriptor, and passed to the bison parser just as a
MAP token. The bison parser will not be directly aware of this list. I
know this is a somewhat strange approach, but it's the only way to
deal with lots of types.

> Category ranges (25-35) should be also alloved, preferably without
> necessity of quotes:
> map$lp$3,7,25-30,120

As v.mapcalc will be more strict with spaces as token separators than
r.mapcalc, this is perfectly possible without quoting. But I tend not
to omit () and []. Even if object indices aren't normally used in
grass, they can come in handy within v.mapcalc. For instance, we could
have a function which will create a list of indices selecting objects
by a more complex set of conditions, like several SQL statements
creating a union of indirect attribute dependencies. These objects
could be written to a new map, or used directly to perform another
operation. With very large lists, this could get a bit slow, as I'm
using linked lists; even a binary search on a linked list with
millions of items can take a fair amount of time. In such cases
writing a new intermediate map might prove more efficient.

Hm. I think another choice might be the colon. What about:

	mymap:l(25-30)

Does this look better?

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