[GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
----------------------------------+-----------------------------------------
 Reporter:  martinl               |       Owner:  grass-dev@…              
     Type:  task                  |      Status:  new                      
 Priority:  blocker               |   Milestone:  7.0.0                    
Component:  Default               |     Version:  unspecified              
 Keywords:  standardized options  |    Platform:  Unspecified              
      Cpu:  Unspecified           |  
----------------------------------+-----------------------------------------

Comment(by cmbarton):

 Replying to [comment:183 neteler]:
 > While checking all QGIS processing files
 (https://github.com/qgis/QGIS/tree/master/python/plugins/processing/algs/grass7)
 I have cleaned up lib/gis/renamed_options (r64056 + r64057, r64062 +
 r64063).

 A few thoughts

 >
 > The following issues are open (TODO):
 >
 >  * r.mapcalculator: outfile -> output? (any implications in the wxGUI?)

 Yes. This will break the GUI map calculator. Why the change? Doesn't the
 map calculator always create a new file?

 >  * r.param.scape: param -> method?
 >  * r.walk; percent_memory -> memory?

 These seem OK

 >
 > Then here I suggest to update for consistency:
 >
 > {{{
 > v.lidar.correction
 >        sce   Interpolation spline step value in east direction
 >              default: 25
 >        scn   Interpolation spline step value in north direction
 >              default: 25
 > --> ew_step/ns_step (as in v.surf.bspline)
 >
 > v.lidar.edgedetection
 >        see   Interpolation spline step value in east direction
 >              default: 4
 >        sen   Interpolation spline step value in north direction
 >              default: 4
 > --> ew_step/ns_step (as in v.surf.bspline)

 These are definitely an improvement

 >
 > No idea if the default values should be the same?

 If this works like v.surf.bspline, the defaults are almost always wrong.
 Some multiple of the current resolution (2X or 10X) would be better than
 the current default of 4. It is much better for this number to be larger
 than optimum than smaller than optimum.

 v.surf.bspline has an option to calculate a reasonable spline step that
 runs very quickly. I assume that this is the same algorithm found in the
 lidar processing modules. A note suggesting using this option would be
 good to add to the spline step description for all modules.

 Michael

 > }}}
 >
 > Eventually a potential issue in file "lib/gis/renamed_options":
 > {{{
 > # r.reclass.area
 > r.reclass.area|lesser,greater:value, mode
 >  --> syntax ok?
 > }}}

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:184>
GRASS GIS <http://grass.osgeo.org>