[Qgis-developer] SAGA Interface

[Camilo Polymeris]

>> What I don't understand is: we'd have the same problems using python.
>> There are, as far as I know, no Python-saga packages.
>> Debian's libsaga[2], for instance, does *not* include python bindings.
>> That means we'd have to compile & ship the python-saga binding
>> ourselves, anyway. Or am I missing something?
>
> This should be solved from the saga side, providing a package for it.

That could be an option, yes. But they haven't done it, and I don't
know if they would be interested. One of us could step up and offer
packaging to SAGA, but I am not that experienced in packaging issues
and distro-related complications.
The saga wiki suggest using saga_cmd through python, which would need
no recompilation, but would limit us to non-interactive plugins. Maybe
that isn't so much of an issue, and would be easier.

> Let me try to explain:
> First case: C++ plugin; this requires recompilation of QGIS, so we have
> two options:
> - include the plugin in qgis-trunk, and add the dependency on saga; this
> is unlikely to be accepted by most core qgis-devs, I guess

What about including it in trunk, but only load the plugin if the
dependencies are satisfied?
Would the devs be ok with that? Provided the quality of the plugin is
acceptable, of course.
I also wouldn't require a *full* saga installation, if I am not
mistaken. Only libsaga.

> - leave the plugin outside qgis, and require the recompilation for each
> and every platform, and for each release of qgis; furthermore, osgeo4w
> users will not be able to use it with qgis-dev.
>
> Second case: Python plugin. The user will be able to install it or not,
> provided he has saga with its py bindings installed on its system. This
> will work with all versions of qgis (>=minimum version, as defined in
> the plugin), on all OS.
>

There is a third case: Using saga_cmd through python.
This is the easiest in term of programming effort, I think. But is
limited to non-interactive plugins, as I said before, and but would
require a full saga installation.

> Speed shouldn't be a problem, as the plugin istelf should do very little
> calculations, only calling saga commands with the appropriate
> parameters, as it happens with the GRASS and the GdalTools plugins.

I agree speed isn't a problem.

> Am I wrong?

You are right, and bring up some interesting arguments. You are
starting to convince me. :)

Maybe I could even start with saga_cmd only (option 3) and later add
support for interactive modules using the python api (if available),
option 2.
What do you think of that?
Less elegant than a C++ solution, but much easier.

If I go this route, what would the recommended exchange formats for
raster/grid and vector/shape be?

Many thanks for your comments, I feel this has been a productive discussion.
Regards,
Camilo