[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 wenzeslaus):

 Similarly, G7:r.ros uses `output` which is in fact used as `basename`:
 {{{
 output=name [required]
     Prefix for output raster maps (.base, .max, .maxdir, .spotdist)
 }}}

 G7:r.spread is not even taking advantage of that, so the change should be
 localized to `r.ros`:
 {{{
 max=string [required]
     Raster map containing maximal ROS (cm/min)
 dir=string [required]
     Raster map containing directions of maximal ROS (degree)
 base=string [required]
     Raster map containing base ROS (cm/min)
 spot_dist=string
     Raster map containing maximal spotting distance (m, required with -s)
 }}}

 The fix in this case is: use different options for each map. What about
 the names? `base_ros` or `ros_base`? Or no `ros` since the module name is
 already `r.ros`? But what about `r.spread`, should this be the same? Maybe
 we can use what is used in `r.spread` to make just few changes.

 As [http://osgeo-org.1560.x6.nabble.com/Fwd-QGIS-Processing-amp-GRASS-
 td5155460.html noted by MarkusN] QGIS Processing has problems with the
 current solution:
 > r.ros (maybe others): the output in this GRASS module is just a
 > prefix for 3/4 output maps with an hardcoded name. Processing does not
 > actually support such case.

 I hope that the multiple output used by many (e.g. `r.neighbors`) and
 suggested for `r.texture` is actually helps QGIS Processing (and others).
 Explicit options are of course the safest way.

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