[GRASS-dev] [GRASS GIS] #2338: r.horizon rename parameters
GRASS GIS
trac at osgeo.org
Mon Jun 23 04:44:44 PDT 2014
#2338: r.horizon rename parameters
-------------------------+--------------------------------------------------
Reporter: zarch | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: critical | Milestone: 7.0.0
Component: Raster | Version: svn-trunk
Keywords: r.horizon | Platform: All
Cpu: All |
-------------------------+--------------------------------------------------
Comment(by zarch):
Replying to [comment:9 wenzeslaus]:
> Replying to [comment:7 neteler]:
> > Yes, "prefix=" like in r.texture. At least standardize it:
>
>
> As I was saying in in #2136: I don't like "prefix" because
> it is not a prefix. In my point of view, we are suffixing
> the analyses name or state description to the given string.
> I prefer "basename" because it is what it is.
Ok, I used basename and, to avoid repetitions, I added
([http://trac.osgeo.org/grass/changeset/60894 r60894]) two new standard
options:
- G_OPT_R_BASENAME_INPUT
- G_OPT_R_BASENAME_OUTPUT
so If in the future we decide to change again from basename to prefix or
something else, we should be able to do this modifying only in a single
place.
But I realize that maybe is not enough. I modify the r.sun module to
handle the changed name in r.horizon, so I used G_OPT_R_BASENAME_INPUT, in
this way in r.sun the "horizon" parameter became "basename", instead I
think that would be clearer to use "horizon_basename".
So what should I do? just leave "basename" or use "horizon_basename"?
Any thoughts on this?
Also in [http://grass.osgeo.org/grass70/manuals/r.sun.html r.sun] probably
we should change:
- elev_in => elevation
- asp_in => aspect
- aspect => ??? aspect_val? vaspect? val_aspect?
- slope_in => slope
- slope = ??? slope_val? vslope? val_slope?
- linke_in => ??? linke
- lat_in => ??? lat
- long_in => ??? long
- horizon => ??? basename or horizon_basename?
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2338#comment:10>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev
mailing list