[Qgis-developer] Re: [saga-gis-developer] saga - qgis interface
Hy Volker, thanks for your code. I'm working for integrate it in SagaTools plugin. As soon as the plugin is usable I will share it as sperimentale in qgis repository. by gianluca ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Re: [saga-gis-developer] saga - qgis interface
On Sat, Feb 19, 2011 at 1:09 AM, Volker Wichmann wichm...@laserdata.at wrote: Hi Gianluca, Another issue which has to be solved is that of the Grid System parameter. As you most likely know, most of the SAGA grid modules require all grids to be processed within the same grid system. In case this is true for a module, I see two possibilities: (1) check this after you converted from GeoTiff to sgrd and before you call saga_cmd (2) leave the check to saga_cmd and catch the return error message I think there is an even better 3d option: derive it from the geotiff (or other) file. Unless you have one of those rare files which have nonsquare grid cells, it is perfectly possible to derive the origin and grid cell size. A 4th approach is doing what sextante is doing afaik: resample the grids if they don't match. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Re: [saga-gis-developer] saga - qgis interface
Il giorno sab, 19/02/2011 alle 01.09 +0100, Volker Wichmann ha scritto: please find attached a first approach - the script takes a module library name and a module name as input and parses all parameters. It prints out the parameters sorted by input, output and options and also prints out a final saga_cmd usage call. As Johan already mentioned, it will require some fine tuning in order to arrange the parameters in a meaningful way in the GUI dialog (i.e. like in SAGA GUI). The strict ordering in input/output/options is not suitable in this case. But I feel this is enough for starting a first implementation. Just one note: please do not hesitate uploading the plugin even in its first stages of development (just mark it as experimental), as soon as it is more or less usable: in this way it will be far easier for all interested to test it and give feedback (and perhaps get additional developers on board). Thanks. -- http://www.faunalia.it/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Re: [saga-gis-developer] saga - qgis interface
On Thu, Feb 17, 2011 at 1:27 AM, Volker Wichmann wichm...@laserdata.atwrote: 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 import sys, os, fnmatch, saga_api ## print '# SAGA API version: '+saga_api.SAGA_API_Get_Version() print '' modulepath= '/usr/lib/saga/' libraries = os.listdir(modulepath) mlb = saga_api.CSG_Module_Library() def printparameter(p): print '#' +str( p.is_Input())+str(p.is_Output())+str(p.Get_Type())+' '+p.Get_Identifier()+p.Get_Name() print '# '+p.Get_Description() for i in range(p.Get_Children_Count()): printparameter(p.Get_Child(i)) def parseparams(p, libnr): s='' if not p.is_Optional(): if p.Get_Type()==saga_api.PARAMETER_TYPE_Int: s='-'+p.Get_Identifier()+':'+str(1) if p.Get_Type()==saga_api.PARAMETER_TYPE_Double: s='-'+p.Get_Identifier()+':'+str(1) if p.Get_Type()==saga_api.PARAMETER_TYPE_Grid and p.is_Input(): s='-'+p.Get_Identifier()+':'+'esmall.sgrd' if p.Get_Type()==saga_api.PARAMETER_TYPE_Grid_List and p.is_Input(): s='-'+p.Get_Identifier()+':'+'esmall.sgrd' if p.Get_Type()==saga_api.PARAMETER_TYPE_Grid and p.is_Output(): s='-'+p.Get_Identifier()+':'+'out'+str(libnr)+p.Get_Identifier()+'.sgrd' if p.Get_Type()==saga_api.PARAMETER_TYPE_Shapes and p.is_Input(): s='-'+p.Get_Identifier()+':'+'smallpoints.sgrd' return s for fmlb in libraries: if fnmatch.fnmatch(fmlb, '*.so'): print '## Module library: ' + fmlb
Re: [Qgis-developer] Re: [saga-gis-developer] saga - qgis interface
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.vandew...@gmail.com On Thu, Feb 17, 2011 at 1:27 AM, Volker Wichmann wichm...@laserdata.atwrote: 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@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Re: [saga-gis-developer] saga - qgis interface
Hi Volker, In case your are interested in some python code which will parse the above mentioned parameters, I can have a look within the next days. Yes! I'm really interested! I'm not a really good python programmer and any kind of help is wellcome. Thanks gianluca ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Re: [saga-gis-developer] saga - qgis interface
Hi Johan, thank you for your interesting, suggestion and help: * how are module libraries and modules presented? In a menu or some type of module library? I think to use a 2-level menu (libraries/modules) * which qt interface would you like to use to present the different type of parameters that saga has. I'm agree, is an important decision and I'm still thinking about but, thanks to suggestions, now I've a quite precise idea * which types of modules would you like to provide first? Shape or grid based modules? I'm starting with grid module but I hope to work with overall saga 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)? Yes, I need to make a file conversion via gdal (yes, we can do it) for convert sgrd to Gtiff Thanks Gianluca ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Re: [saga-gis-developer] saga - qgis interface
Il giorno gio, 17/02/2011 alle 01.27 +0100, Volker Wichmann ha scritto: the Gdal-Tools seem to be more or less hard-plugged: every tool has its own description (.py file). Is your idea to generate these files (I'm not familiar with pyQT, but I would expect that generating these files would be a separate step, e.g. by running a script and committing the files to the QGIS source), which would be necessary for every API/module That's right: on the other hand, GRASS modules are autogenerated from the xml description. I think this second approach is much better if modules are 10, and if the interface of all modules is more or less constant. All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Re: [saga-gis-developer] saga - qgis interface
Hi Volker, grazie per il tuo interessamento e il prezioso aiuto I'm referring to files as accumulated.cost.spm attached this mail, generated from Accumulated Cost Anisotropic module GUI. Although now I've understand your opinion and I'm agree with you, my original idea was to automaticaly generate a GUI in QGIS (using pyQT) from something like xml file for capture parameters and past to a python script with saga_cmd (e.g. os.system(saga_cmd ). In that way I hoped to avoid build all GUI for each saga module in QGIS. This is quite tedious but I'll do it. Really I'm study raster plugin Hi Volker, thank you for your interest and the valuable help. About xml file, I'm referring to files as accumulated.cost.spm attached this mail, generated from Accumulated Cost Anisotropic module GUI. Although now I've understand your opinion and I'm agree with you, my original idea was to automaticaly generate a GUI in QGIS (using pyQT) from something like xml file for capture parameters and past to a python script with saga_cmd (e.g. os.system(saga_cmd ). In that way I hoped to generated on the fly GUI and avoid build all GUI for each saga module in QGIS. With the GUI I can past all parametere from GUI to python script. Actually, the use of saga_api is more robust way for programming plugin even If it could be more difficult for installation and configuration. My idea is build a plugin like Gdal-Tool (https://trac.osgeo.org/qgis/browser/trunk/qgis/python/plugins/GdalTools?rev=13639). Thanks Gianluca Il 15/02/2011 1.24, Volker Wichmann ha scritto: Hi, I don't know of a save button which outputs XML description - from the GUI you can create batch/html output, do you refer to that? But I would not recommend to trust on this, I think it is a bad idea to hardwire your plugin - every change in the module parameters naming or even new parameters would break your implementation of a SAGA module. For example, the RSAGA interface already suffered from such an implementation. I think you should use the SAGA python API to dynamically parse the parameters of each module - this would guarantee that your plugin would work with every SAGA build used. I am not familiar with QGIS and its plugin design, but from all posts regarding this topic I assume that you like to call a saga_cmd subprocess from the GUI. I would like to support the writing of some python code that would dynamically parse available SAGA modules and their parameters in order to build up module dialogs in QGIS. Could you point me to some sources which show the idea/implementation of QGIS plugins? I'm not a python programmer, but I use it for scripting, so maybe I could be of some help. Best regards, Volker PS: I'm not subscribed to the qgis-developer mailing list, so I'm not allowed to post to this mailing list. ?xml version=1.0 encoding=utf-8? PARAMETERS name=Accumulated Cost (Anisotropic) OPTION type=grid_system id=PARAMETERS_GRID_SYSTEM name=Grid system CELLSIZE-1/CELLSIZE XMIN0/XMIN XMAX0/XMAX YMIN0/YMIN YMAX0/YMAX /OPTION DATA type=grid id=COST name=Cost GridNOT SET/DATA DATA type=grid id=DIRECTION name=Direction of max costNOT SET/DATA DATA type=grid id=POINTS name=Destination PointsNOT SET/DATA DATA type=grid id=ACCCOST name=Accumulated CostNOT SET/DATA OPTION type=double id=K name=k factor2.00/OPTION OPTION type=double id=THRESHOLD name=Threshold for different route0.00/OPTION /PARAMETERS ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
