[GRASS5] Re: notation standardisation

[Markus Neteler]

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 at geog.uni-hannover.de with
subject 'unsubscribe grass5'