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

[Radim Blazek]

On Tuesday 04 June 2002 08:00 pm, Christoph Simon wrote:
> 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.

Sounds nice, but now, let us try to define how to do these things
on internal/library level (your "infrastructure" below), expression 
parser will probably follow.

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

I think, that all these new features should be done in grass51 vectors (which 
was started as first step for new vector functionality like this).
There are two possibilities to combine attributes in g51:
1) attache new categories, create new table which contains (selected) columns 
from both input tables 
2) attach 2 categories to resulting graphic elements, each linked to one of 
original tables

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

There are usualy different operators for such cases:
- within 
- completely within 
- intersect (cut the the part within - I'm not sure about the name)

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

I fully agree - create interface. Such contributions may not be useless,
because almost nothing is in grass available now.

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

I would simply start with some most common, loading user functions may be
probably postponed. 

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

GRASS code must be in C.

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

I think that I can prepare that infrastructure and you can receive
pure geometry in
struct line_pnts { double *x,*y,*z; int n_points;  int alloc_points; };
or may be with some cals like: Vect_get_line_areas() - to get areas on
both sides of boundary.

I'll try to start with infrastructure definition
(for now I'll consider just about two overlayed vector maps):

I) Variants of results we want to get from overlay:
  a) list of IDs(internal numbers) of elements in one map, which fulfil
     operator condition (if no breaking required)
  b) list of elements (i.e. list of new line_pnts structures created by
     intersecting)
  c) list of IDs (for both maps) + sizes (length or area) - if just report
     is required, for example which lines intersect which areas and how long
     are these intersections

II) How to do that? I see 2 ways how to analyse vectors:
  a) 1) Overlay whole maps and create new map (intersect all lines
        and areas) and save as standard grass vector map where for 
        new elements will be saved its origin (area 456 in MapA and
        line 123 in MapB
     2) Go through all new elements and select that which fits the operator
  b) Go through all elements of map and check if fulfil required rule

Function (probably only suitable for II-b):
Vect_analyse/overlay ( 
  struct Map_info *MapA, 
  struct ilist *ListA,   // list of elements in MapA to operate on
  int typeA,             // type of elements in MapA to operate on
  struct Map_info *MapB, 
  struct ilist *ListB,  
  int typeB,            
  int operator,          // AND, WITHIN, COMPLETELY_WITHIN, ....
  int result_type,       // Ia, Ib, Ic above 
  void *List)            // list of results


Radim