| | 290 | |
| | 291 | === New easy-to-use command line interface for GRASS GIS === |
| | 292 | |
| | 293 | * GRASS GIS requires GRASS GIS Database, Location and Mapset to be set up to maintain data consistency, efficiency and security. Unfortunately, this is cumbersome when GRASS GIS is not the primary tools one is using. 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. |
| | 294 | * GRASS GIS itself can make it easier for the callers (at least in most cases) by implementing an interface which would allow to use GRASS GIS modules without explicit dealing with GRASS GIS database. |
| | 295 | * The command line call using the proposed interface would look like this: |
| | 296 | |
| | 297 | {{{ |
| | 298 | grass run r.slope.aspect elevation=file://.../elevation.tiff aspect=file://...aspect.tiff |
| | 299 | grass run r.lake elevation=some/file.tiff water_level=10 lake=some/new/file.tiff coordinates=100,520 |
| | 300 | }}} |
| | 301 | |
| | 302 | * The `grass` command would have to parse the command line, find the files which should be maps (either using `file://` or perhaps anything would work) and import/export/link them, and then call the actual command. |
| | 303 | * The input maps could be linked (external) rather than imported (except for the cases when projection differs) which should be faster than import. |
| | 304 | * The output maps could be be also linked (external) with projection same as input which is should be faster then export. |
| | 305 | * Ideally this should work also with PostGIS and databases provided through GDAL/OGR. |
| | 306 | * The GRASS GIS Database, Location and Mapset should be created on the fly and deleted afterwards (the `.grassrc` wouldn't be used). |
| | 307 | * This project should also contain a [https://github.com/qgis/QGIS QGIS] Processing part. |
| | 308 | * Since QGIS Processing is one of the reasons for this interface, implementing is a crucial use case which should be tested from the very beginning a with QGIS Processing implementation, the interface would be used right away. |
| | 309 | * Alternatively, another project or more than one project can be in this part. |
| | 310 | * Title should change according to decisions made about this part. |
| | 311 | * Proposal should discuss how advanced things such raster algebra, multi-map inputs and outputs, temporal framework, cartography and visualization tools will work. |
| | 312 | * 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. |
| | 313 | * Bonus task would be to find/implement a way to run Python code easily in case `grass` is called from Python (`grass python -c "print('...')"` is a good start). |
| | 314 | * It is expected that this would work for any `g.gui.*` modules too but implementing similar mechanism also for module dialogs is out of scope of this project (although some basic implementation might be quite straightforward). |
| | 315 | * Language requirements: Python (both GRASS GIS startup scripts and QGIS Processing are in Python) |
| | 316 | * See also: |
| | 317 | * #2579 Specify command to be executed as parameter of grass command (patch) and other suggestion for CLI |
| | 318 | * [http://lists.osgeo.org/pipermail/grass-dev/2015-January/072979.html grass-dev QGIS Processing & GRASS (January 2015)] |
| | 319 | * #2424 PyGRASS does not work when GRASS is invoked from outside because it is not possible to change path to dynamic libraries in running process |
| | 320 | * [http://grasswiki.osgeo.org/wiki/Working_with_GRASS_without_starting_it_explicitly Working with GRASS without starting it explicitly] |
| | 321 | * wiki:Grass7/VectorLib/OGRInterface |
| | 322 | * wiki:Grass7/VectorLib/PostGISInterface |
| | 323 | * [https://github.com/qgis/QGIS/blob/0a1382a0be36d408aebd227fb0066f68c513e41e/python/plugins/processing/algs/grass7/Grass7Algorithm.py QGIS Processing Grass7Algorithm.py] source code |
| | 324 | * [https://github.com/moovida/jgrasstools/blob/530c87f26d220f3eeff9d2fb9d21abd8821c00c3/grass/src/main/java/org/jgrasstools/grass/utils/ModuleSupporter.java uDig's JGrasstools] source code |
| | 325 | * [http://sextante.googlecode.com/svn/trunk/soft/sextante_lib/sextante_gui/src/es/unex/sextante/gui/grass/ SEXTANTE grass] source code |
| | 326 | * [https://github.com/geopython/PyWPS/blob/425f0eb160f60714a6705a24ba926e03690ab371/pywps/Grass.py PyWPS source code] and [http://pywps.wald.intevation.org/documentation/process.html PyWPS documentation] |
| | 327 | * [https://code.google.com/p/wps-grass-bridge/source/browse/trunk/?r=97 wps-grass-bridge] source code |
| | 328 | * Related discussions on mailing list: |
| | 329 | * [http://lists.osgeo.org/pipermail/grass-dev/2015-February/073867.html On GSoC Proposal New easy-to-use...] |
| | 330 | * [http://lists.osgeo.org/pipermail/grass-dev/2015-March/074433.html GSOC project proposal] |
| | 331 | * Mentor for the GRASS GIS part: Vaclav Petras |
| | 332 | * Mentor for the QGIS part: ? |
| | 333 | * Mentor for the <insert other OSGeo project> part: ? |
| | 334 | * Co-mentors (e.g. PostGIS connection part): ? |
