Re: [Qgis-developer] SAGA Interface for QGIS - Final GSoC Report
Hi Camilo On Sun, Aug 21, 2011 at 3:02 AM, Camilo Polymeris cpolyme...@gmail.com wrote: Hello everyone, I am happy to say that this week saw many improvements in the QGIS Processing Framework and the interface to SAGA. [...] It's great to see the final touches improving the usability. Regarding the number of settings it would be good to offer as few choices as possible. Many times the settings can be avoided and a sensible default choice can be used. For example the setting Number of tags to show is very confusing. For the module dialog the status bar could be changed to a simple QLabel if you are not going to add further widgets or indicators to it. The status bar also contains a superfluous size gripper for changing dialog size. Additionally the Open and Save buttons simply close the module dialog - that's a bit unexpected :) Finally, due to rising interest in interfacing other libraries (GRASS, OTB) I have published the API documentation[3] on the framework and started writing a Developer's Tutorial[4]. Thanks for the documentation. In the developer's tutorial I am missing two important bits: 1. how to implement the module's functionality when Execute button is clicked 2. how to execute a module from a script or python console Google Summer of Code 2011 is almost over, but it is my intention to continue maintaining this software, first focusing on polishing the available code and later adding more features: Support for further parameter types, interactive modules, and module instance serialization, among many other proposed. It was great to have you aboard during the summer! We hope you enjoyed it and you will continue hacking on the processing/SAGA tools to support even broader range of modules and to make the user experience as seamless as possible. And of course you are welcome to start hacking on other parts of QGIS, too :-) Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] SAGA Interface for QGIS - Final GSoC Report
It's great to see the final touches improving the usability. Regarding the number of settings it would be good to offer as few choices as possible. Many times the settings can be avoided and a sensible default choice can be used. For example the setting Number of tags to show is very confusing. Agreed, in general terms. What the right number of settings is, we'll find out through experimentation. As you probably noticed, the 'number of tags' slider doesn't actually do anything, yet. For the module dialog the status bar could be changed to a simple QLabel if you are not going to add further widgets or indicators to it. The status bar also contains a superfluous size gripper for changing dialog size. Additionally the Open and Save buttons simply close the module dialog - that's a bit unexpected :) I use the size gripper! Sometimes the parameters don't fit horizontally, so I expand the dialog. Anyways, the feedback mechanism should be refined. I like those non intrusive pop-ups that e.g. firefox features, don't know if they are available in Qt, though. Finally, due to rising interest in interfacing other libraries (GRASS, OTB) I have published the API documentation[3] on the framework and started writing a Developer's Tutorial[4]. Thanks for the documentation. In the developer's tutorial I am missing two important bits: 1. how to implement the module's functionality when Execute button is clicked Yes. The tutorial is in a very early stage. Next chapter will be about that. I am looking for some simple algorithm or library to have the demo module do something at least remotely realistic/useful. 2. how to execute a module from a script or python console That would belong in the user's docs, I think. I have recently added some convenience functions. Will probably modify them, but for now you can e.g. type: from processing import framework framework[Pythagoras' Tree].execute(Method = 2) See also issues #46 #47 (github issue tracker). It was great to have you aboard during the summer! We hope you enjoyed it and you will continue hacking on the processing/SAGA tools to support even broader range of modules and to make the user experience as seamless as possible. And of course you are welcome to start hacking on other parts of QGIS, too :-) Thanks! It has been a great opportunity and lots of fun. I certainly will continue hacking on the processing SAGA code. In the long term, there are also some experiments I'd like to do with some geophysical models, to return a bit to the semantics of the problem. Regards, Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] SAGA Interface for QGIS - Final GSoC Report
Il 21/08/2011 03:02, Camilo Polymeris ha scritto: implementation. The programmatically collected stats, indicating support for 170 modules (40%) are published in the Module Support[1] wiki page, while the Tested Modules[2] page, maintained by Paolo, contains a list of SAGA modules that have actually been tested. Please note: due to time constraints, I'm able to properly test only a small subset of commands. Your help in testing more of them will be much appreciated. 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
Re: [Qgis-developer] SAGA Interface
On Sat, Apr 2, 2011 at 12:28 AM, Camilo Polymeris cpolyme...@gmail.com wrote: What I don't understand is: we'd have the same problems using python. There are, as far as I know, no Python-saga packages. Debian's libsaga[2], for instance, does *not* include python bindings. That means we'd have to compile ship the python-saga binding ourselves, anyway. Or am I missing something? This should be solved from the saga side, providing a package for it. That could be an option, yes. But they haven't done it, and I don't know if they would be interested. One of us could step up and offer packaging to SAGA, but I am not that experienced in packaging issues and distro-related complications. The saga wiki suggest using saga_cmd through python, which would need no recompilation, but would limit us to non-interactive plugins. Maybe that isn't so much of an issue, and would be easier. Excuse me for replying on such an old mail, but I only noticed this mail now (you should really have asked this on the debian-gis or saga developer list): the next debian package will include python support. In fact you can already get a source package with python-saga support from my launchpad page: https://launchpad.net/~johanvdw/+archive/sagacvs ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] SAGA Interface
Il giorno dom, 03/04/2011 alle 04.27 -0400, Camilo Polymeris ha scritto: Should the dialog be modal? IMHO yes. -- http://www.faunalia.it/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] SAGA Interface
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. Here is a screenshot of what it looks right now: www.udec.cl/~cpolymeris/QGIS_Screenshot_04032011.png You think that's a good direction? Needs a lot of polish, of course. Should the dialog be modal? Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] SAGA Interface
I was out yesterday, and I'm glad to see how things are going on! Camilo, I've browsed your repo but I can't find the parts where saga_cmd is being called... I suppose I missed some files. The python road is way more easy to develop and mantain, of course. I only fear dealing with large datas, where import/export and back could be an issue... But ok, don't make things complex befaure the time. It can be a further improvement in case it required. have a good sunday, giiovanni 2011/4/3 Camilo Polymeris cpolyme...@gmail.com 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. Here is a screenshot of what it looks right now: www.udec.cl/~cpolymeris/QGIS_Screenshot_04032011.png You think that's a good direction? Needs a lot of polish, of course. Should the dialog be modal? Camilo ___ 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
Re: [Qgis-developer] SAGA Interface
On Sun, Apr 3, 2011 at 5:02 AM, G. Allegri gioha...@gmail.com wrote: I was out yesterday, and I'm glad to see how things are going on! Camilo, I've browsed your repo but I can't find the parts where saga_cmd is being called... I suppose I missed some files. You are right.. seems I forgot to push the files. I'll do it as soon as I am on my development machine. The python road is way more easy to develop and mantain, of course. I only fear dealing with large datas, where import/export and back could be an issue... What do you mean? I'd like to be aware of any possible complications. But ok, don't make things complex befaure the time. It can be a further improvement in case it required. Of course. This is all just a hack.. I'll clean it up in time and make it more flexible. Using saga_cmd or saga_api as available. Regards, Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] SAGA Interface
Anyway, we need to build the single GUI module on the fly, and that is what I'm trying to do. In my mind: - mainteiner side: generate a xml file from saga_apy python called with all modules and related parameters; - user side: only use plugin with saga installed, without need to recompiled all sagag source with python interface. Are you agree? What do you about? gianluca Hello Gianluca I do generate the GUI on the fly: from the output of saga_cmd. No XML files. There are some problems, yet. And the code in the repo wont work, because I forgot to push some files, as Giovanni pointed out. Eventually, I'd like the GUI to be more complete if saga_api is present (which provides more information), but to work without saga_api, too. Regards, Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] SAGA Interface
Hi Camilo, I do generate the GUI on the fly: from the output of saga_cmd. No XML files. There are some problems, yet. And the code in the repo wont work, because I forgot to push some files, as Giovanni pointed out. Yes, I saw and I think your approach is very interesting, better than my! Tomorrow I'll try your plugin. By Gianluca ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] SAGA Interface
About large files: I'm just worried by the overhead with data export and import between QGis and SAGA. That's why I was interested in a low level data structure binding between the two environments. But as I've said, it can be an improvements eventually, in case it will really result to be an issue... I hope your GSoC proposal will be accepted! I'm an earth scientist too (geologist), and I'm going thorugh the same way of you: passion for IT and OSS, and programming. Now I would like some more earth back in my daily work, but we can't have eveything! :) So good luck Camilo! I will support this project as much as I can. I don't have founded projects in this moment for that, but I will be happy to spare some of my free time on it. Back to the module. Are we sure that offering two options (with or without saga_api) is feasible? I mean from the point of view of the effort. Probably you have already investigated this... I was also wondeing about two points: - should the plugin accept only layers previously loaded in QGis? This is the way Sextante works inside Gvsig (I suppose you know it). It enables only the plugins that accept the type of layer actually loaded (eg, vector inputs, raster inputs, etc.). Another possibility is to let the user choose wether to use a layer already loaded or browse for it on the filesytem (or db, etc.). - would you provide the saga-python module with the plugin? We could offer it, specifying wich version of SAGA it was been built for, to help those users which can't build the plugin by their own... See you, giovanni 2011/4/3 Camilo Polymeris cpolyme...@gmail.com Hello OSgeo I have submitted a Google Summer* of Code student proposal to continue work on the SAGA to QGIS plugin I started coding. It is available through the GSoC page [3]. Any comments are welcome, (and mentors, too :) Regards, Camilo [3] http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/polymeris/1001 * boreal ___ 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
Re: [Qgis-developer] SAGA Interface
Il 02/04/2011 0.28, Camilo Polymeris ha scritto: If I go this route, what would the recommended exchange formats for raster/grid and vector/shape be? Hi Camilo, gdal can handle saga grid native format. (http://www.gdal.org/frmt_various.html). For vectors I think the best chose is shape file. At least for first step. Gianluca ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] SAGA Interface
Il giorno ven, 01/04/2011 alle 18.28 -0400, Camilo Polymeris ha scritto: That could be an option, yes. But they haven't done it, and I don't know if they would be interested. One of us could step up and offer packaging to SAGA, but I am not that experienced in packaging issues and distro-related complications. You do not have to do everything. If the project is successful, others will jump in and help. The saga wiki suggest using saga_cmd through python, which would need no recompilation, but would limit us to non-interactive plugins. Maybe that isn't so much of an issue, and would be easier. Simplicity is the way to happyness. There is a third case: Using saga_cmd through python. This is the easiest in term of programming effort, I think. But is limited to non-interactive plugins, as I said before, and but would require a full saga installation. Sounds good. Very similar to the GRASS approach, I guess. You are right, and bring up some interesting arguments. You are starting to convince me. :) Great. Maybe I could even start with saga_cmd only (option 3) and later add support for interactive modules using the python api (if available), option 2. What do you think of that? Less elegant than a C++ solution, but much easier. As QGIS grows in complexity, it will become increasingly difficult to maintain too many different functions. So the KISS principle applies here. We need new functions that are not only interesting and useful, but also sustainable in the long term with the limited developer resources we have. Many thanks for your comments, I feel this has been a productive discussion. Glad if I can help. All the best. -- http://www.faunalia.it/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] SAGA Interface
the plugin is in code.google (http://code.google.com/p/qgis-saga-plugin/). This is what I have done so far: https://github.com/polymeris/qgis/tree/master/python/plugins/sagamodules Same as you, but basically I am trying to use only saga_cmd to keep things simple. The C++ version of the plugin I had started writing is in that repo, too. (Older commit, another directory) Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] SAGA Interface
Il giorno gio, 31/03/2011 alle 10.19 -0400, Camilo Polymeris ha scritto: What I don't understand is: we'd have the same problems using python. There are, as far as I know, no Python-saga packages. Debian's libsaga[2], for instance, does *not* include python bindings. That means we'd have to compile ship the python-saga binding ourselves, anyway. Or am I missing something? This should be solved from the saga side, providing a package for it. Let me try to explain: First case: C++ plugin; this requires recompilation of QGIS, so we have two options: - include the plugin in qgis-trunk, and add the dependency on saga; this is unlikely to be accepted by most core qgis-devs, I guess - leave the plugin outside qgis, and require the recompilation for each and every platform, and for each release of qgis; furthermore, osgeo4w users will not be able to use it with qgis-dev. Second case: Python plugin. The user will be able to install it or not, provided he has saga with its py bindings installed on its system. This will work with all versions of qgis (=minimum version, as defined in the plugin), on all OS. Speed shouldn't be a problem, as the plugin istelf should do very little calculations, only calling saga commands with the appropriate parameters, as it happens with the GRASS and the GdalTools plugins. Am I wrong? All the best. -- http://www.faunalia.it/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] SAGA Interface
What I don't understand is: we'd have the same problems using python. There are, as far as I know, no Python-saga packages. Debian's libsaga[2], for instance, does *not* include python bindings. That means we'd have to compile ship the python-saga binding ourselves, anyway. Or am I missing something? This should be solved from the saga side, providing a package for it. That could be an option, yes. But they haven't done it, and I don't know if they would be interested. One of us could step up and offer packaging to SAGA, but I am not that experienced in packaging issues and distro-related complications. The saga wiki suggest using saga_cmd through python, which would need no recompilation, but would limit us to non-interactive plugins. Maybe that isn't so much of an issue, and would be easier. Let me try to explain: First case: C++ plugin; this requires recompilation of QGIS, so we have two options: - include the plugin in qgis-trunk, and add the dependency on saga; this is unlikely to be accepted by most core qgis-devs, I guess What about including it in trunk, but only load the plugin if the dependencies are satisfied? Would the devs be ok with that? Provided the quality of the plugin is acceptable, of course. I also wouldn't require a *full* saga installation, if I am not mistaken. Only libsaga. - leave the plugin outside qgis, and require the recompilation for each and every platform, and for each release of qgis; furthermore, osgeo4w users will not be able to use it with qgis-dev. Second case: Python plugin. The user will be able to install it or not, provided he has saga with its py bindings installed on its system. This will work with all versions of qgis (=minimum version, as defined in the plugin), on all OS. There is a third case: Using saga_cmd through python. This is the easiest in term of programming effort, I think. But is limited to non-interactive plugins, as I said before, and but would require a full saga installation. Speed shouldn't be a problem, as the plugin istelf should do very little calculations, only calling saga commands with the appropriate parameters, as it happens with the GRASS and the GdalTools plugins. I agree speed isn't a problem. Am I wrong? You are right, and bring up some interesting arguments. You are starting to convince me. :) Maybe I could even start with saga_cmd only (option 3) and later add support for interactive modules using the python api (if available), option 2. What do you think of that? Less elegant than a C++ solution, but much easier. If I go this route, what would the recommended exchange formats for raster/grid and vector/shape be? Many thanks for your comments, I feel this has been a productive discussion. Regards, Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] SAGA Interface
I understand your point Paolo, and I can't contribute to C++ coding now, so I can't support it practically. But: - if Camilo can do it, he's welcome. I suppose he's conscious of what it means, also from a lon term support point of view... With GRASS module we have the same issues, am I wrong? - without a low-level interactions between QGis and SAGA, what is the real usefulness of this plugin? SAGA needs to be installed anyway (and it's easy), we already can import/export between the two's... Ok all the effort would be directed to avoid opening the SAGA interface. Mmm, I don't see such a great gain to justify the effort. Just two cents to share opinions. I'm just wondering giovanni 2011/3/31 Paolo Cavallini cavall...@faunalia.it On Wed, 30 Mar 2011 20:31:14 -0400, Camilo Polymeris cpolyme...@gmail.com wrote: Thanks for your comment. For those reasons and the ones I mentioned in the original mail, I think I'll be going the C++ route. Sorry to insist, but I think this is not a good choice. We already had experiance with several non-core C++ plugins, some of them extremely useful, and all of them are essentially unavailable to users. On the other hand, it is probably unfeasible to add a dependency on SAGA. The single argument that seems to favour Python is the greater availability of coders. Giovanni and Gianluca have responded to this mail saying they would work on a Python version. No other C++ coders interested, yet :( This should mean something, even though it is not the crucial issue. All the best. -- http://faunalia.it/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] SAGA Interface
Sorry to insist, but I think this is not a good choice. We already had experiance with several non-core C++ plugins, some of them extremely useful, and all of them are essentially unavailable to users. On the other hand, it is probably unfeasible to add a dependency on SAGA. What I don't understand is: we'd have the same problems using python. There are, as far as I know, no Python-saga packages. Debian's libsaga[2], for instance, does *not* include python bindings. That means we'd have to compile ship the python-saga binding ourselves, anyway. Or am I missing something? Are you, Gianluca, using the command-line interface to saga or the python bindings? That former is very interesting as a compile-free option, but ultimately is limited to certain tasks and to having saga_cmd installed. Both options (command line and API) are not exclusive. Regards, Camilo [2] http://packages.debian.org/squeeze/amd64/libsaga/filelist ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] SAGA Interface
You're right Camilo, python-saga bindings are available in source, as ready-to-use batch commands (saga_api_to_python_linux.sh and saga_api_to_python_win.bat): http://saga-gis.svn.sourceforge.net/viewvc/saga-gis/trunk/saga-gis/src/saga_core/saga_api/) to compile them through SWIG It means we have to provide them along the QGis-SAGA plugin by ourselves giovanni http://saga-gis.svn.sourceforge.net/viewvc/saga-gis/trunk/saga-gis/src/saga_core/saga_api/ 2011/3/31 Camilo Polymeris cpolyme...@gmail.com Sorry to insist, but I think this is not a good choice. We already had experiance with several non-core C++ plugins, some of them extremely useful, and all of them are essentially unavailable to users. On the other hand, it is probably unfeasible to add a dependency on SAGA. What I don't understand is: we'd have the same problems using python. There are, as far as I know, no Python-saga packages. Debian's libsaga[2], for instance, does *not* include python bindings. That means we'd have to compile ship the python-saga binding ourselves, anyway. Or am I missing something? Are you, Gianluca, using the command-line interface to saga or the python bindings? That former is very interesting as a compile-free option, but ultimately is limited to certain tasks and to having saga_cmd installed. Both options (command line and API) are not exclusive. Regards, Camilo [2] http://packages.debian.org/squeeze/amd64/libsaga/filelist ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] SAGA Interface
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@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] SAGA Interface
On Wed, Mar 30, 2011 at 9:59 AM, G. Allegri gioha...@gmail.com wrote: Hi Camilo. I agree with your approach. I already expressed it in past emails on this topic. Even if working at low levels requires some more overhead (cross platform builds and support), it would bring a higher level of usability. A first step could be the design of data structures wrappers/bindings between ones. I think that true integration between QGIS and SAGA internal native data structures. Thanks for your comment. For those reasons and the ones I mentioned in the original mail, I think I'll be going the C++ route. The single argument that seems to favour Python is the greater availability of coders. Giovanni and Gianluca have responded to this mail saying they would work on a Python version. No other C++ coders interested, yet :( So, I have roughly divided the work to be done in a list of smaller tasks. These I have sorted in a way that would allow me, I hope, to reach one goal by end of the first GSoC term and other by end of the second term. This list is at the end of this message and would apply with minor modifications to a Python module, too. The intention here is to come up with a timeline and to identify what the hardest parts of the process are going to be, possible pitfalls, etc. Please let me know if you have identified tasks I haven't considered. I think this is a good exercise, even out of the GSoC context. When its better formulated and if there are no objections I'll add it to [1] http://www.qgis.org/wiki/SAGA_Toolbox_for_QGIS Regards, Camilo (0) PRE-GSOC (now :) Tasks: - Proposal - Development environment - Software design - Setup project (1) FIRST TERM GOAL: Implement basic functionality, have *at least one* module working. Implementation requirements: - Plugin registration - Library handling - Module loading - GUI: Basic module list - GUI: Module dialog, generic widget for options - Option parameters: Boolean, Integer, Floating Point - Input/output data structures: Grid (2) SECOND TERM GOAL: Polish functionality and interface, have most non-interactive modules working. Requirements: - Options: Choices - Options: Value Range - Input/output: Shapes - Option constraint: Integer, Floating Point - Option constraint: Choices - GUI: Appropiate specific widgets based on option constraints - GUI: Library module descriptions, basic help - Packaging (ugh) (3) POST-GSOC GOAL: Add support for remaining modules, including interactive modules. Other interface improvements. Requirements: - Options: All other remaining options - Input/output: Table and remaining data structures - Interactive modules: Grid - Interactive modules: Line, Box, Circle - GUI: Interactive - GUI: Save load functions (XML) - Python bindings (4) LONG-TERM GOAL: Conquer the GIS world ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
