[GRASS5] Re: intersect sites with polygons?

[Christoph Simon]

On Wed, 3 Jul 2002 20:45:02 +0100
Glynn Clements <glynn.clements at virgin.net> wrote:

> Well, the trend in language design seems to be moving away from
> requiring whitespace. More generally, the trend in language design
> seems to be ever-closer compatibility with C; it's open to debate as
> to whether this is good or bad, but it's getting pretty clear that
> taking an opposite path in any particular instance is going against
> the flow.

Sorry, didn't get your point here. "10a" (unquoted) isn't a legal
C-language token. OTOH, I don't restrict anything which isn't
restricted in C, all the other way round. Using quotes, any name can
get any characters. v.mapcalc currently even is more liberal than
grass, as it also allows for 8-bit characters. In any case, using
quotes, anything is possible.

> The main factor is the complexity of a typical statement. For
> r.mapcalc, the most common usage is a single expression with a few
> operators, included on the command line. Beyond that, most expressions
> fit on one line, so it's easier to require a backslash for multi-line
> statements than to require a semicolon per statement.
> 
> OTOH, it sounds as if v.mapcalc is aimed more at substantial scripts
> than simple expressions; in which case, multi-line statements may be
> far more common. If the overall syntax differs significantly from
> r.mapcalc, it may help to pick a different name, to avoid implying a
> similarity which doesn't really exist.

Everybody seems to agree that GRASS isn't very complete when talking
about vector functionality. This isn't a problem, until a user needs
to solve a particular task. And then, the straight forward answer is
to write a grass v.* module which will do the job. This seems to grow
bigger and bigger, probably more than in the case of raster maps.

I myself, a GRASS beginner, reached this point more than once, so I
wondered why there isn't a program which would allow me to adapt to
any particular situation, much in the style of r.mapcalc. So the very
first idea was to use v.mapcalc that same way r.mapcalc is used, with
short, single action statements. This was and remains the first aim of
v.mapcalc. I'm no r.mapcalc expert, but I did see quite long
`onliners' in mapcalc tutorials.

While trying to describe a v.mapcalc program in concrete terms, it
seemed that there is a certain need to justify it's existence, as many
of the hypothetical examples could be solved using already existing
modules, or modules which had already been proposed. I don't think
it's a problem to have more than one way to solve a particular task,
but vector complexity itself seems to push me to write something which
appears more an interpreter than a calculator: allowing to deal with
non-map entities like pointlists (or maybe even SQL entities) on one
hand, and differenciated processing of object lists proceeding from
one or more maps and yielding a new map, using programming language
like idioms like loops and conditionals. Of cource, when scripting is
available, a comment character will be clearly necessary, yet another
step r.mapcalc didn't have to deal with.

This second aim isn't really so different from the first, so I still
expect those scripts to be little more than a few lines, but as
flexible as needed to deal with the most special vector tasks. This,
at least, is the aim. I do not pretend to be able to predict how it's
actually going to be used.

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