Hi Markus,
On Mon, Mar 12, 2018 at 3:03 PM, Markus Metz <markus.metz.giswork@gmail.com> wrote:
On Sun, Mar 11, 2018 at 4:33 AM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
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”.
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.
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.
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.
https://trac.osgeo.org/grass/wiki/GSoC/2018#ImproveGRASSintegrationinQGIS3
Specifying a raster band/layer name should probably be mandatory.
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.
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.
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.”
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.
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.
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.
https://trac.osgeo.org/grass/ticket/2579#comment:15
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.
I would be interested in the general design and concept for the implementation of this project.
Great, this will be very helpful.
A very interesting idea that would facilitate the use of GRASS as a toolbox similar to GDAL or (ambitious reference) OTB.
Thanks and thanks for the feedback too!
Vaclav