[GRASSLIST:3810] Re: Vector Manipulation

[Christoph Simon]

On Fri, 31 May 2002 16:10:59 +0200
Radim Blazek <blazek at itc.it> wrote:

> On Friday 31 May 2002 03:50 pm, Christoph Simon wrote:
> > But what I think would really be necessary is a v.mapcalc, able to
> > operate on vertex coordinates as well as the segments themselves. I am
> > not familiar enough with grass to judge the usefulness of this for
> > most users, but my guess is, that many would benefit from it. Although
> > I have a clear idea how it should work, I'm far from understanding
> > grass to write it myself. This would make certain things very easy.
> 
> Most of us are waiting for that, however this task will not be so easy,
> I think. Understanding grass vectors is not so difficult, I can help.
> For now, can you describe in more details your clear idea how it should
> work?

I didn't really analize such a program in depth, so maybe this is a
bit ingenuous, but I think it actually must try to mimic r.mapcalc as
close as possible, as this would reduce the learning curve of those
who already know that. Without understanding how vectors are described
in Grass, I can only start from the user's perspective (this might be
a good thing). If r.mapcalc allows:

	mapC = mapA OP mapB
or
	mapC = functionX (mapA, mapB)

v.mapcalc should do the same. In case of the first form, I would
expect v.mapcalc to operate on entities, i.e., points, lines,
areas. In that case, the effect of the operation should be expectable:
line(a) plus line(b) should output both in mapC. Line(a) AND line(b)
only, if that line is present in both. In case of an area, I would
expect to get the intersecting parts accordingly, etc. It would be a
matter to create a table of all functions from r.mapcalc and see the
most obvious behaviour. I'm sure there will be cases, where the
`obvious' behaviour is not obvious at all. But on one side I think
this is not going to be always the case (with plus and AND it is not),
and on the other, this would be just a matter of discussion among the
users. Isn't this on of the advantages of open software?

In any case, basing v.mapcalc on r.mapcalc is meant to be a starting
point, not a restriction: there is no reason to implement useless
functions just because the do exist in r.mapcalc, and there is no
reason to not implement others which r.mapcalc doesn't have, but which
are useful. One difference of course would be right away, that vector
operations on coordinates will need a tolerance (snapping
distance). At least initially, I would implement this globally for the
whole operation. Of course regions and mask would have to be respected
mucht the like r.mapcalc does.

The second form would allow for functions that operate by function
definition on the coordinates of the vertices or on the attribute
values, maybe limited to one map. Then a construction like

	macC = reproject (mapA, NEW_PROJ) AND mapB

I didn't look at the sources of r.mapcalc, but I guess the grammar
parser should already exist and be useful for this. The rest is
filling in the function ;-)

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