[GRASS5] Re: [GRASSLIST:3809] Re: Vector Manipulation

[Radim Blazek]

(I have switched to developers list)

On Friday 31 May 2002 04:45 pm, Christoph Simon wrote:
> 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. 

What you writes below ("no reason to implement useless functions just because 
the do exist in r.mapcalc") seems to me more reasonable.

> 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

Yes. Do you mean that mapX represents geometry here?

> or
> 	mapC = functionX (mapA, mapB)

And here, mapX represents attributes (categories)? Vector attributes
are saved (or should be, or will be) saved in external RDBMS. I would
left this calculations for that system.

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

Which OP (operators)? Probably similar used for methods in 
http://www.opengis.org/techno/specs/99-050.pdf
2.2.1.3, 2.2.1.4. Or anybody knows some better 'standard'
definition of spatial relations?

> 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 ;-)

Reprojecting is done by v.proj or v.transform now. I would not mix all to one 
module.

Do you think, you could contribute somehow. I think that if you could
write reliable module for just few most common spatial operations, it would
be appreciated by most of GRASS users. Note that for example JTS project 
exists: http://www.vividsolutions.com/jts/jtshome.htm
and some functions are already present in grass (v.cutter).


Radim