[GRASS5] Database linking question

[David D Gray]

"Eric G . Miller" wrote:
> 
> On Tue, Jan 02, 2001 at 06:16:04PM +0000, David D Gray wrote:
> > Hi Eric
> >
> > Thanks for your remarks. My question was perhaps over-brief, because
> > what I'm looking for is something different from the usual questions
> > about RDBMS's...
> 
> Okay, I thought this was in reference to a native "embedded" attribute
> system (long term storage...).  Anyway, some of the things I've been
> following would appear to have the kind of flexibility you're looking
> for; however, there's the C++ -> C bridge which is harder than the
> reverse.
> 
> Of interest...
> 
> Coldstore  (An object/mmap storage system; C++; Alpha; limited to
> platforms with ELF objects; Probably never practical for use in GRASS).
> 
> MetaKit ("efficient embedded database library"; C++/Python/Tcl; Stable;
> portable, flexible, reportedly handles "moderate-sized" databases ("few
> Megabytes") very well and does well with larger databases when
> programming works with it's "columnwise data model"; Has testimonials! ;
> platform agnostic; promising except for that C++ issue).
> 
> xBase (well known format(s); C++ library; limited data types and ranges;
> 16bit charsets not supported???; requires "cleaning" to remove dead
> data; possible but C++ issue again);
> 
> I've started investigating the "educational" RDBMS Leap just to see one
> implementation of a relational database that tries to stay close to the
> Relational Algebra and C. J. Date's view's on RDBMS's.  Not really
> useful in itself for an embedded database system, but worthy of study.
> 
> Anyway, I'll keep hammering away at this, but for GRASS to be a
> contender in the Vector GIS arena it really needs a robust, data
> attribute system (Relational is nice, SQL is unnecessary and probably
> undesirable).  I really don't want to try to reinvent the wheel either
> (I'm not sure I'm up to it anyway) so I'd prefer to find an existing
> solution that can be "plugged" in.  I'm not sure what you all have in
> mind for the future GRASS Vector library, but I think it needs to take
> into account this need and should try to make it simple for the module
> programmer to handle (perhaps transparent in some instances).
> 

Eric

Perhaps we are really looking for more than one candidate here. I have
developed a simple segmented approach to importing vector data from
general sources. The thing holding it up is lack of a rapid-access,
key-controlled storage structure. Something like a hash table or Btree
is what is required, a spatial type like R-tree is not required and
would probably be no faster than GRASS's inbuilt binary tree. Also join
capabilities is not required. Though gdbm is perhaps not maintained, it
is light and supplies all the needed features. So I think I will go
ahead and embed this as a plugin (for 5.1, not the stable branch). A
wrapper would be created for module-level access, so that the backend
can change without hassling the module programmers.

I feel that Berkeley DB is the best candidate for the embedded `native'
attribute database. I have looked at the documentation, and it seems to
fit the bill. It has basic relational capabilities and a good design of
API, including Tcl interface. This also would be a plugin (and then gdbm
would be redundant). I seem to recall that there were some license
worries when Sleepycat took over the development and released versions
2/3, but the OSI hails this as a shining example of open-source
development, so it is presumably OSD-compliant. On the face of it, it
seems like a typical BSD-type license. Nevertheless that would have to
be checked out.

I've just read up on the fruits of last night's discussion (my night
here in Europe). The possibility exists of using postgresql as one kind
of `interchange format'. I agree with Rich that there is no problem in
principal in emulating an arc-node format with postgresql types. For
example, a vector map called `vmap' could be represented by a set of
tables like:

CREATE TABLE vmap_arcs ( 
	line_id int PRIMARY KEY,  --  ID number for line
	lines path,               --  the vertices of a line
	line_bb box               --  the line's bounding box
)

CREATE TABLE vmap_poly (
	area_indx int,    --  Joins to vmap_areas.area_id
	sub_indx int,     --  The index of the component line
	line_indx         --  Joins to vmap_arcs.line_id
)

CREATE TABLE vmap_isles (
	parent int,     -- Joins to vmap_areas.area_id (for areas)
	child int       -- Ditto
)

CREATE TABLE vmap_areas (
	area_id int PRIMARY KEY,  --  ID for primary spatial entity
	area_bb box               --  Bounding box for entity. May be more
robust than
				  --  using a centroid for spatial location
)

CREATE TABLE vmap_att (
	id int,     -- Joins to vmap_entities.entity_id
	[specific data fields now go here]
)

My understanding is that as of version 7.0.x, postgresql supports

1) foreign keys, allowing efficient joins of the kind described above.

2) a native R-tree implementation for querying geometric types.


Regards

David

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