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

GDAL · December 28, 2014, 2:56am

#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):

Replying to [comment:180 glynn]:
> Replying to [comment:178 wenzeslaus]:
>
> > > r63765 generates a warning if GRASS_FULL_OPTION_NAMES is set (to
anything) and the found string isn't an exact match for the given string.
> >
> > Thanks that's good but wouldn't be better to do just the `strcmp`
comparison (to be faster) and fail (with fatal error) which would show
these things in tests (errors are clearly visible, warning must be
searched for in the output). I think the primary use-case for
`GRASS_FULL_OPTION_NAMES` is when you actually want to find the long
options and then it is just more effective to fail. The secondary use-
case, I can think of, is making parsing faster which is only possible if
this check is alternative, not addition. Do you have different opinion?
(This is not necessary to decide before the release I belief because it is
not real API considering the use-cases.)
>
> I just took the simplest route for now. I don't consider performance
issues at this scale to be relevant.

I was hitting some issues when I was calling some modules to do simple
task many time, so I'm looking for ways how to decrease the cost of new
processes but I don't have any benchmark for the option parsing.

> Changing the G_warning() to G_fatal_error() would be trivial, if that's
desired.

Not sure about the others but it makes sense to me to switch to
`G_fatal_error()`.

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

GDAL · December 28, 2014, 4:00am

#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):

Continuing in what I wrote in comment:17 and following ones changed
G7:r.rgb in the way that fixed number of outputs handled by basename was
replaced by specific options. This is not only more explicit but also fits
more to the context when same rasters are used as input and in case of
`r.rgb` allows to request only some outputs.

Old `r.rgb`:

{{{
Usage:
r.rgb input=name [output=basename] [--overwrite] [--help] [--verbose]
[--quiet] [--ui]

Parameters:
    input Name of input raster map
   output Name of output basename raster map(s)
             Default: input
}}}

New `r.rgb`:

{{{
Usage:
r.rgb input=name red=name green=name blue=name [--overwrite]
[--help] [--verbose] [--quiet] [--ui]

Parameters:
   input Name of input raster map
     red Red channel raster map name
   green Green channel raster map name
    blue Blue channel raster map name
}}}

If somebody would like to learn how to write a test, this is a great
opportunity. On might do something like:

{{{
r.composite r=lsat7_2002_10 g=lsat7_2002_30 b=lsat7_2002_50 o=lsat_comp
r.rgb i=lsat_comp r=lsat7_2002_10 g=lsat7_2002_30 b=lsat7_2002_50
}}}

And then test difference of old and new maps. The results might not be
identical but should be close to each other. Another tests can check if
only one map is created when one map is requested.

I cannot work on this more but similar change as I did for `r.rgb` could
be done for G7:r.blend too. It also has an `output` option which is a
"basename for red, green and blue output raster maps".

There are some other modules I'm not completely sure about such as
G7:i.pansharpen and G7:i.topo.corr.

Some other seems that they don't need this change (e.g., G7:i.pca,
G7:i.landsat.toar, G7:i.landsat.acca, and G7:i.tasscap) because the number
of outputs is variable. However, I'm not sure how the suffixes are
generated, sometimes it seems that they are even expected on the input.
Standard basename separator (underscore, #2136) should be used in all
cases otherwise it is not really standard, now many of them are probably
using dot.

Last issue I know about is G7:r.texture where the number of outputs
depends on number of requested textures. G7:r.neighbors actually solves
this issue by using output not as a basename but as multiple and
requesting as many outputs as requested methods.

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

GDAL · January 11, 2015, 7:01pm

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

The following issues are open (TODO):

  * r.mapcalculator: outfile -> output? (any implications in the wxGUI?)
  * r.param.scape: param -> method?
  * r.walk; percent_memory -> memory?

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)

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

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:183>
GRASS GIS <http://grass.osgeo.org>

GDAL · January 11, 2015, 7:37pm

#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>

GDAL · January 11, 2015, 8:46pm

#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 annakrat):

Replying to [comment:183 neteler]:
> The following issues are open (TODO):
>
> * r.mapcalculator: outfile -> output? (any implications in the wxGUI?)

what is r.mapcalculator?

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

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

I would remove it from there, because the logic of the parameters changed
so you cannot easily map the old name to a new name.

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

GDAL · January 11, 2015, 9:17pm

#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 neteler):

Replying to [comment:184 cmbarton]:
> Replying to [comment:183 neteler]:
> > * 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?

I propose the change for consistency. Isn't the result a map rather than a
file (we use that for eg ASCII file output)? So the parameter name should
be "output" then.

Replying to [comment:185 annakrat]:
> Replying to [comment:183 neteler]:
> > The following issues are open (TODO):
> >
> > * r.mapcalculator: outfile -> output? (any implications in the
wxGUI?)
>
> what is r.mapcalculator?

No idea, I found it in the QGIS processing scripts being used.
In GRASS, it is here:
scripts/r.mapcalculator/r.mapcalculator

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

GDAL · January 11, 2015, 9:46pm

#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):

Replying to [comment:186 neteler]:
> Replying to [comment:184 cmbarton]:
> > Replying to [comment:183 neteler]:
> > > * r.mapcalculator: outfile -> output? (any implications in the
wxGUI?)
> >
> > Yes. This will break the GUI map calculator.

Perhaps some !Tcl/Tk one, I don't know. wxGUI raster map calculator is
using `r.mapcalc`. `r.mapcalculator` is not used anywhere in GRASS GIS
according to my knowledge and `grep` search.

> > Why the change? Doesn't the map calculator always create a new file?
>
> I propose the change for consistency. Isn't the result a map rather than
a file (we use that for eg ASCII file output)? So the parameter name
should be "output" then.

It should be changed to "output". Any option which is name of some kind of
output should be named "output" by default. Reason to name it different
would be for example more than one option which is a name of something on
output. Also, we are not using "file" to "denote raster map" (for various
reasons).

> Replying to [comment:185 annakrat]:
> > Replying to [comment:183 neteler]:
> > > The following issues are open (TODO):
> > >
> > > * r.mapcalculator: outfile -> output? (any implications in the
wxGUI?)
> >
> > what is r.mapcalculator?
>
> No idea, I found it in the QGIS processing scripts being used.
> In GRASS, it is here:
> scripts/r.mapcalculator/r.mapcalculator

QGIS processing needs to use `r.mapcalculator` instead of `r.mapcalc`
because it needs to convert input maps and output maps to and from GRASS
GIS but in case of `r.mapcalc`, map names are hidden in the expression.
`r.mapcalculator` on the other hand, has several options which are map
names and output is not part of the expression but also an option as it
would be for other modules.

Similar issues applies to more modules as I posted here or to the
basename/prefix ticket. I recently fixed `r.ros`. I learned about these
issues and `r.mapcalculator` in [http://lists.osgeo.org/pipermail/grass-
dev/2014-August/070342.html GRASS-dev QGIS Processing & GRASS].

`r.mapcalculator` may create some confusion because is not part of
standard GRASS GIS distribution (compilation switched off by default). It
is also not in the documentation. I don't know if the confusion is also on
the QGIS site. Another issue is that it is in Shell, not Python, so it
should not work in GRASS 7 on MS Windows as far as I understand. Finally,
so revision of messages is needed, error message "Calculating
$GIS_OPT_OUTFILE. Try expert mode." shown after `r.mapcalc` failed just
caught my eye.

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

GDAL · January 11, 2015, 10:00pm

#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):

Indeed. I was confused. I assumed that r.mapcalculator was a renaming of
r.mapcalc.

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

GDAL · January 12, 2015, 12:43am

#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 glynn):

Replying to [comment:187 wenzeslaus]:

> `r.mapcalculator` may create some confusion because is not part of
standard GRASS GIS distribution (compilation switched off by default). It
is also not in the documentation. I don't know if the confusion is also on
the QGIS site. Another issue is that it is in Shell, not Python, so it
should not work in GRASS 7 on MS Windows as far as I understand. Finally,
so revision of messages is needed, error message "Calculating
$GIS_OPT_OUTFILE. Try expert mode." shown after `r.mapcalc` failed just
caught my eye.

r.mapcalculator was never converted to Python. It was deemed unnecessary
now that r.mapcalc uses G_parser(). r.mapcalculator was created when
r.mapcalc didn't use G_parser() which meant that it couldn't generate a
GUI option dialog.

If there's some situation where it's useful, it should be converted to
Python. Otherwise, it should be removed from the 7.0 tree.

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

GDAL · January 12, 2015, 1:17am

#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):

Replying to [comment:189 glynn]:
> Replying to [comment:187 wenzeslaus]:
>
> > `r.mapcalculator` may create some confusion because is not part of
standard GRASS GIS distribution (compilation switched off by default). It
is also not in the documentation. I don't know if the confusion is also on
the QGIS site. Another issue is that it is in Shell, not Python, so it
should not work in GRASS 7 on MS Windows as far as I understand. Finally,
so revision of messages is needed, error message "Calculating
$GIS_OPT_OUTFILE. Try expert mode." shown after `r.mapcalc` failed just
caught my eye.
>
> r.mapcalculator was never converted to Python. It was deemed unnecessary
now that r.mapcalc uses G_parser(). r.mapcalculator was created when
r.mapcalc didn't use G_parser() which meant that it couldn't generate a
GUI option dialog.
>
> If there's some situation where it's useful, it should be converted to
Python. Otherwise, it should be removed from the 7.0 tree.

I think it is needed for QGIS and perhaps other things wrapping GRASS
modules. Although I don't know much, the issue appears to be that they
don't know what maps needs to be prepared. I've never really studied the
problem. There might be some other way for callers to deal with the
expression. For example, temporal framework also wraps `r.mapcalc` and its
quite successful. Or `r.mapcalc` or some module derived from it (similarly
as `r3.mapcalc` is) can just parse the expression and output the names in
some key-value/parseable form, or there can be a Python function for it.
Some inside from application developers using GRASS GIS would be helpful.

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

GDAL · January 12, 2015, 8:39am

#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 mlennert):

Replying to [comment:189 glynn]:
> Replying to [comment:187 wenzeslaus]:
>
> > `r.mapcalculator` may create some confusion because is not part of
standard GRASS GIS distribution (compilation switched off by default). It
is also not in the documentation. I don't know if the confusion is also on
the QGIS site. Another issue is that it is in Shell, not Python, so it
should not work in GRASS 7 on MS Windows as far as I understand. Finally,
so revision of messages is needed, error message "Calculating
$GIS_OPT_OUTFILE. Try expert mode." shown after `r.mapcalc` failed just
caught my eye.
>
> r.mapcalculator was never converted to Python. It was deemed unnecessary
now that r.mapcalc uses G_parser(). r.mapcalculator was created when
r.mapcalc didn't use G_parser() which meant that it couldn't generate a
GUI option dialog.
>
> If there's some situation where it's useful, it should be converted to
Python. Otherwise, it should be removed from the 7.0 tree.

+1 for removal. If there are any issues with using the grass7 r.mapcalc in
other software (e.g. QGIS) then let's try to solve these issues.

Moritz

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

GDAL · January 12, 2015, 1:52pm

#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 neteler):

Replying to [comment:183 neteler]:
> * r.param.scale: param -> method?
> * r.walk; percent_memory -> memory?

Done in r64088 + r64089.

> {{{
> 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)
>
> No idea if the default values should be the same?
> }}}

Parameters renamed in r64083/r64085 + r64084/r64086.
The default values I have still left as before.

TODO: r.mapcalculator, r.reclass.area entry in lib/gis/renamed_option

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

GDAL · February 18, 2015, 7:34pm

#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 martinl):

Replying to [comment:192 neteler]:

> Parameters renamed in r64083/r64085 + r64084/r64086.
> The default values I have still left as before.
>
> TODO: r.mapcalculator, r.reclass.area entry in lib/gis/renamed_option

Is it still open?

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

GDAL · February 20, 2015, 7:22am

#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 neteler):

Replying to [comment:193 martinl]:
> Replying to [comment:192 neteler]:
>
> > Parameters renamed in r64083/r64085 + r64084/r64086.
> > The default values I have still left as before.
> >
> > TODO: r.mapcalculator, r.reclass.area entry in lib/gis/renamed_option
>
> Is it still open?

r.reclass.area is done.

r.mapcalculator was proposed to be removed if not needed by QGIS
Processing. I wonder how harmful it is to just keep it.

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

GDAL · February 20, 2015, 1:32pm

#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):

Replying to [comment:194 neteler]:

> r.mapcalculator was proposed to be removed if not needed by QGIS
Processing. I wonder how harmful it is to just keep it.

`r.mapcalculator` documentation should say that it is only for QGIS and it
should not be used by others because it is not guaranteed.

I have very limited QGIS Processing knowledge but I guess QGIS Processing
still needs `r.mapcalculator` because there is not way how QGIS Processing
can know which maps to import and which maps to export. From my
understanding, the only way to know would be if standard `r.mapcalc` would
offer a flag (e.g. `-l`) which lists the inputs and output(s?):

{{{
> r.mapcalc -l "test1 = test2 + test3 + 5"
input=test2,test3
output=test1
}}}

and does only the parsing, not the actual computation. In GRASS GIS, this
could be used for example, by GUI to validate the expression. Instead of
flag, a separate module can be used (as mentioned in comment:190).

I'm not sure how serious it is but as mentioned in comment:187,
`r.mapcalculator` is a Shell script and Shell script are no longer
supported by standalone GRASS GIS. But perhaps it is not an issue because
QGIS installs its own GRASS GIS on MS Windows, OSGeo4W probably contains
some shell and all systems except for MS Windows just have some shell.

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

GDAL · February 20, 2015, 1:55pm

#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 martinl):

Replying to [comment:195 wenzeslaus]:
> I'm not sure how serious it is but as mentioned in comment:187,
`r.mapcalculator` is a Shell script and Shell script are no longer
supported by standalone GRASS GIS. But perhaps it is not

right, it's a Shell script and currently disabled in Makefile. So let's
remove it from trunk and relbr70. Any objection?

> an issue because QGIS installs its own GRASS GIS on MS Windows, OSGeo4W
probably contains some shell and all systems except for MS Windows just
have some shell.

I needed anyone can rewrite `r.mapcalculator` to Python and publish as
Addons.

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

GDAL · February 20, 2015, 4:29pm

#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):

Replying to [comment:196 martinl]:
> Replying to [comment:195 wenzeslaus]:
> > I'm not sure how serious it is but as mentioned in comment:187,
`r.mapcalculator` is a Shell script and Shell script are no longer
supported by standalone GRASS GIS. But perhaps it is not
>
> right, it's a Shell script and currently disabled in Makefile. So let's
remove it from trunk and relbr70. Any objection?

This will break QGIS Processing `grass7:r.mapcalculator` algorithm:

https://github.com/qgis/QGIS/blob/master/python/plugins/processing/algs/grass7/description/r.mapcalculator.txt

If expect that QGIS Processing will not work with 7.0.0 and that this is a
feature for 7.0.1 or later, then it is fine I guess.

> > an issue because QGIS installs its own GRASS GIS on MS Windows,
OSGeo4W probably contains some shell and all systems except for MS Windows
just have some shell.
>
> I needed anyone can rewrite `r.mapcalculator` to Python and publish as
Addons.

This sounds good. QGIS "just" has to ensure that Addons will be installed
(QGIS Processing currently does not support Addons, only things from core
which are
[https://github.com/qgis/QGIS/tree/master/python/plugins/processing/algs/grass7/description
explicitly listed]).

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

GDAL · February 20, 2015, 4:50pm

#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 martinl):

Replying to [comment:197 wenzeslaus]:
> If expect that QGIS Processing will not work with 7.0.0 and that this is
a feature for 7.0.1 or later, then it is fine I guess.

`r.mapcalculator` and other remaining shell scripts removed in r64697 and
backported in r64700.

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

GDAL · February 21, 2015, 3:09am

#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 glynn):

Replying to [comment:195 wenzeslaus]:

> I have very limited QGIS Processing knowledge but I guess QGIS
Processing still needs `r.mapcalculator` because there is not way how QGIS
Processing can know which maps to import and which maps to export. From my
understanding, the only way to know would be if standard `r.mapcalc` would
offer a flag (e.g. `-l`) which lists the inputs and output(s?):

Such an option would be fairly simple to add. Most of the relevant logic
is already present in execute() in r.mapcalc/evaluate.c.

The initialize() function populates the list of input maps (in
r.mapcalc/map.c or map3.c), which can be used to generate the list of
inputs. Each top-level assignment expression defines an output.

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

GDAL · February 21, 2015, 8:47am

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

* status: new => closed
* resolution: => fixed

Comment:

It seems to me that there is no open issue related to this ticket. I am
taking liberty to close the ticket, feel free to reopen if needed.

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