r.horizon rename parameters

[zarch]

What do you think if we rename the options from:

• elev_in => elevation (like in slope_aspect);
• horizon_step => step;
• horizon_start => start;
• horizon_end => end;
• horizon => prefix or output_prefix

[martinl]

Strong +1, for elevation should be used standardized option G_OPT_R_ELEV. Milestone moved to 7.0 (renaming options should be done before releasing 7.0), see wiki:Grass7/NewFeatures#Removedmodules

[hcho]

+1. I prefer prefix over output_prefix because it's shorter.

[martinl]

Replying to hcho:

+1. I prefer prefix over output_prefix because it's shorter.

note that you can shorten option as you want (keeping unique names), so 'out', 'output' or 'o_p' will work. output_prefix seems to be probably more informative... Also keeping consistency with other modules would be nice (probably good to have standardized option for modules which produce maps with given prefix/postfix?)

[hcho]

Oh! I never knew we could use o_p.

[wenzeslaus]

Please read #2136 and look how many modules are using particular names.

[zarch]

Functions to get the number of decimals in a string and to return a string format given the basename

[zarch]

Replying to wenzeslaus:

Please read #2136 and look how many modules are using particular names.

So I change: horizon => basename, ok?

I wrote two functions, one that return the number of decimals in a string, and another one that return a format string given the basename, the number of digits and decimals that we want to use.

I attached the code with two functions plus some tests in main() [0].

Considering that these functionalities are shared between modules I think we should put them somewhere in the GARSS C API...

Where should we put them? Any ideas?

Pietro

[0] ​http://trac.osgeo.org/grass/attachment/ticket/2338/main.c

[neteler]

Replying to martinl:

Replying to hcho:

+1. I prefer prefix over output_prefix because it's shorter.

Yes, "prefix=" like in r.texture. At least standardize it:

Also keeping consistency with other modules would be nice (probably good to have standardized option for modules which produce maps with given prefix/postfix?)

Yes, that should go into the parser.

[martinl]

Replying to neteler:

Replying to martinl:

Replying to hcho:

+1. I prefer prefix over output_prefix because it's shorter.

Yes, "prefix=" like in r.texture. At least standardize it:

Some modules are using basename I guess. We should standardize it before releasing 7.0...

[wenzeslaus]

Replying to neteler:

Replying to martinl:

Replying to hcho:

+1. I prefer prefix over output_prefix because it's shorter.

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.

[zarch]

Replying to wenzeslaus:

Replying to 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 (​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 ​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?

[annakrat]

Replying to zarch:

Replying to wenzeslaus:

Replying to 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 (​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 ​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).

[zarch]

Replying to annakrat:

the rest as you suggested

Done in ​r61096.

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).

+1

yes I think that add a basename option to gisprompt could be a good idea.

I close this ticket, we could discuss further about this in ​#2136.

[neteler]

Reopening as r61098 + r61099 are not yet backported to relbr7 (parameter name changes)

[neteler]

TODO: Besides backport check also manual page examples

[neteler]

r.horizon and r.sun parameter changes:

Backported r61096 + r61098 + r61099 in r62430, Closing.

[neteler]

Replying to neteler:

r.horizon and r.sun parameter changes:

Backported r61096 + r61098 + r61099 in r62430, Closing.

for the record: completed in r62473.