[Qgis-developer] Re: [saga-gis-developer] saga - qgis interface

G. Allegri giohappy at gmail.com
Thu Feb 17 04:52:47 EST 2011


It's a project we were thinking about a couple of years ago, but the project
has stopped (we've had to move the founds to other projects) The approach
was similar to yours, but I was thinking to a lower level binding: let saga
odules read directly from Qgis in memory data structures, without having to
import/export data. In the latter case our doubt was: if we have to do that
we already have the saga gui! We didn't see the gain in having a qt
module... other than having to open saga gis.
I haven't investigated this too much, and maybe it's a lot of work to do it
(C++ code to be written, etc.), but it would give a great value to such a
module. Don't you think?

Anyway, the first steps of having a python gui interface to saga-api is
certainly foundamental.

giovanni


2011/2/17 Johan Van de Wauw <johan.vandewauw at gmail.com>

> On Thu, Feb 17, 2011 at 1:27 AM, Volker Wichmann <wichmann at laserdata.at>wrote:
>
>> Hi Gianluca,
>> My idea is to write a python code that will generate GUI
>> dialogs completely on the fly without any hard coded parameter flags or
>> .py files (SAGA has about 500 modules!). That is, you have a path where
>> your SAGA modules (.so/.dll) reside and then your QGIS GUI will use the
>> saga_api to generate the dialogs for the available modules on the fly.
>> As far as I see, all you need is the following information:
>> * module library name
>> * module name
>> * module (saga_cmd) parameter names
>> * module parameter types
>>
> That seems the best approach to me as well. I've attached a script which
> creates a saga_cmd call for most modules, which I once used to check if
> there are any obvious errors/memory leaks. As mentioned before, this script
> is the first thing I wrote in python, so sorry for any strange unnecessary
> constructions and/or errors, but it should give you an idea how to browse
> through the module libraries, modules and their parameters.
>
>
>> All you would need is a generic python module which would generate the
>> dialogs for QGIS using the saga_api on the fly and another python module
>> which would use the information entered in these QGIS dialogs to call
>> saga_cmd. But maybe I'm getting this wrong.
>>
>
> Prior to jumping towards dialogs, perhaps it is useful to think about how
> you want to integrate saga and qgis:
> * how are module libraries and modules presented? In a menu or some type of
> module library?
> * which qt interface would you like to use to present the different type of
> parameters that saga has. This is really an important decision. I personally
> think that the way saga relies heavily on wxpropgrid to generate its
> interfaces is really nice. Someone who knows qt well may give some advice
> here what the best approach would be. If some kind of property grid is
> already used in qgis, I would certainly look to that. I really think this is
> one of the most important decisions - some modules have a lot of different
> parameters (eg [2]) and presenting them in an orderly way is quite a
> challenge.
> * which types of modules would you like to provide first? Shape or grid
> based modules?
> * how do you handle file conversions? Eg a geotiff is open in qgis. Prior
> to running this module, it will have to be converted to a .sgrd file (can be
> done with gdal)?
>
> In fact, if I would be starting this project, I would use this approach:
> 1. Create some type of menu/module library to show the saga modules
> 2. If these are opened show a very basic window showing a generated command
> line and a html box with the documentation of the module (eg [2]). At that
> point, you actually have nothing more than a nice way to browse through the
> saga modules from qgis, without any integration. But it offers a starting
> point.
> 3. If a good approach is found to generate the kind of property grid, you
> could switch to having a text box per parameter type. In a next step, some
> options may be converted to better suited interfaces, eg showing a list of
> grids present in qgis. At this point, I think development can be done by
> different people: someone is working on an interface for shapefiles, someone
> else on file conversion issues/... At this point, knowledge of the saga api
> is less important, and most work is done in python/qt.
>
> [1]
> http://www.saga-gis.org/saga_api_doc/html/parameters_8h.html#005312577c5ba61839e45f6a19b94218
> [2]
> http://www.saga-gis.org/saga_modules_doc/grid_analysis/grid_analysis_19.html
>
> _______________________________________________
> 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/20110217/fc8f7278/attachment.html


More information about the Qgis-developer mailing list