[GRASS-dev] Adding an expert mode to the parser

[Blumentrath, Stefan]

Hi,

I have been struggling with similar issues and solved them by writing a GRASS_BATCH_JOB script that I execute in parallel in different mapsets.
Thus, the approach Markus and Sören sketch looks very useful to me (even for people who are not on HPC).

Do you have more options / flags in mind than the region settings? Just asking to get a better idea about the amount of how module complexity may increase with the changes you plan?

If it is only region settings per module-call that should not be overwhelming for users. E.g., the QGIS-GRASS plugin (and I guess Processing too) has a button for «use region of this map» for every command with raster input, which is pointing in this direction (though not as sophisticated as your solution). And QGIS aimed at simplifying the interaction with GRASS analysis ;-).

In order to not blowing up the manual too much, one might write a compact standard description that points to g.region or a central, more detailed description of the new options, which will be the same for every module that uses them, would not they?

After you explained a bit more what you are after I do not really see a problem with this. In fact I am very positive!
But I have to admit that I did not understand the difference between --raster-region and --vector-region. Are you planning to implement some vector-tiles solution?

Cheers
Stefan

From: grass-dev [mailto:grass-dev-bounces at lists.osgeo.org] On Behalf Of Vaclav Petras
Sent: 26. september 2016 04:28
To: Markus Neteler <neteler at osgeo.org>
Cc: GRASS developers list <grass-dev at lists.osgeo.org>; Markus Metz <markus.metz.giswork at gmail.com>
Subject: Re: [GRASS-dev] Adding an expert mode to the parser


On Sun, Sep 25, 2016 at 3:49 PM, Markus Neteler <neteler at osgeo.org<mailto:neteler at osgeo.org>> wrote:
when doing each job in its own mapset and reintegrate it in a single
target mapset as if able to process then in parallel in one mapset by
simply specifying the respective region to the command of interest.
Yes, different from the current paradigm and not for G7.

I think, we can accommodate this behavior in G7. In fact, each command can run with a separate region even now. It can set it on its own, take it from GRASS_REGION or WIND_OVERRIDE. But if you are talking about automatic patching, that's of course different.


But my original comment was targeted at the increasing number of
module parameters and how to handle that (with some new HPC related
idea as an example).

I think we need to talk about specific use cases and decide based on that. For some, Advanced or HPC tab might be enough. Some others might be better addressed by a specific global options like what Soeren just suggested (in the style of --overwrite).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20160926/a1119100/attachment-0001.html>