[Qgis-developer] SAGA Interface

[G. Allegri]

Hi Gianluca,
I can't say how much I could dedicate to that, but if you could put it on
GitHub I could find some time to contribute.
I don't think I can invest time on the low level development, but with
Python I think I could give some time.

giovanni

2011/3/31 gianluca.massei <g_massa at libero.it>

> 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
>>
>>
>>
> _______________________________________________
> 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/20110331/b995762d/attachment.html