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

[Christoph Simon]

On Thu, 6 Jun 2002 15:15:19 +0200
Radim Blazek <blazek at itc.it> wrote:

> 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

When dealing with software which I don't know well, I generally prefer
the stable branch to avoid bad surprises while learning. But each
project has a different level of unstability. Would you think it's
high risk for me to go to grass51?

I see that many of the things which are not obvious for me have
already been solved. I hope you'll tell me that grass 51 is not high
risk ;)

Does the programming manual PDF couver the new vector features? If
not, Where can I get those?

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

That'a why I said, that I'm not qualified to do this alone. I'm just
too much at the beginning.

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

Right, but if this is a functionality planned for a later step, the
design should allow for it from the beginning. Even if the parser
doesn't do so, it shouldn't require a total rewrite to make a (hash)
table lookup for a function which might need dynamic loading. This
could be done by installing all `factory' functions already in such a
hash table and make the lookup for everything which by syntax needs to
be an operator. This is not too hard for flex/bison. The locating and
loading of these function certainly can wait.

> GRASS code must be in C.

Thanks God!

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

OK. Then we would have a parser, interpreting the commandline, much
the like r.mapcalc works (as I guess), and that will dispatch to a
function for each operation, which will output an intermediate or
final result. You will open the files according the parser's results,
look up the functions and operators, and call that function with the
needed data. Right?

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

This is certainly a good restriction for now. But if we create
temporary maps for each atomic functions, even if it's not always very
efficient, more maps wouldn't mean more programming work.

> 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

Sounds good. I guess the basic vector functions already exist to
compute permiter and area, right? They just need to be called here.

> 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

I would probably try to choose version b) as it sounds more
efficient. In version a) I imagine that we get first a map which will
essentially duplicate maps A and B, eliminating then those elements
which need to be discarded. In case of version b) this shouldn't be
the case, but I imagine, that in the end, this might be a tradeoff
between memory requirements and processing power, as in case of
version b) eventually more comparisons need to be done in certain
cases.

> 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

I'll have to dive into the programmers manual to get familiarized with
the specific types. So guessing only: MapAB is probably the header
info and ListAB the actual map data. typeAB would be either area,
line, or point. Operator is specified by an int (or enum). But why is
the resulting List a void pointer? Shouldn't it be also a pair of
Map_info and ilist? Also, the result_type can always be only one or is
this a bitfield? I guess this function returns an integer to indicate
success or failure (for instance to allocate the memory for the
resulting map or for lacking disk space, having no write permissions,
etc., to write the result).

I think your are going to take a while until having this basic
skeleton working. In the meanwhile, if you tell me that I need it,
I'll replace my grass5 by grass51 and start studying the programmers
manual.

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