[GRASS5] Re: [GRASSLIST:1187] notation standardisation

GRASS GRASS developer
1

On Sun, 26 Nov 2000, seppo kaitala wrote:

Would it be good if the notation would be same for the same kind of
consepts.

For instance in commands

v.proj map=name [out=name] inloc=name [dbase=name] [set=name]

r.proj input=name location=name [output=name] [mapset=name][dbase=name]
[method=name] [res=value]

The case r.proj/v.proj should be easy to fix, but which one is
preferrable? Also, s.proj's syntax is similar to r.proj's. But I think I
at least would prefer v.proj's shorter. Others?

MHu

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

2

On Sun, Nov 26, 2000 at 09:00:40PM +0100, Morten Hulden wrote:

On Sun, 26 Nov 2000, seppo kaitala wrote:

> Would it be good if the notation would be same for the same kind of
> consepts.
>
> For instance in commands
>
> v.proj map=name [out=name] inloc=name [dbase=name] [set=name]
>
> r.proj input=name location=name [output=name] [mapset=name][dbase=name]
> [method=name] [res=value]

The case r.proj/v.proj should be easy to fix, but which one is
preferrable? Also, s.proj's syntax is similar to r.proj's. But I think I
at least would prefer v.proj's shorter. Others?

Well, I thought we agreed a while back to use input/output whenever it
was appropriate. IMHO, a "map" is a complete printed or digital thing,
with scales, north arrows, grid marks, legends, etc... I think "inloc"
should be "location" as well (it's only 3 more characters).

--
Eric G. Miller <egm2@jps.net>

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

3

From owner-GRASSLIST@baylor.edu Mon Nov 27 09:38:39 2000
On Sun, Nov 26, 2000 at 09:00:40PM +0100, Morten Hulden wrote:
> On Sun, 26 Nov 2000, seppo kaitala wrote:
>
> > Would it be good if the notation would be same for the same kind of
> > consepts.
> >
> > For instance in commands
> >
> > v.proj map=name [out=name] inloc=name [dbase=name] [set=name]
> >
> > r.proj input=name location=name [output=name] [mapset=name][dbase=name]
> > [method=name] [res=value]
>
> The case r.proj/v.proj should be easy to fix, but which one is
> preferrable? Also, s.proj's syntax is similar to r.proj's. But I think I
> at least would prefer v.proj's shorter. Others?

Well, I thought we agreed a while back to use input/output whenever it
was appropriate. IMHO, a "map" is a complete printed or digital thing,
with scales, north arrows, grid marks, legends, etc... I think "inloc"
should be "location" as well (it's only 3 more characters).

I agree, I think it would be better to use full description name.
"inloc" is somewhat nonintuitive.

Huidae Cho

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

4

As follow-up, I also think we should use the same parameter names used
by g.list, g.copy, g.remove, etc. when input/output aren't appropriate.

So we have "rast", "vect", "sites", "icon", "labels", "region", "group",
and "3dview" to use (and maybe "dspf" ?).

Rule of thumb [proposed]:

1. If the module takes a single input and produces a single output, then
   use input=[name] and output=[name].

2. If the module just performs some action, but doesn't produce an
   output different from the input, then use the input "types" parameter
   "name" (i.e. "rast", "vect", etc...).

3. If the module has multiple inputs or outputs, then attempt to use the
   parameter names above if possible, else parameter names are left up
   to the author. So, If I had a module that took a raster and a vector
   and produced a raster, it's parameters could be:
     r.something rast=[name] vect=[name] output=[name]
   However, with some modules, there's more than one input or output of
   a single "type", so then each name should be descriptive of what its
   function is.

I don't know that we ever resolved the issue of addressing sites
attributes. Basically we have something like:

   "east", "north", "dim", "cat", "decimal", and "string";
   
for attribute names. For the "index", I don't know; maybe just "index"
when there's only one to be specified, otherwise "zindex" for "dim",
"dindex" for decimal and "sindex" for string??? I know I'm guilty of
not being consistent here.

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.

--
Eric G. Miller <egm2@jps.net>

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

5

Hi Eric,

I have added your proposal to
documents/parameter_proposal.txt

On Sun, Nov 26, 2000 at 08:34:55PM -0800, Eric G . Miller wrote:

As follow-up, I also think we should use the same parameter names used
by g.list, g.copy, g.remove, etc. when input/output aren't appropriate.

So we have "rast", "vect", "sites", "icon", "labels", "region", "group",
and "3dview" to use (and maybe "dspf" ?).

Rule of thumb [proposed]:

1. If the module takes a single input and produces a single output, then
   use input=[name] and output=[name].

I agree. This was the original concept as well, as far as I know.

2. If the module just performs some action, but doesn't produce an
   output different from the input, then use the input "types" parameter
   "name" (i.e. "rast", "vect", etc...).

I agree, this will be most intuitive. But it must be an 5.1 issue as
many modules have to be changed (breaks user scrips).

3. If the module has multiple inputs or outputs, then attempt to use the
   parameter names above if possible, else parameter names are left up
   to the author. So, If I had a module that took a raster and a vector
   and produced a raster, it's parameters could be:
     r.something rast=[name] vect=[name] output=[name]
   However, with some modules, there's more than one input or output of
   a single "type", so then each name should be descriptive of what its
   function is.

Yes, like s.surf.rst does:
[...]
  treefile Output vector file showing segmentation
  overfile Output vector file showing overlapping segments
     pcurv Profile curvature
     tcurv Tangential curvature
[...]

I don't know that we ever resolved the issue of addressing sites
attributes. Basically we have something like:

   "east", "north", "dim", "cat", "decimal", and "string";
   
for attribute names. For the "index", I don't know; maybe just "index"
when there's only one to be specified, otherwise "zindex" for "dim",
"dindex" for decimal and "sindex" for string??? I know I'm guilty of
not being consistent here.

We have to take care with dim as multi dimensions can exist (dim1,
dim2, ...). The "cat" I don't like, an "index" would be much better.
But why "dindex" for decimal and "sindex" for strings? The current name
is nice, isn't it?

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!

Concerning the "vocabulary":
Similar confusion is there with vector data:
My proposal:
category number -> index
category label -> attribute

Regards

Markus

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

6

> 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.

Concerning the "vocabulary":
Similar confusion is there with vector data:
My proposal:
category number -> index
category label -> attribute

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.)

Radim

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

7

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@jps.net>

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

8

On Mon, Nov 27, 2000 at 11:12:37AM +0000, Markus Neteler wrote:

> I don't know that we ever resolved the issue of addressing sites
> attributes. Basically we have something like:
>
> "east", "north", "dim", "cat", "decimal", and "string";
>
> for attribute names. For the "index", I don't know; maybe just "index"
> when there's only one to be specified, otherwise "zindex" for "dim",
> "dindex" for decimal and "sindex" for string??? I know I'm guilty of
> not being consistent here.
We have to take care with dim as multi dimensions can exist (dim1,
dim2, ...). The "cat" I don't like, an "index" would be much better.
But why "dindex" for decimal and "sindex" for strings? The current name
is nice, isn't it?

Well, here's the deal. I want to use the second string attribute as a
label for d.site.labels. In order to specify that, I have to specify I
want to use the "string" attribute type with the "index" of "2". If the
command should need to consider more than one attribute, such as what to
use for a cell value for a raster conversion and what to use for the
category label, then you need something like "value=decimal vindex=3,
label=string lindex=2". This is really messy, but I don't see any way
around it given the current sites format. But, I feel I'm beating a
dead horse here.

--
Eric G. Miller <egm2@jps.net>

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

9

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@jps.net>

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

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

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

10

On Tue, Nov 28, 2000 at 09:04:28AM +0100, Andreas Lange wrote:

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.

Well, I'm thinking of vector too (and maybe CELL or Reclass??). But,
your appraisal of Xbase is essentially what I thought. I only mentioned
it. I wasn't advocating it. I have done searches for database
libraries that could be "plugged" into GRASS, but haven't found anything
that seems to fit the bill.

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

I don't think Berkeley db supports the kind of strong typing for fields
I'm interested in. I think it's look-ups might be slow for large
database files as well. This is a long range TODO thing...

--
Eric G. Miller <egm2@jps.net>

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

11

Hi Eric,

the entire CVS stuff could't be compiled due to a missing reference:
/home/neteler/ggg/src/libes/LIB.i686-pc-linux-gnu/libgis.a(put_row.o): In
function 'G__write_data_compressed':
/home/neteler/ggg/src/libes/gis/put_row.c:679: undefined reference to
'G_zlib_write'

It seems that #ifdef USE_LZE_COMPRESSION was not active!
I have added a flag to
src/libes/gis/Gmakefile
to fix the problem.

Hope that's o.k with you (I'll try the new compression asap!).

Markus

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