Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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 --+- Comment(by martinl): Replying to [comment:199 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. reported as #2592 -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:201 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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: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. Changing the G_warning() to G_fatal_error() would be trivial, if that's desired. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:180 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:175 wenzeslaus]: If I understand correctly, we still want to use full option names for GRASS code (and perhaps documentation) and to advise it for user scripts. Indeed. The main issues I see with abbreviations are: 1. Searching for use of an option name (grep, Ctrl+F, etc) will miss abbreviations. 2. Abbreviations make code harder to understand for people who aren't fluent in English. In this case it would be good to have a way to proof that the full option names are used, something like an environmental variable `GRASS_FULL_OPTION_NAMES` which would switch off the advanced word/character matching and `renamed_options` so that only full names would be considered as valid. 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. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:176 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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): I have taken liberty to backport the current parser state in r63772 + r63774. This including an attempt to document GRASS_FULL_OPTION_NAMES in r63773, please improve. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:177 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:176 glynn]: Replying to [comment:175 wenzeslaus]: If I understand correctly, we still want to use full option names for GRASS code (and perhaps documentation) and to advise it for user scripts. Indeed. The main issues I see with abbreviations are: 1. Searching for use of an option name (grep, Ctrl+F, etc) will miss abbreviations. 2. Abbreviations make code harder to understand for people who aren't fluent in English. In this case it would be good to have a way to proof that the full option names are used, something like an environmental variable `GRASS_FULL_OPTION_NAMES` which would switch off the advanced word/character matching and `renamed_options` so that only full names would be considered as valid. 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.) -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:178 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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): I improved options for G7:r.ros and G7:r.spread in r63777. The biggest change is actually not the longer names but the change of `output` which was just unnecessary use of basename concept. I replaced that by 4 new explicit options. (I also improved the naming but not everywhere, so feel free to change it if you have better ideas.) Although it was already discussed here or in #2136, I submitted some patches and Martin committed something, there might be more changes like this needed. The point is that it is better to avoid basename if possible because explicit options are easier to understand, better for scripting and necessary for applications like QGIS. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:179 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:167 wenzeslaus]: Done in r63741. Should be backported soon I guess. I also extended [source:grass/trunk/lib/gis/renamed_options renamed_options] with G7:r.his and G7:d.his in r63740 but with d.shade because also the module was renamed. it seems to be OK to me, please backport. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:168 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:146 neteler]:
It would be very helpful to advertise the candidates here, like:
{{{
g.region rast=rastermap -p
ERROR: g.region: Sorry, rast= is ambiguous. Choices: raster,
raster_3d
}}}
Could that be implemented?
Yes (although as part of a change which would also remove the ambiguity in
that case).
My intention is to modify the code which calls match_option()
(set_option() and check_string()) to record which options are matched. If
one option is a prefix of all of the others, the string will be considered
to unambiguously match that option. If the match is ambiguous, we now have
a list of which options matched, which can be used for the error message.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:169
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:169 glynn]: My intention is to modify the code which calls match_option() (set_option() and check_string()) to record which options are matched. If one option is a prefix of all of the others, the string will be considered to unambiguously match that option. If the match is ambiguous, we now have a list of which options matched, which can be used for the error message. This change is implemented in r63744. Currently, an ambiguous match for an option key lists the matches, but an ambiguous match for a value (opt-options) doesn't (as the error message is generated by the caller). -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:170 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:170 glynn]: This change is implemented in r63744. Currently, an ambiguous match for an option key lists the matches, but an ambiguous match for a value (opt-options) doesn't (as the error message is generated by the caller). cool! It open doors to rename options line `n,s,e,w` to `north,south,east,west` in `g.region`. The shorted options will continue to work... -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:171 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:171 martinl]:
cool! It open doors to rename options line `n,s,e,w` to
`north,south,east,west` in `g.region`. The shorted options will continue
to work...
sorry, I was wrong, attempt
{{{
north Value for the northern edge
south Value for the southern edge
east Value for the eastern edge
west Value for the western edge
top Value for the top edge
bottom Value for the bottom edge
rows Number of rows in the new region
cols Number of columns in the new region
resolution 2D grid resolution (north-south and east-west)
resolution_3d 3D grid resolution (north-south, east-west and top-
bottom)
ns_resolution North-south 2D grid resolution
ew_resolution East-west 2D grid resolution
tb_resolution Top-bottom 3D grid resolution
}}}
Command
{{{
g.region n=1 s=0 e=1 w=0 t=1 b=0 res=1 res3=1 nsres=1 ewres=1 tbres=1
}}}
fails with
{{{
ERROR: g.region: Sorry, n= is ambiguous
ERROR: Option north= matches
ERROR: Option ns_resolution= matches
ERROR: g.region: Sorry, s= is ambiguous
ERROR: Option south= matches
ERROR: Option save= matches
ERROR: g.region: Sorry, e= is ambiguous
ERROR: Option east= matches
ERROR: Option ew_resolution= matches
ERROR: g.region: Sorry, t= is ambiguous
ERROR: Option top= matches
ERROR: Option tb_resolution= matches
}}}
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:172
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:171 martinl]:
Replying to [comment:170 glynn]:
This change is implemented in r63744.
Currently, an ambiguous match for an option key lists the matches, but
an ambiguous match for a value (opt-options) doesn't (as the error
message is generated by the caller).
cool!
I meant that
{{{
g.region rast=elevation
}}}
will work, which is very good news.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:173
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:168 martinl]: Replying to [comment:167 wenzeslaus]: Done in r63741. Should be backported soon I guess. I also extended [source:grass/trunk/lib/gis/renamed_options renamed_options] with G7:r.his and G7:d.his in r63740 but with d.shade because also the module was renamed. it seems to be OK to me, please backport. Backported in r63755. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:174 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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): If I understand correctly, we still want to use full option names for GRASS code (and perhaps documentation) and to advise it for user scripts. In this case it would be good to have a way to proof that the full option names are used, something like an environmental variable `GRASS_FULL_OPTION_NAMES` which would switch off the advanced word/character matching and `renamed_options` so that only full names would be considered as valid. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:175 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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): For record: in r63704 has been renamed 'volume' options in `r.color`, `r3.colors` and `v.colors` to `raster_3d`. I would suggest do the same with `m.nviz.image`, any objections? -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:162 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:158 hellik]:
{{{
stream_rast Name for output raster map with unique stream ids
}}}
changed to `stream_raster` in r63706
{{{
stream_vect Name for output vector map with unique stream ids
}}}
changed to `stream_vector` in r63706
{{{
transmissivity_singleway Name of single-way transmissivity raster
map [0.0-1.0]
transmissivitysingleway Name of the single-way atmospheric
transmissivitymap [-]
}}}
`transmissivitysingleway` changed to `transmissivity_singleway` in r63709
{{{
walk_coeffCoefficients for walking energy formula parameters a,b,c,d
transport_coeff Name of transport capacity coefficient raster map
[s]
topidxclass Topographic index class
topidxstats Name of topographic index statistics file
tiledimension The dimensions of the tiles used in the output raster3d
map (XxYxZ or default: 16x16x8)
tilesize The maximum tile size in kilo bytes. Default is 32KB.
swatershedName for output sink-watershed raster map
}}}
no opinion here
{{{
start_rastName of starting raster points map
}}}
changed to `start_raster` in r63711
{{{
stab Set the flow stabilizing scheme (full or exponential upwinding).
staendThe user defined values that indicate start, intermediate
and end status in the indicator output space time raster dataset
sourceprojSource projection
sourcescale Conversion factor from units to meters in source
projection
soilheatflux Name of instantaneous soil heat flux raster map [W/m2]
Name of soil heat flux raster map [W/m2]
soilmoisture Name for output root zone soil moisture raster map
}}}
no opinion here
{{{
slope_tol Slope tolerance that defines a 'flat' surface (degrees)
}}}
changed to `slope_tolerance` in r63713
{{{
segmaxMaximum length of segment on network
Maximum number of points in a segment
savehistory Text file in which to save history
savesettings Name for output file where to save current settings
rgbmaps Three (R,G,B) 3D raster maps to create RGB values
[redmap,greenmap,bluemap]
Three (r,g,b) raster maps to create RGB values
[redmap,greenmap,bluemap]
productname Name of MODIS product type
pclay Name of soil clay fraction raster map [0.0-1.0]
pcurvatureName for output profile curvature map (or fxx)
Name for output profile curvature raster map
outtopidxstatsName for output topographic index statistics file
}}}
no opinion here
{{{
nwalkers Number of walkers
Number of walkers, default is twice the number of
cells
num_partitionsRead the input files in this number of chunks
npartitions Number of partitions
}}}
`num_partitions` changed to `npartitions` (to follow other similar options
like `nwalkers`, `npoints` and others - number of ...)
{{{
ncolumn Node cost column
Node cost column (number)
}}}
This is more significant issue, all of v.net modules uses various
shortened options
{{{
min_area Minimum size of area to be imported (square units)
min_size Minimum number of pixels in a class
min_slope Minimum slope value (in percent) for which aspect is
computed
mcurvatureName for output mean curvature 3D raster map
Name for output mean curvature map (or fxy)
Name for output mean curvature raster map
loadhistory Text file from which to load history
loadsettings Name of input file to read settings from
localutctime Name of time of satellite overpass raster map [local time
in UTC]
insol_timeOutput insolation time raster map [h] (mode 2 only)
infil Name of runoff infiltration rate raster map [mm/hr]
infil_value Runoff infiltration rate unique value [mm/hr]
infileInput file with one input raster map name and data point
position per line, field separator between name and sample point is |
init_time Initial time for current simulation (0) (min)
gcurvatureName for output Gaussian curvature 3D raster map
beam_rad Output beam irradiance [W.m-2] (mode 1) or irradiation
raster map [Wh.m-2.day-1] (mode 2)
}}}
no opinion here
{{{
afcolumn
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:163 martinl]:
{{{
ncolumn Node cost column
Node cost column (number)
}}}
This is more significant issue, all of v.net modules uses various
shortened options
{{{
afcolumnArc forward/both direction(s) cost column (number)
acolumn Arcs' cost column (for both directions)
abcolumnArc backward direction cost column (number)
EXPERIMENTAL: Arc backward direction cost column
(number)
}}}
see my note about `v.net` modules above
I went though v.net modules and renamed
{{{
alayer - arc_layer
nlayer - node_layer
type - arc_type
ccats - center_cats
ncolumn - node_column
afcolumn - arc_column
abcolumn - arc_backward_column
tcats - terminal_cats
nsp - npoints
coordinate - coordinates
vis - visibility
}}}
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:164
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:164 martinl]: I went though v.net modules and renamed see r63730 -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:165 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:164 martinl]:
Replying to [comment:163 martinl]:
{{{
ncolumn Node cost column
Node cost column (number)
}}}
This is more significant issue, all of v.net modules uses various
shortened options
{{{
afcolumn Arc forward/both direction(s) cost column (number)
acolumn Arcs' cost column (for both directions)
abcolumn Arc backward direction cost column (number)
EXPERIMENTAL: Arc backward direction cost column
(number)
}}}
see my note about `v.net` modules above
I went though v.net modules and renamed
{{{
alayer - arc_layer
nlayer - node_layer
type - arc_type
ccats - center_cats
ncolumn - node_column
afcolumn - arc_column
abcolumn - arc_backward_column
tcats - terminal_cats
nsp - npoints
coordinate - coordinates
vis - visibility
}}}
Thanks much. These are a great improvement. IIRC, the vector overlay/query
modules could use something similar. Perhaps already done as I've had no
time to investigate at the end of semester here. This is a lot of work I
realize but greatly appreciated.
Michael
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:166
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:161 neteler]:
Replying to [comment:159 wenzeslaus]:
However, in case of `d.shade`, I'm actually suggesting:
{{{
d.shade color=elevation shade=slope
}}}
which more describes the meaning of the input rasters for me.
Sounds good to me.
Done in r63741. Should be backported soon I guess.
I also extended [source:grass/trunk/lib/gis/renamed_options
renamed_options] with G7:r.his and G7:d.his in r63740 but with d.shade
because also the module was renamed.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:167
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:159 wenzeslaus]: It seems to me in case of `d.shade` (and perhaps few other modules) the options have unnecessary map in the name. It might be enough just to leave out the map unless it is there to distinguish from other option. I would agree with you, please feel free to apply this changes. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:160 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:159 wenzeslaus]:
However, in case of `d.shade`, I'm actually suggesting:
{{{
d.shade color=elevation shade=slope
}}}
which more describes the meaning of the input rasters for me.
Sounds good to me.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:161
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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): For those who would like to help with our effort, please check attachment:module_params_overview-2014-12-12.ods and inform us about remaining parameter inconsistencies. Any renaming should be done before we release RC1 (planned for 29/12)/ -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:152 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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):
Any objections to rename
{{{
bgcolor
}}}
to
{{{
bg_color
}}}
?
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:153
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:152 martinl]: For those who would like to help with our effort, please check attachment:module_params_overview-2014-12-12.ods and inform us about remaining parameter sorry the correct file is attachment:module_params_overview-2014-12-22.ods !!! -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:154 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:147 martinl]: since `G_ELEMENT_3DVIEW` and `G_ELEMENT_REGION3D` are not used in the code I took liberty to remove them in r63639. If no objection I will do backport to relbr70. done in r63684. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:155 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:153 martinl]:
Any objections to rename
{{{
bgcolor
}}}
to
{{{
bg_color
}}}
?
I don't see an advantage in this case. Wouldn't we have to change many
similar cases then, too?
And it would really become back_ground_color (could then be abbreviate as
bg_color) which is way too long.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:156
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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 hellik): Replying to [comment:154 martinl]: Replying to [comment:152 martinl]: For those who would like to help with our effort, please check attachment:module_params_overview-2014-12-12.ods and inform us about remaining parameter sorry the correct file is attachment:module_params_overview-2014-12-22.ods !!! for a better overview I've added a pivot analysis with options/flags, their description and the count to the sheet. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:157 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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 hellik):
Replying to [comment:154 martinl]:
Replying to [comment:152 martinl]:
For those who would like to help with our effort, please check
attachment:module_params_overview-2014-12-12.ods and inform us about
remaining parameter
sorry the correct file is
attachment:module_params_overview-2014-12-22.ods !!!
maybe some candidates?
{{{
stream_rast Name for output raster map with unique stream ids
stream_vect Name for output vector map with unique stream ids
transmissivity_singlewayName of single-way transmissivity raster
map [0.0-1.0]
transmissivitysingleway Name of the single-way atmospheric
transmissivitymap [-]
walk_coeff Coefficients for walking energy formula parameters a,b,c,d
transport_coeff Name of transport capacity coefficient raster map [s]
topidxclass Topographic index class
topidxstats Name of topographic index statistics file
tiledimension The dimensions of the tiles used in the output raster3d
map (XxYxZ or default: 16x16x8)
tilesizeThe maximum tile size in kilo bytes. Default is 32KB.
swatershed Name for output sink-watershed raster map
start_rast Name of starting raster points map
stabSet the flow stabilizing scheme (full or exponential upwinding).
staend The user defined values that indicate start, intermediate and end
status in the indicator output space time raster dataset
sourceproj Source projection
sourcescale Conversion factor from units to meters in source
projection
soilheatfluxName of instantaneous soil heat flux raster map [W/m2]
Name of soil heat flux raster map [W/m2]
soilmoistureName for output root zone soil moisture raster map
slope_tol Slope tolerance that defines a 'flat' surface (degrees)
segmax Maximum length of segment on network
Maximum number of points in a segment
savehistory Text file in which to save history
savesettingsName for output file where to save current settings
rgbmaps Three (R,G,B) 3D raster maps to create RGB values
[redmap,greenmap,bluemap]
Three (r,g,b) raster maps to create RGB values
[redmap,greenmap,bluemap]
productname Name of MODIS product type
pclay Name of soil clay fraction raster map [0.0-1.0]
pcurvature Name for output profile curvature map (or fxx)
Name for output profile curvature raster map
outtopidxstats Name for output topographic index statistics file
nwalkersNumber of walkers
Number of walkers, default is twice the number of
cells
num_partitions Read the input files in this number of chunks
npartitions Number of partitions
ncolumn Node cost column
Node cost column (number)
min_areaMinimum size of area to be imported (square units)
min_sizeMinimum number of pixels in a class
min_slope Minimum slope value (in percent) for which aspect is
computed
mcurvature Name for output mean curvature 3D raster map
Name for output mean curvature map (or fxy)
Name for output mean curvature raster map
loadhistory Text file from which to load history
loadsettingsName of input file to read settings from
localutctimeName of time of satellite overpass raster map [local time
in UTC]
insol_time Output insolation time raster map [h] (mode 2 only)
infil Name of runoff infiltration rate raster map [mm/hr]
infil_value Runoff infiltration rate unique value [mm/hr]
infile Input file with one input raster map name and data point position
per line, field separator between name and sample point is |
init_time Initial time for current simulation (0) (min)
gcurvature Name for output Gaussian curvature 3D raster map
beam_radOutput beam irradiance [W.m-2] (mode 1) or irradiation
raster map [Wh.m-2.day-1] (mode 2)
afcolumnArc forward/both direction(s) cost column (number)
acolumn Arcs' cost column (for both directions)
abcolumnArc backward direction cost column (number)
EXPERIMENTAL: Arc backward direction cost column
(number)
}}}
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:158
GRASS GIS http://grass.osgeo.org
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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):
It seems to me in case of `d.shade` (and perhaps few other modules) the
options have unnecessary map in the name. It might be enough just to
leave out the map unless it is there to distinguish from other option.
`d.shade` can change from
{{{
d.shade drapemap=elevation reliefmap=slope
}}}
to
{{{
d.shade drape=elevation relief=slope
}}}
It seems to me that the map in the name does not add much information
(that it is clear that input is some map or raster).
However, in case of `d.shade`, I'm actually suggesting:
{{{
d.shade color=elevation shade=slope
}}}
which more describes the meaning of the input rasters for me.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:159
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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): Many more updates related to the new element name changes, I tried to catch all: * r63628 + r63629 update g.region/g.rename calls to use new element names * r63630 + r63631 update g.region/g.rename calls to use new element names While I was at it: * r63634 + r63635: some shell test scripts updated Now eagerly waiting for the nightly run of the testsuite at http://fatra.cnr.ncsu.edu/grassgistests/summary_report/index.html -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:144 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:137 hcho]: No, not the last word of the option name. You cannot skip any words separated by an underscore. rm= is not ambiguous in this case because the shortest option name that matches rm= is raster_map=. If one wants raster_map2=, use rmap2=, not rm2= (no abbreviation inside a word). I mean the shortest option name with no more following underscores. 'r' for raster, 'm' for map, and no more underscores after 'raster_map'. This still has a couple of problems: 1. match_option() now needs to return the strength of a match, and the code which calls it (two places: once for option names, once for opt-options values) needs to consider this when determining whether a match is ambiguous. 2. match_option() now has to try to find a stronger match if there is one. E.g given an option named ab_b and an argument ab, the b can match the second letter of the first word or the first letter of the second word. Currently, it will find the first case and return. The change would require that it finds the first, but keeps searching for a stronger match in case an ambiguity subsequently needs to be resolved. The prefix rule suggested in [comment:101] also requires complicating the calling code, although it doesn't require changes to match_option() itself. Specifically, it needs to record all of the options which matched; it can't be reduced to finite state. But keeping track of which options matched would allow us to provide a more informative error message in the event that the given name is ambiguous (i.e. the error message could list all of the matches). The strength approach is perhaps a bit simpler to implement for the caller, in that it doesn't need to track which options matched, only the count and strength. If an option provides a strong match, and all prior matches are weak, it sets the match counter to one (discarding any number of weak matches). Once at least one strong match has been found, any weak matches will be ignored. At the end, a match is unambiguous if the count is one (i.e. one weak match and no strong matches, or one strong match and any number of weak matches). OTOH, it's also a bit less convenient, as the user has to provide some part of each word, even when this doesn't reduce the set of candidates. It's also possibly less clear to the user exactly what they should type to avoid the ambiguity. To be honest, the last point is my objection. I'd be less concerned about the increased complexity of match_option() if the result was an unambiguously better user experience (although I am slightly concerned about the possibility that match_option_1() might go from having exponential complexity in theory to actually having exponential complexity in practice). -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:145 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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):
A question related to the match_option. It concerns the change with
potentially most impact in the next weeks regarding the users:
{{{
g.region rast=rastermap -p
ERROR: g.region: Sorry, rast= is ambiguous
# as it should now be
# g.region raster=rastermap -p
}}}
It would be very helpful to advertise the candidates here, like:
{{{
g.region rast=rastermap -p
ERROR: g.region: Sorry, rast= is ambiguous. Choices: raster,
raster_3d
}}}
Could that be implemented?
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:146
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:143 martinl]: Replying to [comment:142 neteler]: I suppose that view3d can be removed and region3d -- region_3d? AFAIS we don't need `region3d`? Region settings contains 3D info by default. since `G_ELEMENT_3DVIEW` and `G_ELEMENT_REGION3D` are not used in the code I took liberty to remove them in r63639. If no objection I will do backport to relbr70. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:147 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:147 martinl]: Replying to [comment:143 martinl]: Replying to [comment:142 neteler]: I suppose that view3d can be removed and region3d -- region_3d? AFAIS we don't need `region3d`? Region settings contains 3D info by default. since `G_ELEMENT_3DVIEW` and `G_ELEMENT_REGION3D` are not used in the code I took liberty to remove them in r63639. But also the code indicated in comment:142 should be cleaned at the same time. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:148 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:148 neteler]: since `G_ELEMENT_3DVIEW` and `G_ELEMENT_REGION3D` are not used in the code I took liberty to remove them in r63639. But also the code indicated in comment:142 should be cleaned at the same time. sure, done in r63642. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:149 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:144 neteler]: Many more updates related to the new element name changes, I tried to catch all: * still found more, especially in the test scripts. Fixed in r63644 + r63649. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:150 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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): Updated temporal: renamed parameters extrdir/workdir - directory for consistency (as earlier done for other t.* modules) in r63650 + r63651 -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:151 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:135 martinl]: Replying to [comment:134 martinl]: `raster_3d` introduced in r63584. If no objections I will backport modified element names including `raster_3d` to relbr70. done in r63617. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:138 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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): More element name change related updates in r63619 and r63620 (shell scripts) -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:139 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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 hcho): BTW, we don't rename `oldvector` and `asciivector` to `old_vector` and `ascii_vector` for the same reason? They are also two words. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:140 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:140 hcho]: BTW, we don't rename `oldvector` and `asciivector` to `old_vector` and `ascii_vector` for the same reason? They are also two words. make sense to me, done in r63624 and backported to relbr70 as r63625. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:141 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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):
r63624 completed in r63626; r63625 completed in r63627.
BTW, there are still in lib/python/pygrass/gis/__init__.py, line 27:
{{{
'region3d': libgis.G_ELEMENT_REGION3D,
...
'view3d': libgis.G_ELEMENT_3DVIEW}
}}}
and
{{{
./lib/manage/option.c:else if (strcmp(p-key, region) == 0 ||
strcmp(p-key, region3d) == 0)
./gui/wxpython/gui_core/gselect.py:
'windows3d':'region3d',
./gui/wxpython/gui_core/gselect.py:
'region3d':'region3d',
./gui/wxpython/gui_core/gselect.py: 'region3D
definition':'region3d',
./gui/wxpython/gui_core/gselect.py: 'region3D
definition files':'region3d',
}}}
I suppose that view3d can be removed and region3d -- region_3d?
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:142
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:142 neteler]: I suppose that view3d can be removed and region3d -- region_3d? AFAIS we don't need `region3d`? Region settings contains 3D info by default. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:143 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:131 hcho]: * modules with parameters `raster_map=` and `raster_map_2=`: `rast` ambiguous, `rmap` for `raster_map=` and `rmap2` for `raster_map_2=` * modules with parameters `raster_map=` and `raster_map2=`: `rast` ambiguous, `rmap` for `raster_map=` and `rmap2` for `raster_map2=` I'm not sure if I was clear enough here. You're suggesting that the abbreviation must include some part of the last word of the option name? Or that it must include the last character? I.e. is rm= ambiguous? The main problems I foresee with that are * The last word (or an abbreviation of it) might match some earlier portion of the option name, meaning that the user intended to specify (part of) the last word but the characters were matched against an earlier portion. * It's possible for a string to match the last word of multiple options. E.g. given options raster_map and raster_2_map, rmap would match both equally. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:133 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:132 cmbarton]: Replying to [comment:127 mlennert]: +1 for raster_3d. Moritz +1 for me `raster_3d` introduced in r63584. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:134 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:134 martinl]: `raster_3d` introduced in r63584. If no objections I will backport modified element names including `raster_3d` to relbr70. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:135 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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 hcho): Replying to [comment:133 glynn]: Replying to [comment:131 hcho]: * modules with parameters `raster_map=` and `raster_map_2=`: `rast` ambiguous, `rmap` for `raster_map=` and `rmap2` for `raster_map_2=` * modules with parameters `raster_map=` and `raster_map2=`: `rast` ambiguous, `rmap` for `raster_map=` and `rmap2` for `raster_map2=` I'm not sure if I was clear enough here. You're suggesting that the abbreviation must include some part of the last word of the option name? Or that it must include the last character? I.e. is rm= ambiguous? No, not the last word of the option name. You cannot skip any words separated by an underscore. rm= is not ambiguous in this case because the shortest option name that matches rm= is raster_map=. If one wants raster_map2=, use rmap2=, not rm2= (no abbreviation inside a word). The main problems I foresee with that are * The last word (or an abbreviation of it) might match some earlier portion of the option name, meaning that the user intended to specify (part of) the last word but the characters were matched against an earlier portion. I'm not talking about skipping words and using the last word, so this is not the case. * It's possible for a string to match the last word of multiple options. E.g. given options raster_map and raster_2_map, rmap would match both equally. rmap= would match raster_map= only because you cannot skip 2. Hope I'm clearer now. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:136 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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 hcho): Replying to [comment:136 hcho]: Replying to [comment:133 glynn]: Replying to [comment:131 hcho]: * modules with parameters `raster_map=` and `raster_map_2=`: `rast` ambiguous, `rmap` for `raster_map=` and `rmap2` for `raster_map_2=` * modules with parameters `raster_map=` and `raster_map2=`: `rast` ambiguous, `rmap` for `raster_map=` and `rmap2` for `raster_map2=` I'm not sure if I was clear enough here. You're suggesting that the abbreviation must include some part of the last word of the option name? Or that it must include the last character? I.e. is rm= ambiguous? No, not the last word of the option name. You cannot skip any words separated by an underscore. rm= is not ambiguous in this case because the shortest option name that matches rm= is raster_map=. If one wants raster_map2=, use rmap2=, not rm2= (no abbreviation inside a word). I mean the shortest option name with no more following underscores. 'r' for raster, 'm' for map, and no more underscores after 'raster_map'. If you have `raster_map_1=` and `raster_map_2=`, `rm=` would be ambiguous because `raster_map` is still ambiguous. If you have `raster_map=` and `raster_map_2=`, `rm=` expands to `raster_map=` and it's not ambiguous. The main problems I foresee with that are * The last word (or an abbreviation of it) might match some earlier portion of the option name, meaning that the user intended to specify (part of) the last word but the characters were matched against an earlier portion. I'm not talking about skipping words and using the last word, so this is not the case. * It's possible for a string to match the last word of multiple options. E.g. given options raster_map and raster_2_map, rmap would match both equally. rmap= would match raster_map= only because you cannot skip 2. Hope I'm clearer now. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:137 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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): +1 for raster_3d. Moritz -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:127 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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 lucadelu): Replying to [comment:127 mlennert]: +1 for raster_3d. +1 also for me Moritz -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:128 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:127 mlennert]: +1 for raster_3d. +1 I think that it would be useful to modify parser to understand also `rast` (`rast3d is OK because '_' is treated as word separator). -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:129 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:129 martinl]: I think that it would be useful to modify parser to understand also `rast` (`rast3d is OK because '_' is treated as word separator). attachment:raster_3d.diff -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:130 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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 hcho): Replying to [comment:130 martinl]: Replying to [comment:129 martinl]: I think that it would be useful to modify parser to understand also `rast` (`rast3d is OK because '_' is treated as word separator). attachment:raster_3d.diff I'm generally against adding special cases in the code. IMHO, if the user types `rast`, s/he means `raster` not `raster_3d` and it shouldn't be ambiguous. Currently, the parser would stop with a parameter ambiguous error. I think it would be more useful to modify the parser such that it takes the shortest unambiguous parameter with no further underscores. For example, * modules with parameters `raster_map=` and `raster_3d=`: `rast` and `raster_` would be ambiguous. * modules with parameters `raster=` and `raster_3d=`: `r` and `rast` would match with `raster=` and `r3` and `rast3` with `raster_3d=` * modules with parameters `raster_map=` and `raster_map_2=`: `rast` ambiguous, `rmap` for `raster_map=` and `rmap2` for `raster_map_2=` * modules with parameters `raster_map=` and `raster_map2=`: `rast` ambiguous, `rmap` for `raster_map=` and `rmap2` for `raster_map2=` I'm not sure if I was clear enough here. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:131 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:127 mlennert]: +1 for raster_3d. Moritz +1 for me Michael -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:132 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:123 neteler]: To be it looks ok to change the element name rast3d to raster_3d. If I am not wrong it solves all technical problems, too, including abbreviations etc. Opinions? Let's come to a decision, thanks! -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:124 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:124 neteler]: Replying to [comment:123 neteler]: To be it looks ok to change the element name rast3d to raster_3d. If I am not wrong it solves all technical problems, too, including abbreviations etc. Opinions? Let's come to a decision, thanks! I think most devs are OK with the underscore version. Personally, I don't like the underscore, but I don't have any powerful argument, so I will accept it. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:125 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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 hcho): Replying to [comment:125 annakrat]: Replying to [comment:124 neteler]: Replying to [comment:123 neteler]: To be it looks ok to change the element name rast3d to raster_3d. If I am not wrong it solves all technical problems, too, including abbreviations etc. Opinions? Let's come to a decision, thanks! I think most devs are OK with the underscore version. Personally, I don't like the underscore, but I don't have any powerful argument, so I will accept it. Agree. I don't like the underscore version, but I'm OK with raster_3d because it's at least better than 3draster or 3d_raster. Also, we don't have to rename any modules and the parser doesn't have to treat numbers as a special character. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:126 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:121 glynn]: Can someone, anyone, explain what exactly is the problem with underscores? Why are they bad, why shouldn't we use them, etc? To be it looks ok to change the element name rast3d to raster_3d. If I am not wrong it solves all technical problems, too, including abbreviations etc. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:123 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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): I've been dealing with end of semester and traveling. Wow! A lot of words spilled over a small suggestion to simplify parsing in code and in commands. FWIW, the underscore makes it a *little* easier to parse and potentially shorten (if that is desirable) the term for GRASS's unique 3D/voxel format. It also makes it a little easier to quickly differentiate the 2D raster things (raster and raster.x) from the 3D raster things (raster_3D and raster_3D.x). I don't find an underscore that much trouble to type, except on my iPad where I can't run GRASS anyway. That said, it's not a big deal to me either way. Since one is very minimally more difficult to type than the other (1 character), I'd suggest whichever form makes programming easier. Maybe a simple vote is needed to move on. I'm delighted to go along with the majority so we release the next beta -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:120 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:116 wenzeslaus]: [comment:111 annakrat] and [comment:113 hcho] don't want the underscore for 3D raster, so this changes `raster` and (`raster_3d` and `raster3d`) just to `raster` and `raster3d`. [comment:102 I] already said that I prefer `raster3d` over `raster_3d`. In my opinion such a common option name as one for 3D raster (common for me and name of one of the basic types) should not have an underscore. Can someone, anyone, explain what exactly is the problem with underscores? Why are they bad, why shouldn't we use them, etc? To my mind, any name that is made of more than one word should have some kind of separator between the words. For GRASS option names, some kind of separator equates to an underscore. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:121 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:117 mlennert]: More generally, this whole issue shows to me what happens in an unorganised release process where we start to release betas without being sure that we are in a stable enough state to do so and then begin such a fundamental review such as this one very late into the process... It's always the same. If something can be left until later, it is. Once we reach the last chance to comment stage, all of the discussions which should have happened over the last half-dozen years start. This isn't specific to GRASS. The standard that eventually became C++11 spent most of its life being referred to as C++0x on the assumption that it would be published by the end of 2009 at the latest. It's something of a chicken-and-egg problem. You don't get adequate feedback until many people start using it, and many people won't start using it until it's perceived as stable. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:122 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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): Dear devs: I see the problem of no consensus here. Do we need to fork GRASS at this point or postpone the release forever? (irony flag on or off as you wish) -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:115 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:115 neteler]: I see the problem of no consensus here. Do we need to fork GRASS at this point or postpone the release forever? (irony flag on or off as you wish) My understanding was that we have or we are very close to consensus. I the last round, [comment:108 martinl] suggested `raster` and (`raster_3d` or `raster3d`) for options and elements (when leaving module names as they are). [comment:112 mlennert] agrees with not renaming module names (if I understand correctly). [comment:111 annakrat] and [comment:113 hcho] don't want the underscore for 3D raster, so this changes `raster` and (`raster_3d` and `raster3d`) just to `raster` and `raster3d`. [comment:102 I] already said that I prefer `raster3d` over `raster_3d`. In my opinion such a common option name as one for 3D raster (common for me and name of one of the basic types) should not have an underscore. But [comment:114 glynn] does not see the point in not using underscore in case of `raster_3d`. So, this is the only unclear part depending on how strong is Glynn's opinion. [comment:113 hcho] suggests to allow shortening of options also where the numbers are. [comment:114 glynn] says that's possible. I hope I'm not misquoting anybody. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:116 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:116 wenzeslaus]: Replying to [comment:115 neteler]: I see the problem of no consensus here. Do we need to fork GRASS at this point or postpone the release forever? (irony flag on or off as you wish) My understanding was that we have or we are very close to consensus. I the last round, [comment:108 martinl] suggested `raster` and (`raster_3d` or `raster3d`) for options and elements (when leaving module names as they are). [comment:112 mlennert] agrees with not renaming module names (if I understand correctly). [comment:111 annakrat] and [comment:113 hcho] don't want the underscore for 3D raster, so this changes `raster` and (`raster_3d` and `raster3d`) just to `raster` and `raster3d`. [comment:102 I] already said that I prefer `raster3d` over `raster_3d`. In my opinion such a common option name as one for 3D raster (common for me and name of one of the basic types) should not have an underscore. But [comment:114 glynn] does not see the point in not using underscore in case of `raster_3d`. So, this is the only unclear part depending on how strong is Glynn's opinion. Why only Glynn's ? For me that question goes both ways. I have to admit that I don't understand the opposition to raster_3d. Is this only based on aesthetics ? In terms of ease of programming and usability, I have the feeling that raster_3d is superior as it allows you to use the current parser behaviour to use abbreviations like r3 which raster3d doesn't. More generally, this whole issue shows to me what happens in an unorganised release process where we start to release betas without being sure that we are in a stable enough state to do so and then begin such a fundamental review such as this one very late into the process... Moritz -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:117 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:117 mlennert]: Replying to [comment:116 wenzeslaus]: Replying to [comment:115 neteler]: I see the problem of no consensus here. Do we need to fork GRASS at this point or postpone the release forever? (irony flag on or off as you wish) My understanding was that we have or we are very close to consensus. I the last round, [comment:108 martinl] suggested `raster` and (`raster_3d` or `raster3d`) for options and elements (when leaving module names as they are). [comment:112 mlennert] agrees with not renaming module names (if I understand correctly). [comment:111 annakrat] and [comment:113 hcho] don't want the underscore for 3D raster, so this changes `raster` and (`raster_3d` and `raster3d`) just to `raster` and `raster3d`. [comment:102 I] already said that I prefer `raster3d` over `raster_3d`. In my opinion such a common option name as one for 3D raster (common for me and name of one of the basic types) should not have an underscore. But [comment:114 glynn] does not see the point in not using underscore in case of `raster_3d`. So, this is the only unclear part depending on how strong is Glynn's opinion. Why only Glynn's ? For me that question goes both ways. I have to admit that I don't understand the opposition to raster_3d. So, sorry for misquoting you. Is this only based on aesthetics ? In terms of ease of programming and usability, I have the feeling that raster_3d is superior as it allows you to use the current parser behaviour to use abbreviations like r3 which raster3d doesn't. As I said before, I don't care much about abbreviations. I even consider them bad. They are bad for the source code and most of the scripting because of readability (I think we have a consensus on that). And they are bad for manuals and tutorials because they are harder for user to translate to GUI or QGIS (GUI or processing). So then I don't see the point in putting so much effort into the abbreviated options. And I also think that we cannot unabbreviate everything, some options would be just too long, too unpractical. Anyway, I can manage to write `raster_3d` everywhere and I will hope that everybody will do the same for all GRASS core code and addons. Perhaps it would be useful to have some environmental variable to disable abbreviating which could be used for testing (or to speed up the parsing). -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:118 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:117 mlennert]: More generally, this whole issue shows to me what happens in an unorganised release process Not really: Martin, me and some others worked for *years* on the consolidation. Just others didn't care too much until now. Eg I went through the 4000 parameters and flags multiple times. Just join the party :-) where we start to release betas without being sure that we are in a stable enough state to do so and then begin such a fundamental review such as this one very late into the process... Concerning the beta releases: And I am very sure that without the beta releases the widespread testing which actually happens (also is possible thanks to the packagers preparing installers for the various OS'es and distros who need a tangible package) hadn't been done. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:119 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:108 martinl]: Replying to [comment:102 wenzeslaus]: For example, there will be no need to change `grass.script.raster3d` (which would end up as `grass.script._3draster` in the other case). From this point of view `raster_3d` is also not good because underscore should not be in the name of a Python module if possible and moreover I don't like `raster_3d` in general. Shortening possibilities are not as important to me as name without underscore. What about the module names? Are we changing that? Or is `raster3d` just `rast3d` in module names? Personally I would tend to rename just * element name `raster_3d` (or `raster3d`) * module options e.g. `d.legend raster_3d` I would not touch names of the modules, some of them already use shorten names, eg. `d.rast.leg`, so I would keep `rast3d`. Similarly I would not touch python module names. Any opinion from other devs? +1 Moritz -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:112 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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 hcho): Replying to [comment:111 annakrat]: Replying to [comment:108 martinl]: Personally I would tend to rename just * element name `raster_3d` (or `raster3d`) * module options e.g. `d.legend raster_3d` I would not touch names of the modules, some of them already use shorten names, eg. `d.rast.leg`, so I would keep `rast3d`. Similarly I would not touch python module names. Any opinion from other devs? I don't really like the underscore, I would go with raster3d, I think we can manage to type raster3d because 3D rasters are generally not used as often as rasters. I agree. I don't like the underscore either. Maybe, the parser could treat numbers just like the underscore so that we can shorten raster3d as r3. I would keep the names of modules as they are now. Like Martin mentioned, I don't think we need to change module names if we go for raster3d because other modules already use short names. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:113 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:113 hcho]: I don't really like the underscore, I would go with raster3d, I think we can manage to type raster3d because 3D rasters are generally not used as often as rasters. I agree. I don't like the underscore either. Maybe, the parser could treat numbers just like the underscore so that we can shorten raster3d as r3. Having the parser treat numbers as separate words shouldn't be a problem. OTOH, while I can understand why people might not want to use e.g. back_ground (to allow abbreviation as bg), I really don't see the problem with raster_3d. To me, raster and 3d are entirely separate words. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:114 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:104 neteler]: Should we vote on this topic? We really need to converge asap since beta4 is overdue. I fully agree, we need to somehow decide this issue... -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:105 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:102 wenzeslaus]: For example, there will be no need to change `grass.script.raster3d` (which would end up as `grass.script._3draster` in the other case). From this point of view `raster_3d` is also not good because underscore should not be in the name of a Python module if possible and moreover I don't like `raster_3d` in general. Shortening possibilities are not as important to me as name without underscore. I would agree with that. @glynn: please could you review your opinion on already attached patch. I understand that you prefer some generic solution. On the other hand we need to decide somehow (to find a compromise) since we would like to see GRASS7 released in reasonable time. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:106 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:101 glynn]:
So e.g. if a module has raster and raster_3d options, r, rast
and raster would all be deemed to unambiguously refer to raster, while
any abbreviation intended to refer to raster_3d would have to include
the 3 (e.g. r3, r3d, rast3, rast3d, ...) to ensure that it
cannot also match raster.
I have prepared for testing a new patch based on your suggestion
attachment:raster_3d.diff
Then
{{{
g.list rast3d
}}}
will work. The patch contains modification of the parser to understand
`rast`
{{{
g.list rast
WARNING: Please update the usage of g.list: option rast has been
renamed to raster
...
}}}
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:107
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:102 wenzeslaus]: For example, there will be no need to change `grass.script.raster3d` (which would end up as `grass.script._3draster` in the other case). From this point of view `raster_3d` is also not good because underscore should not be in the name of a Python module if possible and moreover I don't like `raster_3d` in general. Shortening possibilities are not as important to me as name without underscore. What about the module names? Are we changing that? Or is `raster3d` just `rast3d` in module names? Personally I would tend to rename just * element name `raster_3d` (or `raster3d`) * module options e.g. `d.legend raster_3d` I would not touch names of the modules, some of them already use shorten names, eg. `d.rast.leg`, so I would keep `rast3d`. Similarly I would not touch python module names. Any opinion from other devs? -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:108 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:106 martinl]: @glynn: please could you review your opinion on already attached patch. I understand that you prefer some generic solution. On the other hand we need to decide somehow (to find a compromise) since we would like to see GRASS7 released in reasonable time. It's preferable to doing nothing (i.e. leaving modules using abbreviated forms), and is compatible with the result obtained by relaxing the ambiguity rules. Should we do something similar for option names? E.g. g.region, g.rename, g.copy have rast= and rast3d= options. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:109 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:109 glynn]: Should we do something similar for option names? E.g. g.region, g.rename, g.copy have rast= and rast3d= options. yes, enough would to register them in source:grass/trunk/lib/gis/renamed_options -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:110 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:108 martinl]: Personally I would tend to rename just * element name `raster_3d` (or `raster3d`) * module options e.g. `d.legend raster_3d` I would not touch names of the modules, some of them already use shorten names, eg. `d.rast.leg`, so I would keep `rast3d`. Similarly I would not touch python module names. Any opinion from other devs? I don't really like the underscore, I would go with raster3d, I think we can manage to type raster3d because 3D rasters are generally not used as often as rasters. I would keep the names of modules as they are now. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:111 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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:102 wenzeslaus]: I like `raster` and `raster3d`. From all noted options I like this one too. What about the module names? Are we changing that? Or is `raster3d` just `rast3d` in module names? No strong opinion here, I would keep current module names. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:103 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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): Should we vote on this topic? We really need to converge asap since beta4 is overdue. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:104 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#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 huhabla): Replying to [comment:96 martinl]: Replying to [comment:95 helena]: -1 for voxel, than we could rename 'raster' to 'pixel' ;-) I am still not sure we need to rename than all modules from `r3` to `vo`... so is there also an agreement to rename all r3.* commands to vo.* commands and changing all manuals accordingly? If yes, this will require several weeks of focused testing and not at all, personally I don't like to stick with shortened element names (rast, rast3d) just because it makes our life easier. Taking in account a real world it seems to me that the reasonable is to rename `rast - raster` and `rast3d - raster3d` and to modify the parser to understand also shortened element names. This would be absolutely my favorite solution. IMHO renaming all 3D raster and STR3DS modules using volume name approach will result in a lot of unnecessary work and inconsistency. As a result all documentation in code and manual pages, the module help, examples and tests must be updated/modified as well. Not speaking about the confusion with wording in already published scientific papers and books ... . I don't think this is worth the effort. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:99 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
