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

David Finlayson david_finlayson at yahoo.com
Mon Nov 27 02:12:37 EST 2000

As a user issue, I like the way some command fields
can be shortened in the fashion of r.watershed. Saves
some typing at the command line...I would rather
things be consistent rather than short however.

--- "Eric G . Miller" <egm2 at jps.net> 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].
> 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 at jps.net>

David Finlayson
david_finlayson at yahoo.com
University of Washington 
Box 351310 
Seattle, WA   98195 - 1310

Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.

More information about the grass-user mailing list