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

[Moritz Lennert]

Hi to all,

I like the proposal and the discussion.

Would it be a good idea to schedule a virtual meeting during the code sprint next week ?

Moritz

Am 13. März 2018 02:16:09 MEZ schrieb Vaclav Petras <wenzeslaus at gmail.com>:
>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