[GRASS5] Re: notation standardisation

[Andreas Lange]

Hi,

The idea to implement the attributes for sites files with a database
sounds very good.
But i would recommend the DBMI interface instead of Xbase, as Xbase IMHO
has problems with portability from little endian to big endian machines
and with localization/internationalization.

Maybe other dbms might be an alternative too, like Berkeley db. With the
DBMI it should be possible to make use of different systems.

For the notation standardisation we should refer to the element_list (in
src/general/manage/lib/Element_list and in grass5/etc/element_list).
This list has the standardisation for the element names, aliases and
directories. Whenever possible, a name from this list should be used.

Maybe we should generate a sort of "database" of the used terms and the
module used in. This could give hints where to change the notation.
Generation with the xml-output should be possible with some scripts. It
is IMHO always simpler to discuss/review this with examples.

cu,

Andreas

Eric G . Miller wrote:
> 
> On Mon, Nov 27, 2000 at 12:30:45PM +0100, Radim Blazek wrote:
> > > > NOTE: I'd like to get some kind of simple attribute database implemented
> > > > in GRASS, but so far I haven't found anything that we could just plug in
> > > > with a few tweaks.  The closest might be the Xbase library, but it's C++
> > > > and I don't know how well Xbase files might support efforts at
> > > > localization in the future.  Anyway, I bring this up, because
> > > > identifying attributes by "type" and "index" is really cumbersome.
> > > To have direct support would be very useful (instead of fiddling with
> > > external databases). Xbase might be a good suggestion!
> >
> > How do you want to use such database. My suggestion is to write
> > new driver for dbmi so that we would have one interface and
> > could switch to other RDBMS by selecting some other driver.
> 
> Yes, that sounds good.  I haven't seen any documentation on the dbmi
> interface though, which makes it harder to figure out how to program
> for.
> 
> > > Concerning the "vocabulary":
> > > Similar confusion is there with vector data:
> > > My proposal:
> > > category number  -> index
> > > category label   -> attribute
> 
> Yep, but if GRASS has a native database driver that can always be
> guaranteed to work, then all we really need is the "index" for the
> vector object and it's associated attribute table.  User's could then
> select which "field" to use for labelling functions.
> 
> > We use 'category number' for distinguishing more caterories on
> > one element and 'category' for what you call 'index' (id,key) in new vect
> > library (for grass51). Code is already written with these names.
> > ('Category' is still only link to external database.)
> 
> I will have to look when I get a chance.
> 
> --
> Eric G. Miller <egm2 at jps.net>
> 
> ----------------------------------------
> If you want to unsubscribe from GRASS Development Team mailing list write to:
> minordomo at geog.uni-hannover.de with
> subject 'unsubscribe grass5'

-- 
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange at Rhein-Main.de - A.C.Lange at GMX.net



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