[GRASS-dev] New CLI GSoC Idea: Comments, Mentors, Students Needed

[Vaclav Petras]

Hi Markus,

On Mon, Mar 12, 2018 at 3:03 PM, Markus Metz <markus.metz.giswork at gmail.com>
wrote:
>
> On Sun, Mar 11, 2018 at 4:33 AM, Vaclav Petras <wenzeslaus at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20180312/b1db6d18/attachment-0001.html>