#3632: Add a function to read parameters from a file to the parser -------------------------+------------------------------------------------- Reporter: wenzeslaus | Owner: grass-dev@… Type: | Status: new enhancement | Priority: normal | Milestone: 8.0.0 Component: Parser | Version: unspecified Resolution: | Keywords: g.parser options parameters file CPU: | long CLI Unspecified | Platform: Unspecified -------------------------+-------------------------------------------------
Comment (by wenzeslaus): Replying to [comment:2 mmetz]: > > Using the example > {{{ > r.slope.aspect elevation=dtm slope=dtm_slope aspect=dtm_aspect -n > }}} > what is the advantage of the proposed approach over a file that contains exactly this line and executing this file? This is already working and handled by the OS. I'm thinking about these three points: 1) There is no command line length limitation as the line or lines are processed directly by the parser. When I have a long r.series input: {{{ > r.series in=map1900,map1901,...,map2100 out=slope meth=slope }}} I need to switch to `file` instead of `input`. {{{ > cat input.txt map1900 map1901 ... map2100 > r.series file=input.txt out=slope meth=slope }}} That of course assumes that `file` was implemented. In case of having the parameter file, I need to switch to that while still using `input`. {{{ > cat params.txt in=map1900,map1901,...,map2100 out=slope meth=slope > r.series --parameter-file=params.txt }}} 2) The scripting is replaced with configuration. This "command line scripting" is OS-depended. You want a short line, but backslashes won't work in GUI Console (and on MS Win?). Escaping is done in different ways. In other words, the format is actually not well defined, so unless you already know "command line scripting" on your OS, this will be cumbersome. Another syntax related thing are comments which again could have a clearly defined syntax (`#` in Bash versus `REM` in CMD). So the following ways of storing the parameters as a command with indentation and backslash which will work well in unix-like command line but not necessarily elsewhere (which is something we need to explain to the user), {{{ r.series input=map2001,map2002,dummy,dummy,map2005,map2006,dummy,map2008 \ output=res_slope,res_offset,res_coeff method=slope,offset,detcoeff }}} would become, e.g., the following YAML file: {{{ input: - map2001 - map2002 - dummy - dummy - map2005 - map2006 - dummy - map2008 output: - res_slope - res_offset - res_coeff method: - slope - offset - detcoeff }}} Here the advantage is for modules which are implementing some model/simulation which usually have a lot of parameters, e.g. G7:r.sim.water (which has over 20 parameters) or G7:r.topmodel (which actually requires a "parameters file"). 3) This untangles the module from its parameters (splits the "command" into module name and parameters). This brings additional questions such as: Should we extend the format by adding module name or multiple modules and than read that using the `grass` command creating effectively a new API (similarly to e.g. PDAL JSON pipelines)? However, what I'm thinking about now is the advantage of storing the parameters separately from the command itself and than reusing them repetitively (in an interactive command line or a script) while being able to override or complete the parameters when needed. You can do the same with enough of Python, but this would be native. -- Ticket URL: <https://trac.osgeo.org/grass/ticket/3632#comment:3> GRASS GIS <https://grass.osgeo.org>
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev