QGIS » QGIS Application

Tried a few more tools, I always get:

Error: select a tool

Chengelog is here:

http://sourceforge.net/p/saga-gis/wiki/Changelog%202.2.0/

Here one can find the diff in interfaces:

SAGA 2.2.0

https://sourceforge.net/p/saga-gis/wiki/Changelog%202.2.0/attachment/saga_cmd_interface_v2_2_0.txt

SAGA 2.1.4

https://sourceforge.net/p/saga-gis/wiki/Changelog%202.1.4/attachment/saga_cmd_interface_v2_1_4.txt

So one can simply do a diff between both files to see the changes. This also works with files created for older SAGA versions, e.g. in case you have skipped SAGA 2.1.4.

Thanks Volker for pointing it out.

So one can simply do a diff between both files to see the changes.

there are a few changes that will need to be addressed, but the above module (ta_morphometry "Slope, Aspect, Curvature") is identical in 2.1.4 and 2.2.0. As you get the same error for many other modules and as it generally seems to work (tested just on Windows for now, but haven't found yet a 2.2 module that does not work with the 2.1.4 descriptions) it seems anyway that you may have a local issue.

Agreed, thanks for pointing this out.
My system is all from standard packages, a local issue is unlikely, or anyway unexpected.
Does anyone have the same?

The options:

`io_gdal -TRANSFORM `

should be replaced by:

`io_gdal 0 -TRANSFORM 1`

so the import does not fail.
Thanks Giovanni for spotting this.

Basic problem fixed with 72665e0. More comprehensive solution needed.

If this patch fixes the problem and 2.2.0 works fine, i think this can be closed, considering that we have 2.2.0 now as a supported version in the code

Works well here, I leave it open for further feedback.

I applied this patch on my 2.8.1 QGIS installation on Linux Mint, using SAGA 2.2.0. It solved the problem for me. (Thank you Paolo!)

Thank Victor for this.
Unfortunately now (saga 2.2.1) I can see only one (!) saga alg. From the log:

...
2015-09-30T21:19:25 2 Could not open SAGA algorithm:
/usr/share/qgis/python/plugins/processing/algs/saga/description/2.1.4/FragmentationClassesfromDensityandConnectivity.txt
'2.2.1'
2015-09-30T21:19:25 2 Could not open SAGA algorithm:
/usr/share/qgis/python/plugins/processing/algs/saga/description/2.1.4/FlatDetection.txt
'2.2.1'

Steps to reproduce also for other versions:

wget http://sourceforge.net/p/saga-gis/wiki/Changelog%202.2.2/attachment/saga_cmd_interface_v2_2_2.txt

wget http://sourceforge.net/p/saga-gis/wiki/Changelog%202.2.0/attachment/saga_cmd_interface_v2_2_0.txt

diff saga_cmd_interface_v2_2_2.txt saga_cmd_interface_v2_2_0.txt > saga_diff_2_2_0_vs_2_2_2.txt

No, thanks to the SAGA devs. In SAGA 2.2.3 there are some commands with changed parameters, see #14300

I still find modules description for 2.2.0 (and by consequence on 2.2.2 and 2.2.3) that are wrong (just made a pull request for "resampling") because they were not changed when the files were copied from 2.1.*

Is there a way we can check what is the actual status in master?

Thanks a lot Giovanni for this work!
In the meantime, saga 2.2.4 is out, so probably there will be more to fix.

Paolo Cavallini wrote:

In the meantime, saga 2.2.4 is out, so probably there will be more to fix.

this is getting ridiculous, we should really stick to one SAGA version and eventually update only for LTR releases.

Meanwhile I would really appreciate if someone is able to easily check what

• modules we still miss to add in 2.2.0 and 2.2.2 (and now 2.2.4). Yesterday I realized we were missing 5 tools from the shapes_polygons group. I already added the new ones in 2.2.3.

• modules in 2.2.* that we still need to update (since we copied the description files from 2.1.*, and is not unusual still to find broken tools, see the above comment about "resampling").

Agreed, it's really a PITA. Unfortunately, the upgrade cycle for Linux distros at least is outside our control.

Paolo Cavallini wrote:

Agreed, it's really a PITA. Unfortunately, the upgrade cycle for Linux distros at least is outside our control.

Honestly as a Linux user I don't care about this specific problem. For example Linux users have virtually disappeared from trainings, and I would prefer much more to be able to rely 100% on a specific version of SAGA on Windows (that is what the vast majority of users use). Linux users can always be instructed on how to get/compile a specific version of SAGA.

This would be discriminatory, and obviously against our policy.
One possible solution would be to embed a specific saga version, to be merged from upstream when appropriate.
The whole issue should be discussed in the ML or as a QEP however.

Paolo Cavallini wrote:

This would be discriminatory, and obviously against our policy.

it would be a practical decision, not a discriminatory one.
Because otherwise among ~240 (and growing) tools we will have always a good chunk broken, and shipping at each release broken tools is admittedly very bad for the users and qgis image.

If the project want to task me to keep the descriptions files up to date at each saga release I'm available.

One possible solution would be to embed a specific saga version, to be merged from upstream when appropriate.

this would work for me.

If SAGA devs don't care about their users its their problem, not ours. Maybe users will move to another tools, e.g. GRASS and OTB which are much more stable and SAGA will die in neareast future :-).

I think that we should not add support for new SAGA versions without real need. Our priority should be average users, not early adopters. Maybe I'm wrong, but new SAGA version appears in repositories, espesially stable repositories, with delay, not in the same day as it was released. So there is no harm in providing support only for version from stable repositories. We already do this with lot of dependencies, e.g. minimum supported Qt version is 4.8.0 not latest 4.8.6 and so on. Why not use same approach with SAGA? Declare support for version, available for example in Debian Stable (or another repo, we use as minimal supported version), and make sure it works. All other versions may be supported but without any warranty.

Also Victor and me discussed SAGA support recently. Maybe we can implement something like "real-time" description generation for SAGA algs using its Python API. But this will work only for some algs, because many single SAGA algs should be splitted into two or more Processing algs and also there are some differences in parameters handling (e.g. extent passed to SAGA differently). So such automated generator is not a "silver bullet", a lot of manual work will be needed. So not much difference with current situation.

I think that we should not add support for new SAGA versions without real need. Our priority should be average users, not early adopters. Maybe I'm wrong, but new SAGA version appears in repositories, especially stable repositories, with delay, not in the same day as it was released. So there is no harm in providing support only for version from stable repositories.

agree

Can we close this ticket?

IMHO making SAGA usable for all is still an open issue, although the solution may not be a simple one.
Please keep it open until we have a proper solution.

Paolo Cavallini wrote:

IMHO making SAGA usable for all is still an open issue, although the solution may not be a simple one.
Please keep it open until we have a proper solution.

what this has to do with the description/subject of this ticket?

According to https://sourceforge.net/p/saga-gis/mailman/message/35146184/ SAGA 2.3 will support reading data via GDAL.