Changes between Version 43 and Version 44 of GSoC/2018

Timestamp:

Mar 10, 2018, 3:12:52 PM (6 years ago)

Author:

wenzeslaus

Comment:

typos and clarifications

GSoC/2018

@@ -298 +298 @@
   * Reasonable defaults for things like region.
   * CLI and API still allows user to specify any of the above.
- * 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.
+ * 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 tool user is using.
  * There are different ways for calling GRASS modules without starting iterative GRASS session:
   * Modules executed with the `--exec` interface (see [https://grass.osgeo.org/grass74/manuals/grass7.html#batch-jobs-with-the-exec-interface the grass7 manual page] >=7.2)
@@ -305 +305 @@
   * Use the standalone `grass_session` package (new)
   * Set up environmental variables and "RC file" yourself (the classic method).
- * 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'' (in Bash, Python, R), QGIS Processing, gvSIG/SEXTANTE, uDig/JGrassTools, and all the web/server/cloud tools and applications which use GRASS GIS as a processing backend (e.g. PyWPS server).
+ * None of these allows the user to skip the database setup phase. This leads to the need for constant reimplementing of setup, import and export steps in various software and environments including ''user scripts'' (in Bash, Python, R), QGIS Processing, gvSIG/SEXTANTE, uDig/JGrassTools, and all the web/server/cloud tools and applications which use GRASS GIS as a processing backend (e.g. PyWPS server).
  * 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.
  * The command line call using the proposed interface would look like these:
@@ -315 +315 @@
 }}}
 
- * 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.
+ * The `grass` command would have to parse the command line, compare it with the module XML interface description, find the files which should be maps (either using `file://` and ideally anything else), potentially uncompress, and import/export/link them, and then call the actual command (GRASS module).
   * The input maps could be linked (external) rather than imported (except for the cases when projection differs) which should be faster than import.
   * Doing the work in GRASS rather than in the other software would allow GRASS to make the decision about the details, for example the data exchange (r.external vs r.import vs r.in.gdal - see [https://github.com/qgis/QGIS/pull/5426#issuecomment-345067457 comment from MarkusN for QGIS Processing issue] or [https://lists.osgeo.org/pipermail/grass-dev/2017-November/086598.html mailing list]).
- * GRASS Database would be created with an appropriate Location (projection based on input or additional CLI input).
+ * GRASS Database would be created with an appropriate Location (projection based on input files or additional CLI input).
   * The GRASS GIS Database, Location and Mapset should be created on the fly and deleted afterwards (the `.grassrc` wouldn't be used).
  * Computational region would be set based on input file(s) or additional CLI input.
  * The output maps could be be also linked (e.g. r.external.out) with projection same as input which is should be faster then export.
   * Ideally this should work also with PostGIS and databases provided through GDAL/OGR.
- * Proposal should discuss and address how advanced things such raster algebra, multi-map inputs and outputs, temporal framework, cartography and visualization tools will work.
+ * Proposal should discuss and address how advanced things such raster algebra, multi-map inputs and outputs, temporal framework, cartography and visualization tools will work (or what are the limits).
  * Use should be able to always specify the details manually:
 
@@ -330 +330 @@
 grass run --region="s=55600 n=60500..." --mask=some/mask.tiff r.lake elevation=some/file.tiff ...
 grass run --crs=EPSG:3358 --mask=some/mask.tiff r.lake elevation=some/file.tiff ...
+grass run --use=some/file_a.tiff --get=some/file_b.tiff r.slope.aspect elevation=file_a aspect=file_b
 }}}
 
@@ -364 +365 @@
    * Similar complex command line interfaces to learn from: !GeoGig, !ImageMagic (compare new and old CLI), Git, Docker
  * Test and training tasks:
-  * Tests and extent `--exec` functionality:
+  * Tests and extend `--exec` functionality:
    * Add `--tmp-location` which runs `--exec` in a database/location/mapset which are created at the beginning and deleted at the end.
    * Add `-c XY` and `-c LL` for simple unprojected and latitude-longitude Locations (compare options in the current CLI to wxGUI Location Wizard).
    * Add `--clean` (current default) and `--no-clean` which say if `--exec` should clean the `.tmp` directory in the Mapset (for parallel execution).
    * Add `--lock` (current default) and `--no-lock` which say if `--exec` should lock the Mapset (for parallel execution).
-   * Add `--region` to set a temporary computational region for the execution.
+   * Add `--region` to set a temporary computational region for the execution, e.g. `--region="raster=raster_name"`
    * Add `--import-raster=some/file.tiff` which imports (r.in.gdal or r.import) a raster file (same for vector).
    * Add `--link-raster=some/file.tiff` which links (r.external) a raster file (same for vector).