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

[Christoph Simon]

On Tue, 4 Jun 2002 17:57:02 +0200
Radim Blazek <blazek at itc.it> wrote:

> (I have switched to developers list)

I'm not subscribed to that, but it's OK for me.

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

Agreed. I was meaning r.mapcalc as a guide in syntax and formalism; in
naming only, if there is really an analogue functionality. But even in
this context, there are important differences: For example, a raster
has just a dot at each point, but a vector map might have an area,
line or point or a combination of several. Depending on the particular
function, a syntax extension could be introduced, like mapA:L for only
line objects in mapA. If the boolean AND operator means the
intersection, a statement like "mapA:A AND mapB:P" would select all
sites from map B which are in areas of mapA. Of course, I also can
specify a region convert mapA to a raster and create a MASK, unless
the region is very big and the vectors have a high resolution, such
that the raster would fill my disk.

> > 	mapC = mapA OP mapB
> 
> Yes. Do you mean that mapX represents geometry here?

I meant geometry here. If I AND two areas (e.g, intersection) and the
area of mapA had category 5 and the area of mapB had category 10,
which should be the attribute of the resulting area? I think, there is
no `plug and play' solution for it. One solution might be to renumber
the categories and label them by concatenating the original labels,
separated by a caller defined character (e.g., '+'). Later, these new
areas could be reclassified based on the new labels.

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

In this case, I meant to leave this as part of the function
definition, which consists of the arguments and type of arguments to
be used. The idea is not actually to perform attribute calculations,
but to compute vectors in dependency of attributes. This way, I could
select (output) a line if it is in an area which has an attribute e.g.
greater than a certain threshold. As the output is the unchanged
object (line), the attribute of that should also remain unchanged. I
do realize that this is still a simplification, as it would have to be
defined what happens to lines which cross the area's boundary. I could
leave it out, I could just include it, or I could truncate it to the
piece within the area. This can be solved either by using flags, or by
deciding arbitrarily what seems to be the most frequent case. (Here I
would probably choose the last option).

I don't know how much automatic optimization is possible. When
combining more than one of these operations, temporary maps will have
to be build. Maybe this is another difference to r.mapcalc.

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

I am not aware of any standard for spatial relation, but if there is
one, my vote is to follow it as long as practical. The functions
mentioned in both sections seem very useful. These are not very long
lists, so they might be a good starting point. But rather than trying
to define a complete set of any useful function, I would try to create
an interface which facilitates the addition of new functions. If this
infrastructure would exist and there was a good description of how to
access and manipulate the data, I probably already would have
contributed some (maybe useless) functions.

The attempt of finding the complete set of useful functions shows that
this appears to be an endless game. Maybe it would be possible even to
provide a mean to dynamically load user functions, much the like SQL
does. If it is not necessary to recompile a grass module, allowing a
site not even having the grass sources online, interactive development
could provide solutions for very specific cases, where a standard
module just wouldn't make sense. The most frequently used functions
could form a growing basic set.

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

You are totally right. I am at the very beginning in learning grass,
and there are many modules I'm not yet aware of.

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

The aims of JTS seem promising, but actually I hate java. This is
probably the reason why I didn't enter that site when looking for
additional modules. My programming is pure C only, mainly in
networking and a bit of RDBMS. In any case, I'll have a closer look to
what they are doing.

To actually contribute, I would need to know many more details of
grass' internals. As I do this in my spare time only (mainly
weekends), this will take some time. Where I might contribute beside
pure coding, is the parser, if that of r.mapcalc can't be used, and
maybe some stuff with dynamically loading, at least on linux, though I
think there are some portable libraries that take care of this.

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