Feature request #5728
Avoid import-export of rasters and vector when possible
|Pull Request or Patch supplied:||No||Resolution:|
|Easy fix?:||No||Copied to github as #:||15242|
Make piping of commands using the same backend avoid the import-export. This would greatly improve speed, make scripts simpler, and avoid loosing information. Thanks Radim Blazek for the suggestion.
#1 Updated by Victor Olaya almost 11 years ago
- Status changed from Open to Feedback
Great suggestion...but I do not see how to implement it. Making SEXTANTE behaves differently if the algorithm is part of a model completely breaks the phylosophy of SEXTANTE, since the semantics of the algorithm would change depending on how it is called (even in the modeler, it could behave as a normal one if the GRASS algorithm produces a final result and not an intermediate one...)
Any ideas? I do not see an easy solution for this...although it would be good to have it.
#2 Updated by Radim Blazek almost 11 years ago
I don't know SEXTANTE internals. My idea was, that each algorithm/module would offer list of supported input and output formats with preference weight. All GRASS raster modules, for example, would offer 'GRASS native' with high preference and all GDAL formats with lower preference. SEXTANTE or maybe the modules (?) would choose the best offered output format from previous module in pipe. Two consecutive GRASS commands would use GRASS native, for example.
#3 Updated by Radim Blazek almost 11 years ago
I have looked briefly into SEXTANTE Programming Guide 1.0 and to the plugin 1.0.5 code. The guide states that GeoAlgorithm reads/writes data via classes which extend AbstractRasterLayer/AbstractVectorLayer (implementing IRasterLayer and IVectorLayer). The GrassAlgorithm however seems to take tif/shp file names as input instead. What is really the input/output interface of a GeoAlgorithm?
#4 Updated by Victor Olaya almost 11 years ago
That is how the Java version works. SEXTANTE for QGIS is different from that. SEXTANTE for QGIS uses a different approach and cannot be run in different GIS, just in QGIS. Its architecture makes it easier to reuse external apps, such as GRASS. Basically, all layer passing is done through filenames. In case the algorithm is an external one, it will open the given file itself (The GRASS algorithm first import the layer into GRASS, then lets GRASS do the processing and then exports the result to a format that QGIS can read). If it is an algorithm directly coded in Python into QGIS, it will use the layer from the QGIS list of layers, finding the one corresponding to that filename.
#5 Updated by Giovanni Manghi over 8 years ago
- Project changed from 78 to QGIS Application
- Category deleted (
#6 Updated by Giovanni Manghi over 8 years ago
- Category set to Processing/Core
#7 Updated by Giovanni Manghi about 6 years ago
- Easy fix? set to No
#8 Updated by Paolo Cavallini over 5 years ago
- Assignee deleted (
Still true in QGIS 3, still looks important to me, as it would be a huge time saver in case of chained GRASS modules.