[GRASS5] GPL C++ libs and databases

John Reid jgreid at uow.edu.au
Fri Aug 3 09:34:20 EDT 2001

Hi all,

First, a warning.  I am probably going to contradict myself several 
times here.  Also, my base assumption is that interest is in developing 
under a GPL licence.  Purpose of this mail is to determine potential 
interest - I don't actually have a plan (sketch maybe ;-)

C++ spatial data libraries

Going by the comments on the PostGIS list re JTS (C++TS?), 
mention/interest on the GRASS list of the TPIE library and the existence 
of some vector code in OSSIM, I take it there is a considerable amount 
of interest in a GPL C++ library for GIS/SIS data types?  Recently I 
have been looking at reviving the GFC library originally created by L.J. 
Qian, which seems very promising but is probably in need of a major 
overhaul (possibly too clever for its` own good - I would prefer code 
that is easier to understand/maintain).

However to me it seems crazy for development to take place in all these 
seperate threads.  Is anyone interested in some kind of co-ordinated 
effort?  I'm no guru, but I would love to help out in any way I can :-)


I am personally convinced that storage of spatial (3D+) data in a DBMS 
is critically important for sharing data/information between/within 
applications.  As far as PostGIS goes - yeehaa.!!!  Unfortunately, I 
still have this feeling in the back of my mind that bothers me regarding 
PostgreSQL.  AFAICT, it is currently committing both of C.J. Date's "2 
great blunders" for ORDMS.  I have a feeling that this is making life 
much more difficult than it should be - I keep having dreams of abstract 
data types that do not need registration of any C (or other binary 
libraries) for access/mutation of tuples (composite types), only for 
SQL99 user defined types (atomic types).  Or am I missing something 
here?  (besides the fact that the atom has actually been split ;-)

Seems to me there are several options (hopefully not mutually exclusive):

    * persuade the PostgreSQL team to implement domain = class (seems to
      me currently implements relvar = class).  This would require some
      changes to the system tables at least, not sure about implications
      for bootstrap code and existing apps (I'm barely literate in C,
      anyway I'm not particularly keen to work under BSD licence -
      hopefully GPL will continue to fly in the long term!).
    * mySQL? (I know nothing about its internal architecture, so can't
      comment as to its long term suitability).
    * roll our own GPL ORDBMS.  This might not be as large a task as it
      would initially seem (dream on!).  Unfortunately it seems like the
      code from the Uni of Wisconsin Paradise project has been lost from
      the public domain (seems to me from skimming the papers related to
      the project that it would have been a great bootstrap).
       Unfortunately I don't think any of the open source projects could
      afford to purchase the code line from NCR (current owners), even
      in some kind of joint venture.

    However the Wisconsin SHORE code is still available as a basis for
    further development (hopefully mutual - however if no interest from
    Wisconsin might generate interest from other DBMS types anyway).
     Also, there might be  the possibility that the Predator/Cougar
    projects might be amenable to open sourcing their codebase
    (currently research lic), which would be a great bootstrap to
    development effort (and hopefully of mutual benefit!  the current
    project maintainers seem very interested in distributed databases
    and also spatial/image data to some extent - these features are what
    we want, right?).


P.S.  As a volunteer developer, I am prejudiced against developing under 
other more open licences than those conditions that are imposed by the 
GPL (or my understanding of it anyway).  Common feeling?  I really don't 
want to potentially give away the products of my labour to some 
monolithic corporation without the expection of any return obligation 
(either in terms of futher development of the codebase or 
money/food/shelter) ... fair?

More information about the grass-dev mailing list