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

[Andrea Aime]

Radim Blazek wrote:
> 
> Andrea Aime wrote:
> >
> > Frank Warmerdam wrote:
> > >    SQLite is at http://www.hwaci.com/sw/sqlite/ and I have been quite
> > >    impressed with it from my modest involvement.
> > >
> >
> > Wow, is seems really impressive. A good SQL support and index in only
> > 9000
> > lines of code... Radim, how it compares to g51 dbf driver? Should we
> > take
> > a more closer look at it? It seems that SELECT support is quite
> > complete,
> > and indexing capabilities are interesting for querying large data.
> > Import/export
> > to and from PostgreSQL is another interesting plus...
> > Regards
> > Andrea Aime
> 
> SQLite seems to be a good solution. The only problem I see is that there is no
> GUI front-end which was one of my criteria. Dbf files may be edited in StarOffice
> and MSAccess (including forms). I thing that we don't have human resources for developing
> database front-end within grass and we don't want to reinvent wheel. So if such front-end
> is available is important.
> 
> BTW: SQLLite files are not portable (The key size thus depends on the size of
> an integer on the host computer.) but that doesn't matter.
> 
> 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?

> > PS: I'm interested both in spatial indexes both in overlay operations...
> > can I join your work :-)?
> 
> Everybody is welcome. David is working on spatial related tasks.
> I thing that you could start work on spatial operation (overlay) functions.
> We have only dig_point_in_area() in g50 and we need ALL spatial operations
> between ALL element types. Have you any ideas?
> 

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

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