#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 annakrat):
Replying to [comment:10 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.
There should be probably also vector version but I am aware of only one
module which could use that (r.sim.water). So that's not a big issue.
>
> 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"?
horizon_basename I would say
>
> 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?
aspect_value (the same is already in r.sim.water)
> - slope_in => slope
> - slope = ??? slope_val? vslope? val_slope?
slope_value
> - linke_in => ??? linke
> - lat_in => ??? lat
> - long_in => ??? long
the rest as you suggested
With the new standard option, do you think changing gisprompt would be a
good idea? It could be
{{{
Opt->gisprompt = "old,cell,basename";
}}}
GUI could use that instead of guessing from the parameter name. The widget
could be the standard map selection widget but when selecting the map, it
could try to cut the suffix (in case we have the standardized delimiter
such as `__`). When new series of maps are created, they could be all
added (up to some number).
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2338#comment:11>
GRASS GIS <http://grass.osgeo.org>