[GRASSLIST:1195] Re: [GRASS5] Re: notation standardisation
Eric G . Miller
egm2 at jps.net
Sun Nov 26 23:34:55 EST 2000
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
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 at jps.net>
More information about the grass-user