[Qgis-developer] SAGA Interface

[gianluca.massei]

hi camilo, I'm working to make a qgis-saga interface me too,  but with a 
"python approach". I haven't published my code because it's very 
experimental and really not usable. Anyway, at moment I can access from 
QGIS to saga via a simple menu. After the call, each  module print to 
stdout the "help" output (like "saga_cmd library_name module name -h"). 
I'm working to build GUI "on the flay" with pyQT but progress is really 
slow.
If you think to use python  I'm happy to work togheter  and I'll put my 
rough code on GitHub. Otherwise,  don't know C++ enough to really 
contribute at the develop of plugin.

Hi

Gianluca


Il 30/03/2011 13.16, Camilo Polymeris ha scritto:
> 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
>
>