[GRASS5] Re: An internal db for GRASS
David D Gray
ddgray at armadce.demon.co.uk
Thu Feb 8 15:21:25 EST 2001
Markus Neteler wrote:
> Hi Andrea,
> Hi developers,
> On Mon, Feb 05, 2001 at 09:54:21AM +0100, Andrea Aime wrote:
> > Hi Markus,
> > I have surfed for a while yesterday searching for an internal
> > dbms for GRASS... results are not much exciting:
> > * dbf creation and reading is built in shapelib library, which
> > is already used in GRASS... but I don't see any indexing
> > features to speed up queries, it seems there is only sequential
> > access;
> > * gdbm, which can be found at http://www.gnu.org/software/gdbm/gdbm.html
> > seems to be a library to build small databases with indexing, but
> > it has not been developed for a long time (it seems a dead project);
> > * as you already said, Berkley DB is not open source, but I see that
> > it has been used in GNOME and in MYSQL, which are open source
> > projects.
> > Their license allows to use Berkley DB in an open source project
> > without fees, and it's fast and full featured. But I was wondering if
> > it can be redistriuited with grassio library, which will be LGPL to
> > allow
> > commercial products to access GRASS data (I mean, you can look at it
> > as an attempt to use Berkley db from a commercial product without
> > having to pay for a license...)
> > I've taken a look at grass51 proposal... sounds good, and I'm waiting
> > to see more.
> > Bye
> > Andrea
> Thanks for searching the web! I put this onto grass5 list for the
> Concerning Berkley DB: I just have seen that it is used in "openoffice"
> as well now (led by SUN:
> Although the license of Berkley DB is non-GPL, it seems to be usable in
> several GPL'ed projects. Perhaps our license experts here can give a
> recommendation on this? We definitly need something "handy" for 5.1.
I would just like to add my voice to support inclusion of Berkeley DB in
GRASS. If you start thinking about bringing in an external database
system for GRASS, you just keep going round in circles because nothing
is quite perfect. But DB is the best. The problems are:
1. DB has considerable version incompatibility (even with minor
versions) - but with most recent versions, this has quietened down a
bit. Most UNIX installations at least have a version (or more than one)
installed, and also there is a version v1.86 built in to glibc.
Incompatible versions 2.x, 3.0 and 3.1+ are also scattered around. If we
use it, I think it will have to be bundled, so that we can standardise
on a (recent) version. It is quite large, but perhaps parts of the
distribution could be left out - I don't know if the licensing terms
would allow this. Otherwise maybe it could be distributed in a separate
GRASS_support package, much as the KDE folk do with kdesupport, and then
allow an autoconf option to use a system installation if it is present,
otherwise require the bundled version.
2. It does not have spatial data structures. Just now there are flat
record/hash table/BTree options. It would be nice to have a system with
largely consistent features but give a wide variety of choices for the
type of key to use, including spatial types.
The GIST library does have a larger variety of data structure types to
choose from, and is aimed more at traditional uses of digital mapping,
like GIS, but is not primarily for information handling like a
traditional RDBMS. Maybe that could be used also. I think this has been
discussed before, but I don't know if anyone is using it - are there
plans for inclusion?
Traditional data handling and spatial location purposes have never
really converged, so perhaps we really need an example of each for all
the developers' needs. So, DB might do for the former and GIST for the
latter. Both could be included as support extensions.
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