| 317 | | * 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). |
| 318 | | * The input maps could be linked (external) rather than imported (except for the cases when projection differs) which should be faster than import. |
| 319 | | * 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]). |
| 320 | | * GRASS Database would be created with an appropriate Location (projection based on input files or additional CLI input). |
| 321 | | * The GRASS GIS Database, Location and Mapset should be created on the fly and deleted afterwards (the `.grassrc` wouldn't be used). |
| 322 | | * Computational region would be set based on input file(s) or additional CLI input. |
| 323 | | * 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. |
| 324 | | * Ideally this should work also with PostGIS and databases provided through GDAL/OGR. |
| | 317 | * Basic execution phases: |
| | 318 | * 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 download and uncompress, and import (or link) them, and then call the actual command (GRASS module). |
| | 319 | * The input maps could be linked (external) rather than imported (except for the cases when projection differs) which should be faster than import. |
| | 320 | * 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]). |
| | 321 | * GRASS Database would be created with an appropriate Location (projection based on input files or additional CLI input). |
| | 322 | * The GRASS GIS Database, Location and Mapset should be created on the fly and deleted afterwards (the `.grassrc` wouldn't be used). |
| | 323 | * Computational region would be set based on input file(s) or additional CLI input. |
| | 324 | * Module execution. |
| | 325 | * 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. |
| | 326 | * Ideally export (as well as import) should work also with PostGIS and databases provided through GDAL/OGR. |
