[Qgis-developer] SAGA Interface

[G. Allegri]

Hi Camilo.
I agree with your approach. I already expressed it in past emails on this
topic.
Even if working at low levels requires some more overhead (cross platform
builds and support), it would bring a higher level of usability.
A first step could be the design of data structures wrappers/bindings
between  ones.
I think that true integration between QGIS and SAGA internal native data
structures.
Here [1] we started a discussion page. I couldn't go on with this project
because the company decided to not invest on it now, but I'm still
interested on it.

giovanni

[1] http://www.qgis.org/wiki/SAGA_Toolbox_for_QGIS

2011/3/30 Camilo Polymeris <cpolymeris at gmail.com>

> Hello, Paolo, and thanks for your swift answer.
>
> > Please do: I think this is quite interesting. Please note that Gianluca
> > Massei has started some work on this, so he may be able to start
> > quicker.
>
> Has Gianluca published his code? I'd like to see his approach and
> maybe work together. Mine is at github, BTW, but is completely
> unusable right now. Just experiments.
>
> > I think a C++ plugin has limited chances to be successful, because it
> > would either require a dependency of QGIS on SAGA, or the recompilation
> > of the plugin for each distro. Previous experiences in this direction
> > resulted in wonderful plugins used by very few people.
> > Python is the way to go IMHO.
>
> I may be wrong, but wouldn't a recompilation of the saga modules and
> saga API be necessary either way? Unless you install the full SAGA
> package. Even then, I am not sure if saga packages for all distros
> include the python bindings. These would have to be generated (SWIG)
> and compiled, too.
> Anyway, I was thinking more of a low level approach, dynamically
> loading the libraries and taking care of data structure exchange,
> which means this plugin wouldn't have the same requirements as most.
>
> > I think you should be able to complete the interface at least. Adding
> > all the modules may be postponed, if it proves too long. See the
> > GdalTools approach for this. Also the GRASS plugin should give you
> > insights.
>
> I'll try to identify the most used data structures and formats, see if
> there are some I can skip for now. Also I may leave out interactive
> modules, if necessary. Just to simplify things in the beginning.
>
> >> GUI: Any ideas? So far I think I'll just clone SAGA's.
> >
> > I think it would be good if you could follow either the GdalTools or the
> > GRASS plugins approach.
>
> I will take a look at that, considering that I have to generate the
> interface on-the-fly based on module parameters and input data. I find
> specially SAGA's handling of interactive modules a little confusing:
> often it is not clear to the user (me, at least) what he is expected
> to do next.
>
> One of the difficulties I have faced is generated by SAGA's
> documentation. I thought I knew the API more or less well, but this
> new project as forced me to use parts I hadn't looked at before.
>
> Well, thanks again for your comments.
>
> Regards,
> Camilo
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/qgis-developer/attachments/20110330/b05eba5c/attachment.html