[GRASS-dev] On GSoC Proposal "New easy-to-use command line interface for GRASS GIS"
mlennert at club.worldonline.be
Wed Feb 11 00:20:37 PST 2015
I don't want to mess with the wiki page, so I'm sending my remarks here.
If you (and others) think that this kind of discussion should go
directly onto the page then I can do that.
I've looked at your proposal for GSoC and I think I understand the
reasons for it. However, I do have a few remarks:
- "The GRASS GIS Database, Location and Mapset should be created on the
fly and deleted afterwards (the .grassrc wouldn't be used)."
How is this different from what QGIS Processing already does now ?
- "There are different workarounds for calling GRASS modules without
starting GRASS explicitly, or running GRASS in a batch mode. However,
none of these allows one to skip the database setup phase. This leads to
the need for constant reimplementing of setup, import and export steps
in various environments including user scripts (Bash, Python, R), QGIS
Processing, gvSIG/SEXTANTE, uDig/JGrassTools and all the
web/server/cloud tools which use GRASS GIS as a processing backend."
Idem: if you create GISDBASE, etc on the fly, what is it you are
proposing to change through this project ?
- "The input maps could be linked (external) rather than imported
(except for the cases when projection differs) which should be faster
Please don't forget issues of topology that can arise when you use
v.external. E.g. compare the result of
v.overlay ain=boundary_municp atyp=area bin=zipcodes_wake btype=area
using both imported and externally linked maps...
In general, IIUC, what you are looking for is actually a form of special
- creates a location based on the input data (question: how to handle
input data that is not in the same projection ?)
- links (or imports) the data into that location
- executes the command and saves the output via r/v.external.out
This seems like a very short project to put in place.
Or is there something I'm missing ?
More information about the grass-dev