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 
Databases
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?).
cheers,
John
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?