Bug report #10735
SAGA GDAL export fails when format plugins installed
|Affected QGIS version:||2.8.1||Regression?:||No|
|Operating System:||OS X||Easy fix?:||No|
|Pull Request or Patch supplied:||No||Resolution:|
|Crashes QGIS or corrupts data:||No||Copied to github as #:||19120|
When GDAL drivers are installed as plugins (OS X GDAL framework uses plugins for some format drivers), SAGA GDAL export fails. It looks like it's the assumption that SAGA puts Geotiff in position #1. But I have the ECW_JP2ECW driver installed as a plugin for GDAL and SAGA lists ECW and Erdas JPEG2000 before Geotiff. (it appears that only formats with write capability show up here, so my other format plugins, MrSID and GRASS, don't appear in the list)
So, when a Processing SAGA algorithm is run, it fails when exporting the result to GDAL Geotiff because it's really trying to export to whatever happens to be in SAGA's list position #1, Erdas JPEG2000 in my case which needs a license code to enable writing. I've seen another case where only 1 plugin registers, then the #1 position is VRT, which doesn't support writing.
A workaround is to disable GDAL plugins, but that also disables support for directly using those formats everywhere in QGIS and outside QGIS. Maybe GDAL_SKIP could be set in QGIS preferences, but you would still lose access to those formats.
Note: SAGA 2.1
[processing]changed native raster format for SAGA algorithms from tif to sdat
This eliminates the need to export to a QGIS compatible format after generating a raster output. The SDAT format is the native SAGA format, and it is supported by GDAL, so it is also supported by QGIS. This was not used before, but now we use that to reduce the nuber of steps and provide a better integration.
Conversion to other formats is now done by Processing itself, not by the SAGA algorithm.