<div dir="ltr">Hi Markus,<br><div><br>On Mon, Mar 12, 2018 at 3:03 PM, Markus Metz <<a href="mailto:markus.metz.giswork@gmail.com" target="_blank">markus.metz.giswork@gmail.com</a><wbr>> wrote:<br>><br>> On Sun, Mar 11, 2018 at 4:33 AM, Vaclav Petras <<a href="mailto:wenzeslaus@gmail.com" target="_blank">wenzeslaus@gmail.com</a>> wrote:<br>><br>> The example in the wiki is based on a GeoTIFF file with a single raster band. IMHO, the input should be more general in the form "GDAL_raster_datasource raster_band" and "GDAL_vector_datasource layer_name".<br><br>Yes, I agree, the input files in the examples are trivial. Ideally, this
 should also work with things like PostGIS or NetCDF for time series. I 
don't have proposal for the syntax at this point, space from your suggestion, colon, and a separate ...-layer pseudo-option come to my mind.<br><br><div>For vectors we already have a similar case with @OGR mapset where 
we use vector map name for GDAL_vector_datasource and layer for 
layer_name.<br><br>There we hit some terminology differences but that could be mitigated 
by adding something like OGC compliant descriptions which might be 
anyway needed for the better integration with QGIS.<br></div><div><br><a href="https://trac.osgeo.org/grass/wiki/GSoC/2018#ImproveGRASSintegrationinQGIS3">https://trac.osgeo.org/grass/wiki/GSoC/2018#ImproveGRASSintegrationinQGIS3</a></div><br>> Specifying a raster band/layer name should probably be mandatory.<br><br>I'm not sure if it 
should be mandatory or not. I think @OGR requires the layer, but if user provides a single band GeoTIFF or a Shapefile, it seems as
 expected behavior that the only band/layer is picked 
automatically.<br><br>> The new parser would then use GDAL to test if the given datasource is valid and if the given raster band/vector layer exists in this datasource.<br></div><div><br></div><div>These and other tests will be big part of the backend: "The system behind the interface will be inherently fragile, so it is 
necessary to write large amount of tests which would check different 
combinations of data types and projections."<br><br>> I guess the main part of this project would be to write a parser for the `grass run` arguments that translates them to an actual GRASS command.<br><br></div><div>Yes, there are two types of arguments, those related to `grass run` like `--mask` and then those which are part of module interface like `input` which translate to some import commands and also the module option.<br><br></div><div>In case somebody wonders, yes, `--mask` could be a general option for all the module, in fact `--region` was already discussed (r.relief input=... --v --r="n=5520 s=4000..."). Further, `input` could be written like `--input` to follow POSIX and finally, even to modules themselves could accept the general files (like with @OGR), rather than going through `run`. But any of these are outside of scope for this GSoC and it is probably a good idea to leave them for the next iteration. Same goes for the full subcommand interface idea and Grassfile (directory rc file) idea mentioned in the comment 15 of #2579.<br></div><div><br><a href="https://trac.osgeo.org/grass/ticket/2579#comment:15">https://trac.osgeo.org/grass/ticket/2579#comment:15</a><br><br>> > Mentors: I'm seeking an additional mentor for this idea. I put myself as first, but you can be first or second mentor as you wish.<br>><br>> I would be interested in the general design and concept for the implementation of this project.<br><br></div><div>Great, this will be very helpful.<br></div><div><br>> A very interesting idea that would facilitate the use of GRASS as a toolbox similar to GDAL or (ambitious reference) OTB.<br><br></div><div>Thanks and thanks for the feedback too!<br></div><div><br></div><div>Vaclav<br></div></div>