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 <[email protected]> > On Thu, Feb 17, 2011 at 1:27 AM, Volker Wichmann <[email protected]>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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/qgis-developer > >
_______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
