[GRASS5] Re: notation standardisation
neteler at geog.uni-hannover.de
Mon Nov 27 06:12:37 EST 2000
I have added your proposal to
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:
category number -> index
category label -> attribute
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'
More information about the grass-dev