[GRASS5] Multiple attribute support in GRASS5.1:someconsiderations (long)

Radim Blazek Radim.Blazek at dhv.cz
Mon May 14 06:13:58 EDT 2001


Andrea Aime wrote:
> >
> > I think that both dbf and SQLite have some advantages. I don't think
> > we can find the 'best' system and that is the reason why I prefer optional drivers
> > for various databases. I don't see any problem in using new sqlite driver
> > beside odbc, dbf and others.
> 
> Well, my concern was SQL related: IMHO the command should be the same
> even
> if the user adopts different DBMS, I don't like much the idea of a
> special command
> for postgres, another for dbf, another for ODBC and so on. Do we pass
> the query
> to the driver and let hid decide if it is able to manage it or not?

That is how d.vect (g51) works now. One command may be used with dbf or odbc.
Modules know nothing about driver except its name. Whole comunication is
done by DBMI library.

> Well, my first task would be to get a v.overlay command working. I
> already found
> a GPL'd C library that performs polygon to polygon overlay (PolyBoolean,
> old version,
> the new version is C++ based, non GPL and uses only integer coordinates)
> it should
> be easy to adapt it to GRASS. But it doesn't work for polygon/line
> overlays, so
> it has to be extended. Moreover, there must be a fast way to locate
> polygon that
> can intersect (an R-tree or something like this). The sama applies to
> dig_point_in_area:
> useful, but slow since you have to compare each point with each polygon.
> Some
> kind of indexing is required altogheter...
> Regards
> Andrea Aime

> Radim,
>         I've been looking at the spatial operations subject.  I've
> found at least one polygon algorithm that should handle all of the set
> operations (intersect, union, etc..).  I'm working towards fully
> understanding how to implement it.  I've also been looking at some of
> the others like clipping lines with polygons (possibly resulting in
> multiple lines).  With a little more study I think I'll be ready to
> start implementing these things.

> -- 
> Eric G. Miller <egm2 at jps.net>

OK, I'll leave spatial operations for you. 
Should be spatial operations part of vector lib ( Vect_*() ) or shall
we open new vector spatial lib (VS_*()) - maybe GPL only (not LGPL). 

We could maybe start with definition of functions we want?:
int VS_analyse( struct Map_info map1, struct Map_info map2, 
     int element1 , int element2, int operator, double distance)????

operator: WITHIN, CONTAIN, OVERLAP, ... and many others (probably take names
              from some standard - openGis???)

and so on.

Radim

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'



More information about the grass-dev mailing list