On Mon, 4 Mar 2019 at 21:59, Pedro Venâncio <[email protected]> wrote:
>
> Hi Nyall,
>
> I think this rises another problem, that is the use of a very old version of 
> SAGA (2.3.2) in QGIS.
>
> I've just tested Difference algorithm with Lene dataset in native SAGA 2.3.2 
> and 7.2.0, and 2.3.2 gives the problem described, but 7.2.0 gives the correct 
> result:
>
> https://cld.pt/dl/download/2dfb0db5-eb74-4396-ad18-7451fd1fe788/test_saga_232.jpg
>
> https://cld.pt/dl/download/92182907-d37a-4441-891c-3c85064b3100/test_saga_720.jpg

This is really frustrating -- I wonder if someone with links to the
SAGA project could approach them again and gently ask them to consider
a new LTR release? Unfortunately until they do make a new LTR, users
on our Windows installation and through the larger linux distros are
stuck with the 2.3 release. I don't believe either the windows nor
debian/ubuntu/fedora packaging team have any intention of moving to
non-ltr releases.

>
> So, we are faced again with the question of keep an old version of SAGA in 
> QGIS core, or make it as an external plugin, with someone keeping an eye in 
> the changes introduced by SAGA team between versions (as we saw in the past).
>
> Alexander Bruy had made an effort to keep a parallel SAGA plugin that support 
> newer SAGA versions: https://plugins.bruy.me/processing-saga.html
> But it is not in the official repository. Maybe this is the time to discuss 
> again the use of SAGA as an external plugin?

So -- my new proposal would be:

1. Leave the inbuilt support at LTR only. Deprecate all known broken
algorithms to avoid user error and frustration.
2. Copy the saga provider to a NEW "saga-next gen" plugin based
provider, which targets the current SAGA v7 .2 release ONLY. This
would be a community-maintained plugin (although, as a once off
goodwill gesture I'm willing to do the initial plugin setup and host
it on a North Road github repo). This plugin could be installed
alongside the inbuilt SAGA LTR provider without issue, but it would
NOT be included in a default QGIS install and users would have to
manually install it via the plugin installer.

I think this approach is the best solution when could get given the
constraints we are working around.

Nyall
_______________________________________________
QGIS-Developer mailing list
[email protected]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Reply via email to