Re: [Qgis-developer] Moving SEXTANTE into QGIS core
On Sat, Aug 4, 2012 at 5:16 PM, Tim Sutton li...@linfiniti.com wrote: Hi All (Especially Paolo and Victor) For interest of others, Paolo, Victor and myself had an offlist discussion about the procedure for moving SEXTANTE into QGIS core. This weekend I took the first step my exporting the SEXTANTE plugin from svn and bringing it over to the QGIS repo with all it's history. The code still sits in a branch because there is no CMake support for it yet. This is great. Just 1 question: I started working with a git clone right away, thinking the svn repo would be abandoned, but Victor tells me he is still commiting to svn. Could this be a problem in a future merge? Thanks, Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Tests for sextante qgis providers.
Thank you, Tim. That helped a lot. On Thu, Jul 19, 2012 at 3:38 AM, Tim Sutton li...@linfiniti.com wrote: Hi On Thu, Jul 19, 2012 at 9:36 AM, Tim Sutton li...@linfiniti.com wrote: Hi On Wed, Jul 18, 2012 at 12:58 AM, Camilo Polymeris cpolyme...@gmail.com wrote: Hello all, I have had some difficulty with implementing the tests for Sextante, in particular, using QgsProviderRegistry. cf: http://code.google.com/p/sextante/source/browse/trunk/soft/bindings/qgis-plugin/src/sextante/tests/qgis_interface.py The providers seem not to load. Note that the qgis interface stub is initialized after a call to QgsApplication.initQgis(). If you have any pointers on what I could be doing wrong, it would be very much appreciated. I didnt have time to look through your code right now (maybe this evening I will have a chance), but try looking at this project where I have implemented a working test suite for a QGIS python plugin. https://github.com/AIFDR/inasafe/tree/master/gui The tests are run automatically whenever a git push happens so you can see what is produced here: http://jenkins.linfiniti.com/job/InaSAFE/ In particular also look at this https://github.com/AIFDR/inasafe/blob/master/gui/utilities_test.py#L58 which uses an env var 'QGISPATH' to set up the search path for providers etc. Regards Tim Regards Tim Thank you regards, Camilo -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Tests for sextante qgis providers.
Hello all, I have had some difficulty with implementing the tests for Sextante, in particular, using QgsProviderRegistry. cf: http://code.google.com/p/sextante/source/browse/trunk/soft/bindings/qgis-plugin/src/sextante/tests/qgis_interface.py The providers seem not to load. Note that the qgis interface stub is initialized after a call to QgsApplication.initQgis(). If you have any pointers on what I could be doing wrong, it would be very much appreciated. Thank you regards, Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Fwd: Threads in sextante
Hello again, in case you missed the post on the soc mailing list, I have posted a first report on this project at sextante-gsoc.blogspot.com I haven't figured out how to attach files to blogger posts so I'll just attach a diff to this thread, so you can have a look at the preliminary implementation. As said, I went with QThreads for this paticular case, because: a) QProcess, I think, belongs in another level (the calling the auxiliary programs layer) and I am not sure it applies to potential backends using libraries. b) QtConcurrent seems not to have pyqt bindings I might be wrong on any (or both) of these points. Please comment. Note that iterating parameter values are not yet supported. Am looking into it, not sure if sextante or the backends make any assumptions about the order of iteration (that is, I have to use 1 thread or multiple synced threads) or if I can just run them in parallel. Thanks regards, Camilo mt2.diff Description: Binary data ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Re: Starting GSoC
Hello Victor, cc: qgis-developers mailing list. I am working on the mt thing. You can see the approach I am taking in the attached diff, but it basically revolves around starting a QThread for each algorithm qt signaling. Still not sure how to replace e.g. the progress objects. Also, created a blog here: http://sextante-gsoc.blogspot.com/ Hope that platform is ok (I have zero experience with blogs), intend to write a short intro to my project now and on monday my first report. Regards, Camilo mt1.diff Description: Binary data ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Fwd: Threads in sextante
On Sun, May 13, 2012 at 5:13 PM, Victor Olaya vola...@gmail.com wrote: Here is my opinion on all that, in short: -The main idea of using threads is not now to execute multiplep algorithms at the same time, so we can remove a lot of complexity (like 2 processes writing the same file, as it was mentioned) -Implementing a canceling mechanism is going to be the greatest improvement once we have the threading stuff -So, for me, this is what should be done: 1)implementing the threading part 2) implement the cancelling mechanism (a responsive cancel button, etc) 3) modifying algorithm to respond to cancellin events. That sums it up, I think. One main QThread for the GUI stuff + one for the analysis, controlling the later by mean of signals. Aditionally using QProcess (or not) is something that can be decided on a backend-by-backend basis -- potentially some of the backends will use direct APIs or remote connections, not commandline programs. Thanks for all the feedback. Regards, Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Fwd: Threads in sextante
Hello all, one of the things I will be implementing for sextante during GSoC will be multithreading. I have experimented a bit with the possibilities during the last few days, but it would be good to know your opinion on what would be the simplest, cleanest solution. At this point I feel the obvious place to introduce this functionality is the AlgorithmExecutor class, as suggested by Victor, converting that to an instantiable class, inheriting from QThread. I tend to favor QThread over the python standard threads, because its signaling system is familiar to all working with Qt and would interact better with the existing GUI code. In adition to the standard thread signals (started, finished, terminated), the algorithm thread would emit canceled, error, feedback and percentageChanged signals, when necessary. The later two would be connected to Progress objects. All GUI code would be moved out of AlgorithmExecutor. Please comment if you see a better/easier way to implement this or any potential pitfalls with this design, Regards, Camilo -- Forwarded message -- From: Paolo Cavallini cavall...@faunalia.it Date: Thu, May 10, 2012 at 5:17 AM Subject: Threads in sextante To: Camilo Polymeris cpolyme...@gmail.com, Victor Olaya vola...@gmail.com, Alexander Bruy alexander.b...@gmail.com, Giuseppe Sucameli sucam...@faunalia.it Hi all. I'm here with Giuseppe AKA brushtyler, and we're having a very interesting discussion about threads sextante. I would suggest to move the whole discussion to the ML before starting to coda, as I see several alternative solutions to the problem; some of them may be unnecessarily complex, so perhaps all together we could design a simple and effective solution. Camilo, could you please resume the issue on the ML, so we'll start a discussion there? Thanks a lot. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Welcome to 4 QGIS students in Google Summer of Code 2012
On Tue, Apr 24, 2012 at 6:55 AM, Anne Ghisla a.ghi...@gmail.com wrote: Hello all, and sorry for cross-posting, let me introduce our 4 accepted students for OSGeo Google Summer of Code 2012: - Camilo Polymeris, mentored by Victor Olaya on the project Orfeo Toolbox backend for the Sextante framework in QGIS Hello all, that is me, and I am very happy to have been accepted to work with QGIS for this years GSoC. Thank you, org admins and mentors, for making this possible! Just like last year, when I ended up doing something a bit different than what was described in my formal project, my project this year, while still QGIS- and sextante-related, will probably have less to do with OTB than apparent from the title, since J. Malik is already working on that. Looking forward to be contributing to the core of sextante and incorporating some ideas from PF, instead. On a practical note, which might also be of interest to the other students: What do you think is the best channel to publish progress reports? One option would be to start a blog or similar (where? last year I used the github wiki, but I think it wasn't too visible), another to just start a thread on the qgis-developer mailing list for that purpose. Best regards, Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Proposal: QGIS Processing Framework improvements
On Tue, Mar 27, 2012 at 4:18 AM, Victor Olaya vola...@gmail.com wrote: Yes, I wonder about that too. I don't haven't really figured out how sextante works, but it seems a very different approach: calls backends through the commandline, which makes it much simpler to implement, of course, but also limited in some aspects: no interaction, only batch based jobs. I might be wrong, though. Calling algorithms from SEXTANTE doesn't have to be done through the command line. In fact, the idea behind SEXTANTE is to make it as easy as possible to create your own algorithms, and that might be writing it directly in Python, calling a 3rd party app on the console, or doing it through a Python binding I guess friendly competition has its advantages, too. Of course, but it would also be great to join platforms or at least improve one based on the other. I will be at Lyon for the developers meeting (looking forward to it!!): Any chance that you might attend the meeting as well?? Unlikely... am too far away. :( What I can gather from this discussion is that the framework is redundant, sextante seems the way to go, more mature and more straightforward design (from what I can tell). If you agree, I'll withdraw my proposal and see if there is anything I can do to improve on sextante. (Through GSoC or otherwise) Pehaps some of the things (code or ideas) developed for the framework can be reused, and if not... at least it was a learning experience. Regards, Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Re: QGIS Processing Framework
[0] http://lists.osgeo.org/pipermail/qgis-developer/2012-March/018823.html [1] http://code.google.com/p/sextante/source/browse/#svn%2Ftrunk%2Fsoft%2Fbindings%2Fqgis-plugin Sure, having two frameworks makes no sense. Anyone had the time to check the new sextante implementation? If I understand correctly, Сергей is proposing integrating sextante into the existing framework, not necessarily duplicating anything. I was thinking of applying to this year's GSoC with a project to polish the QGIS Processing Framework, specifically: a) Address some long standing issues, like running modules in separate threads deciding how to handle output layers. b) Completing support for tables, pointcloud, SAGA modules. c) Overall a nicer interface. In this process, things can be changed to be make it easier to interface with Sextante or other tools. Regards, Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Re: QGIS Processing Framework
On Thu, Mar 22, 2012 at 5:31 AM, Martin Dobias wonder...@gmail.com wrote: On Wed, Mar 21, 2012 at 7:23 PM, CzendaZdenda tramt...@seznam.cz wrote: If there is possibility that output parameter of the module can have any type, how can I handle with modules' outputs? Or just raster/vector layers are outputs? I mean how can I keep outputs after execution of module ( processing.Framework['module'].execute() ). I am working on 'workflow builder'. I can connect modules or set values by myself. Now I want execute whole 'graph', so that's why I need to keep outputs. I was looking at present modules and types of output are just raster/vector layers or the basic type Parameter. So is there possibility that output type could be something like string, bool, int...? Hi, in my view any parameter type that could be specified as an input should be allowed also for output - not just layers. For example: a module that does statistics on a layer and returns mean and standard deviation - these would be just two scalar output values and could be used by some other module. In general, both inputs and outputs should ideally be treated the same way: they are variables (parameters) of some type and with some value. Sure, that is the intention and is reflected as such in the processing framework. (Every Parameter type can be a input/output/control/feedback) The SAGA backend doesn't handle every possible combination, yet, because either there is no need (not used by any modules) or because there are outstanding issues (e.g. still don't know what to do if running a module would overwrite a layer... ask the user? fail? succeed, but create a backup?) So, yes, you should be able to connect any output of compatible type to any input in your module builder. E.g. the standard deviation in Martin's example could be used as an input to some other module. Perhaps we could at some point also create a control arithmetics module set to complement the module builder, I can imagine you'll often want that stdev scaled by some amount, for example. Regards, Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Re: Qgis-developer Digest, Vol 73, Issue 51 [To GPL or not to GPL]
I understand it *does* mean that you have to be the one sending the source. If you distribute a GPL'd binary without source you have to include a written offer to send the source to any party that receives that binary, even indirectly. In general it should be easier to include the source in the first place No, you need to supply the source to the client (or provide access to it). If the client provides a binary to a third party then it is them who needs to provide the source, not you. You don't have any relationship with the third party - you hold copyright to some of the code, but you have granted the client permission to redistribute it under the GPL. From the GPL FAQ[1]: The reason we require the offer to be valid for any third party is so that people who receive the binaries indirectly in that way can order the source code from you. This may only apply to GPL 2, though, I am not sure. What I am not completely sure is if, besides the users (receivers of modified binaries), the original copyright holders may have a right to the modified sources, even if they haven't received a binary. Say, programmer makes modified version of QGIS for a company, and sends it only to them. The company has a right to the modified sources. Do the original QGIS devs have that right, too? No, they don't. Thought so. Thanks for the clarification. [1] http://www.gnu.org/licenses/gpl-faq.html#WhatDoesWrittenOfferValid ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QIGS GPL - LGPL - Tigers, Lions and Bears Oh My!
It would be any user getting their hands on this binary. If your client gives a copy to his friend then his friend has the right to the source (it doesn't mean that YOU have to the one sending the source). I understand it *does* mean that you have to be the one sending the source. If you distribute a GPL'd binary without source you have to include a written offer to send the source to any party that receives that binary, even indirectly. In general it should be easier to include the source in the first place This applies to LGPL'd code, too, of course. If you modify the code itself, that is, and not merely link to it. What I am not completely sure is if, besides the users (receivers of modified binaries), the original copyright holders may have a right to the modified sources, even if they haven't received a binary. Say, programmer makes modified version of QGIS for a company, and sends it only to them. The company has a right to the modified sources. Do the original QGIS devs have that right, too? (if they knew there was a modified version of the source floating around -- that would often be kept behind closed doors, I guess) Interesting discussion, btw. There is no code of mine involved, so I don't really have a say in this, but if I were you, I would keep everything GPL. At very most, the core libraries could be LGPL'd, to make it easier to interface them to proprietary applications, while keeping the higher level stuff (GUI, and such) GPL. Regards, Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Re: QGIS Processing Framework
Hello all, Yes, I will glad to help you. At beginning, is there some small problem, on which I can test me, whether my programming skills are enough and I am able to help you? I think Camilo is the best person to talk to. Please have a look to the archives of the ML, and to https://github.com/polymeris/qgis/wiki All the best, and welcome on board! Great to see a new potential contributor to the processing framework! I have collected some of the conclusions from previous discussions and some of my own thoughts on this module piping thing, here: https://github.com/polymeris/qgis/wiki/Workflow-Builder Please comment, complement criticize. Regards, Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Re: QGIS Processing Framework
Hello Zdenek, Yes, I will glad to help you. At beginning, is there some small problem, on which I can test me, whether my programming skills are enough and I am able to help you? if you are looking for a smaller task to get familiar with the code base, we have a list of pending issues, here: https://github.com/polymeris/qgis/issues Some are almost complete, while some are just vague ideas. Regards, Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Module piping GUI [Was: analytical workflow]
Hello everyone, in an earlier thread, the implementation of analytical workflows --sets of modules with linked inputs and outputs-- was discussed. While this can currently be attained using Python scripts, a GUI to interactively construct these workflows would be a nice addition to the userfriendliness of the processing framework. Two main possible designs for this GUI came up: Either, a connect-the-boxes-style GUI (a graph): On Wed, Aug 24, 2011 at 4:26 AM, Johan Van de Wauw johan.vandew...@gmail.com wrote: Sextante has a nice modeler tool - it may be a good example how it could work: http://www.gvsig.com/files/images/screenshots/gvSIG_Sextante_02.png or, a patchbay-style GUI: On Tue, Aug 23, 2011 at 9:45 PM, Camilo Polymeris cpolyme...@gmail.com wrote: A bit like qjackctl's patchbay: http://ubuntu.allmyapps.com/data/q/j/qjackctl-jack-control/UBUNTU-9.04/qjackctlPatchbayForm1.png It looks tidier and would also be a bit easier to implement than free-floating boxes. While the former seems to be a more popular choice among existing software, I favor the latter option, because it would better handle numerous I/Os. Your opinion on this would be appreciated. Regards, Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Project directory -or- where to store generated layers
Hello again, there is another processing-framework-related issue I would like your opinion on: The input and output layers of modules are currently stored in the /temp directory or its windows equivalent. These files are, of course, not persistent between sessions. Or as Paolo wrote in the processing bug tracker[1]: Users should be able to save the results outside tmp, and give a meaningful name; for vectors this is not a big issue (one could always Save as... after analysis), but for rasters is more cumbersome. See GdalTools for examples. Temp files should be left only for intermediate steps; users usually want a file as a result. The problem is that, as far as I know, QGIS doesn't provide something like a project directory. So what should the default path be? The current working path? Regards, Camilo [1] https://github.com/polymeris/qgis/issues/38 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] New QGIS logo
I am not much of a designer... but still, had fun creating a variation of your idea: http://imageshare.web.id/images/xb6dtdeotcghebwct53k.png Regards Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] analytical workflow
I agree with martin - such a Modeler could be a great improvement but I assumed it would be somethink like the WxGUI_Modeler .. Yes, I also imagine something similar. But, I prefer more ordered layouts, where you have all outputs in a column on the left side, and all inputs in a column on the right side. In between all connections displayed as lines of different color depending on parameter type and such. A bit like qjackctl's patchbay: http://ubuntu.allmyapps.com/data/q/j/qjackctl-jack-control/UBUNTU-9.04/qjackctlPatchbayForm1.png It looks tidier and would also be a bit easier to implement than free-floating boxes. On the logic side: For input and output the most flexible would be to use python scripts. Of course, it is harder than e.g. XML, and there would be limits to what python code it would understand on input. But still, I think it is the best option. The user would then have the option of saving these workflow presets and using them like any regular module. 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
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
[Qgis-developer] SAGA Interface for QGIS - Final GSoC Report
Hello everyone, I am happy to say that this week saw many improvements in the QGIS Processing Framework and the interface to SAGA. Primarily, raster input and output works now, thanks to help from SAGA developer Volker Wichmann. Single band local QGIS rasters are transparently converted to SAGA format using GDAL, processed, and imported back into QGIS. Many things could be improved and features added, but the basic functionality is there. To assess the progress of the interface, I have written a small script, which checks module support, as determined by parameter 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. Work on a settings dialog has started. It is still unclear how many and which settings should be left to the user. Also on the GUI side, an about dialog was implemented, which displays the new processing icon by Robert Szczepanek. In an effort to be consistent with the QGIS terminology, the string raster is now automatically substituted for instances of grid in each SAGA module's text: Names, tags, parameters and descriptions. Less visible to the user, but still important, the SAGA code has been refactored a little. Work is still pending on this issue. Additionally, the plugin's objects are now managed in a cleaner way. Validator and default value bugs have been fixed. Further testing is necessary. 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]. 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. Best regards thanks a lot for the help, Camilo [1] https://github.com/polymeris/qgis/wiki/Module-Support [2] https://github.com/polymeris/qgis/wiki/Tested-Modules [3] http://polymeris.github.com/qgis/processing.html [4] https://github.com/polymeris/qgis/wiki/Developer%27s-Tutorial ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] least surprise, or: which terms should be used?
Now we have to think about human interface. One thing is: which terms should be used? SAGA uses grid, whereas QGIS uses raster. To me, the idea is to have a consistent GUI in QGIS, so better use the QGIS terms not to scare off our users, but this could be confusing for previous SAGA users. I see this as a minor problema, but I may be wrong. Replaced grid and gridd for raster. Of course, the question applies to shapes, vector/vector feature and probably other SAGA terms. Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Re: SAGA Interface for QGIS - Weekly report
Hello This week I have implemented Range parameters and tried to implemented the SAGA's raster output. To do this I have tried to solve various issues, mostly regarding specifying grid systems to the module. I have implemented a widget that allows the user to set a custom grid system and mechanisms to take the grid system from the input grids. The efforts haven't been enough, tough, SAGA modules keep outputting invalid rasters. A discussion concerning this issue is going on at the saga-gis-developer mailing list[1]. I hope that with a little help I'll be able to solve this during this week. Additionally I have solved a few bugs concerning plugin initialization, string parameter conversion and GUI issues. The list of pending issues has been moved to the tracker provided by github[2], in preparation of further work after end of the GSoC project. In case you are interested in testing the --still very experimental-- project, a short document explaining installation and basic usage is now available through the wiki[3]. As said, for next week, raster output implementation is of top priority. While this gets sorted out I'll complement the code's documentation, in particular the processing framework's. This and earlier reports can be read at the usual page[4]. Regards, Camilo [1] http://sourceforge.net/mailarchive/message.php?msg_id=27868820 [2] https://github.com/polymeris/qgis/issues [3] https://github.com/polymeris/qgis/wiki/SAGA-Interface-HOWTO [4] https://github.com/polymeris/qgis/wiki/Reports ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Re: SAGA Interface for QGIS - Weekly report
I have fallen a bit behind schedule while trying to implement data exchange. Many issues have arisen, but finally vector output (from SAGA's perspective) is working. Neither input nor raster work yet. Next, I'll consider the former, while also fixing some bugs in parameter selection (especially file choices). Having partially implemented data exchange, at least one SAGA module works: Pythagoras' tree. At the usual page[1] is a screenshot of that module in action. [1] https://github.com/polymeris/qgis/wiki/Reports ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] SAGA Interface for QGIS - Midterm report
Hello everyone, This week+, I polished different parts of the module dialog, adding specific widgets callbacks (signals) for actions value changes, including, e.g. a FileSelector widget for paths, and a combobox for available layers or module specific choices. See screenshot [1]. This will allow the modules to change the available parameters (and their presentation to the user) in reaction to value changes. Also, the module instance's state (stopped, running, paused, etc.) mechanism was implemented on the processing side. This is yet invisible, because I haven't interfaced it to SAGA (see `moduleinstance.py`). This being the last week of the first term, I also tried to look ahead a little to what expects us during the next few weeks, which are the most important things that are missing and how to implement them. With the help from other developers through the mailing list, I compiled a list thereof [2]. In summary, due during the next term, in my opinion, are: * Data exchange (passing vector raster data from QGIS to the implementation, will be done with ogr/gdal), starting now. * Multiple value parameters * Logging progress report * Module instance serialization (storing presets of module values), also as intermediate step to accessing the moduleinstance from a cleaner python API. * Better code documentation unit tests. I hope to also squeeze in some other minor parts (GUI things and such). In conclusion, I think this has been a productive week and a very fun first term. I am grateful for all the friendly (and insightful) comments criticism I have received. Thanks a lot! Regards, Camilo [1] https://github.com/polymeris/qgis/wiki/Reports [2] https://github.com/polymeris/qgis/wiki/Timeline ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS Processing Framework
On Fri, Jul 8, 2011 at 1:25 AM, Paolo Cavallini cavall...@faunalia.it wrote: Il 07/07/2011 23:06, Camilo Polymeris ha scritto: identify a few and compile a short list[1], to try to keep focused List missing ;) Oops. [1] https://github.com/polymeris/qgis/wiki/Timeline ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS Processing Framework
On Fri, Jul 8, 2011 at 2:53 AM, Tim Sutton li...@linfiniti.com wrote: Hi Sorry I just caught up on this thread now. I share Martin's concern about dropping C++ support by adopting traits directly. Have you made a decision on this, is C++ still on the cards? Yes, it still is -- I intend to port the processing core to C++ once it has stabilized. After experimenting with traits it seemed to complicated to integrate with the rest of the framework, so I dropped the idea. Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS Processing Framework
Hello everyone, the end of GSoC's first term is nearing and while I think we have made a significant progress, many things are still pending. I have tried to identify a few and compile a short list[1], to try to keep focused during the next few weeks. I'll try to create a proper timeline with (some of) those items would appreciate your comments. Anything missing? Some things more urgent than others? Of course, most of the work will revolve around the first item: Data exchange. Still no clarity on how to handle that. Regards, Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS Processing Framework
I don't know if this is relevant to the crashes you have been getting, but TraitsUI and most other Enthought Qt-oriented GUI projects use version 2 of the SIP QString and QVariant APIs: https://github.com/enthought/pyface/blob/master/pyface/qt/__init__.py This is done so they can swap between PyQt4 and PySide without hassle and to get better unicode and Python 3 support. QGIS uses Version 1 of those APIs which is fundamentally incompatible. QGIS could upgrade to version 2 but all Python plugins containing code using QString or QVariant would have to replace these calls with plain Python strings and objects---definitely a 2.0 sort of change. -Charlie Yes, that is at least part of the problem. I'll continue without traits ATM, as Paolo and Martin recommended. Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Data exchange between QGIS and SAGA [was: QGIS Processing Framework]
Hello saga developers, in case you haven't followed the development of the QGIS Processing Framework and SAGA interface, a short introduction: I was selected to implement a QGIS to SAGA interface in context of Google's Summer of Code 2011 program. The last weeks have been spent designing and implementing basic parts of a more general framework to processing modules. There is interest in interfacing at least SAGA, the Orfeo Toolbox and OSSIM to QGIS. A rough design document can be found at [1]. Note that the implementation[2, 3] differs substantially, though. One of the most important and difficult remaining parts is data exchange (raster vector). I have been studying SAGA's API [4], but am not sure how to handle it would appreciate comment from people more familiar with it. Do you think it would be easier (or cleaner) to interface SAGA's relevant data structures to QGIS' dataproviders or layer structures? For comparison, see the QGIS API docs.[5] - I/O : how will this be handled ? I'm asking this related to the recent mails with interest for providing ossim image chains in Qgis. If it must support module chaining, then there is a need for an abstraction of the i/o mechanism. is it the qgis dataproviders ? a module can take a raster/vector dataprovider as input and can output a raster/vector dataprovider ? Yes, qgis dataproviders, I think. Perhaps alternatives later. This is, IMO, one of the most dificult aspects remaining to define. I'd love to hear some thoughts from the Qgis gurus about this. Any thoughts or comments welcome. Regards, Camilo [1] https://github.com/polymeris/qgis/wiki/QGIS-Processing-Framework [2] https://github.com/polymeris/qgis/tree/master/python/processing [3] https://github.com/polymeris/qgis/tree/master/python/plugins/saga [4] http://www.saga-gis.org/saga_api_doc/html/annotated.html [5] http://doc.qgis.org/head/index.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Re: SAGA Interface for QGIS - Weekly report
I have ported the parameter system to traits, but am not sure if I am taking the right approach. Dynamically generating the module definitions and instances is problematic using traits. A more elegant way would be to create a new python type for each module (perhaps using `type()`), subclassing `HasTraits`. It seems difficult to advance from this stage of development, the last few weeks I have been writing and rewriting the same things, as understanding of the problem and requirements change. I would very much appreciate comments on how to continue: Do you think traits is the way to go? If so, can you suggest cleaner ways to implement the framework? Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS Processing Framework
On Mon, Jun 27, 2011 at 3:59 PM, Camilo Polymeris cpolyme...@gmail.com wrote: Given that there are no objections I have studied the traits docs without finding any reason against it, I'll start migration of the framework. Having trouble with that.. QGIS segfaults when I try to load any of the modules in enthought.traits, e.g.: import enthought.traits.api When running the import through pdb it seems to hang. Can someone please confirm? Thanks, Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] QGIS crashes when loading Traits from Python console. [Was: QGIS Processing Framework]
On Mon, Jun 27, 2011 at 3:59 PM, Camilo Polymeris cpolyme...@gmail.com wrote: Given that there are no objections I have studied the traits docs without finding any reason against it, I'll start migration of the framework. Having trouble with that.. QGIS segfaults when I try to load any of the modules in enthought.traits, e.g.: import enthought.traits.api When running the import through pdb it seems to hang. Can someone please confirm? Thanks, Camilo Confirmed, it crashes with Loaded symbols for /usr/lib/python2.7/dist-packages/enthought/traits/ctraits.so Reading symbols from /usr/lib/python2.7/dist-packages/enthought/traits/protocols/_speedups.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.7/dist-packages/enthought/traits/protocols/_speedups.so Core was generated by `/usr/bin/qgis.bin'. Program terminated with signal 11, Segmentation fault. #0 0x7f3bf98764c8 in ?? () from /usr/lib/python2.7/dist-packages/enthought/traits/protocols/_speedups.so traits from official deb package. All the best. -- Paolo Cavallini: http://www.faunalia.it/pc Yes. Same here. No idea what those _speedups.so could be... Any ideas? Can't continue if we don't solve this. Regards, Camilo debian, Traits v 3.0.0 Program received signal SIGSEGV, Segmentation fault. 0x7fffd22c56b4 in ?? () from /usr/lib/python2.6/dist-packages/enthought/traits/protocols/_speedups.so bt #0 0x7fffd22c56b4 in ?? () from /usr/lib/python2.6/dist-packages/enthought/traits/protocols/_speedups.so #1 0x7fffd22c7e7d in ?? () from /usr/lib/python2.6/dist-packages/enthought/traits/protocols/_speedups.so #2 0x7fffe1aeaf80 in PyEval_EvalFrameEx () from /usr/lib/libpython2.6.so.1.0 #3 0x7fffe1aeccc0 in PyEval_EvalCodeEx () from /usr/lib/libpython2.6.so.1.0 #4 0x7fffe1aeaffb in PyEval_EvalFrameEx () from /usr/lib/libpython2.6.so.1.0 #5 0x7fffe1aeccc0 in PyEval_EvalCodeEx () from /usr/lib/libpython2.6.so.1.0 #6 0x7fffe1aeaffb in PyEval_EvalFrameEx () from /usr/lib/libpython2.6.so.1.0 #7 0x7fffe1aeccc0 in PyEval_EvalCodeEx () from /usr/lib/libpython2.6.so.1.0 #8 0x7fffe1aecd92 in PyEval_EvalCode () from /usr/lib/libpython2.6.so.1.0 #9 0x7fffe1afe0d2 in PyImport_ExecCodeModuleEx () from /usr/lib/libpython2.6.so.1.0 #10 0x7fffe1b0099e in ?? () from /usr/lib/libpython2.6.so.1.0 #11 0x7fffe1b017df in ?? () from /usr/lib/libpython2.6.so.1.0 #12 0x7fffe1b01a6f in ?? () from /usr/lib/libpython2.6.so.1.0 #13 0x7fffe1b020b0 in ?? () from /usr/lib/libpython2.6.so.1.0 #14 0x7fffe1b02604 in PyImport_ImportModuleLevel () from /usr/lib/libpython2.6.so.1.0 #15 0x7fffe1ae4baf in ?? () from /usr/lib/libpython2.6.so.1.0 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS crashes when loading Traits from Python console. [Was: QGIS Processing Framework]
I can confirm the crash on Fedora 15, QGIS 1.6 and ETS 3.5. However, after installing the fresh ETS 4.0 from Github (http://code.enthought.com/source/) I can import traits.api (namespace 'enthought' has been removed in 4.0) through QGIS Python console. Same applies to openSUSE 11.4 (64-bit) with QGIS 1.7. Official RPMs seem to be available at least for openSUSE. Cheers, Joona Works for me, too. (version 4.0.1 from github) Thanks! ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Ubuntu] Re: [Qgis-user] Re: [Qgis-developer] qgis-saga-python bindings in ubuntu
The saga-qgis interface is pretty much non-functional yet. Could you specify which problems you have encountered? Are you using the faunalia version? Camilo El jun 28, 2011 12:35 p.m., Agustin Lobo alobolis...@gmail.com escribió: Johan, Problem solved by adding your repository: deb http://ppa.launchpad.net/johanvdw/sagacvs/ubuntu lucid main deb-src http://ppa.launchpad.net/johanvdw/sagacvs/ubuntu lucid main Unfortunately, this does not entirely solve the problem of the saga plugin in QGIS, but this is another story. Thanks! Agus 2011/6/28 Agustin Lobo alobolis...@gmail.com: Johan, Do not find python-saga in https://launchpad.net/~ubuntugis/+archive/ubuntugis-unstable Instead, I find now 2.0.7+dfsg-0.5~lucid , but synaptic still finds 2.05 only Thanks for taking care of ubuntu saga binaries. Agus 2011/6/28 Johan Van de Wauw johan.vandew...@gmail.com: On Thu, Jun 23, 2011 at 11:10 AM, Agustin Lobo alobolis...@gmail.com wrote: Is it possible to install the python bindings for a saga installation from binaries friom ubuntugis-unstable? I'm currently busy uploading the new versions. After uploading it will take approximately one hour to compile. Once this is done the package you are looking for is called: python-saga Also, while I do have the ubuntugis-unstable repository in the synaptic list, synaptic finds saga 2.05+dfsg-0.1~lucid while https://launchpad.net/~ubuntugis/+archive/ubuntugis-unstable lists saga 2.0.6+dfsg-0~lucid. Why? Because it was uploaded but (for some reason) did not compile. Not your fault. Thanks Agus -- Forwarded message -- From: MALIK Julien julien.ma...@c-s.fr Date: 2011/6/23 Subject: [Qgis-user] Re: [Qgis-developer] qgis-saga-python bindings in ubuntu To: cavall...@faunalia.it cavall...@faunalia.it Cc: qgis-user qgis-u...@lists.osgeo.org, qgis-developer qgis-developer@lists.osgeo.org, agustin.l...@ija.csic.es For ubuntu, you are probably looking for this : https://launchpad.net/~johanvdw Julien Quoting cavall...@faunalia.it cavall...@faunalia.it: A debian plugin is under preparation. Otherwise you'll have to build it yourself. All the best. http://faunalia.it/pc - Reply message - Da: Agustin Lobo alobolis...@gmail.com A: qgis-user qgis-u...@lists.osgeo.org, qgis-developer qgis-developer@lists.osgeo.org Oggetto: [Qgis-developer] qgis-saga-python bindings in ubuntu Data: gio, giu 23, 2011 07:04 Does anyone know if there is any way to get the required (by the qgis saga plugin) python bindings for the binary distribution of saga for debian and ubuntu? Thanks Agus ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer This message was sent using IMP, the Internet Messaging Program. ___ Qgis-user mailing list qgis-u...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user ___ UbuntuGIS mailing list ubu...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/ubuntu http://trac.osgeo.org/ubuntugis/wiki ___ 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] QGIS Processing Framework
On Tue, Jun 21, 2011 at 7:28 AM, Noli Sicad nsi...@gmail.com wrote: It seems that PyQT is probably just new. Hence, we have not heard about this, Currently, the supported GUI toolkits are wxPython and PyQt. While both toolkits funtion with Traits, integration with wxPython is currently more complete. All future development, however, will focus on supporting PyQt. I think we would mostly interact with trait's GUI abstraction, anyways. So we could start development hope that later PyQt support will improve (so that we don't depend on wxWidgets). [...] I had the same feeling, but I do not know that project. Any stronger opinions? I don't think it would be to hard to switch to traits (looks quite similar to our design), I'll wait a few days to see if someone more experienced chimes before taking a decision. There may be hidden limitations or complexities we are not considering. In the meanwhile focus on converting the module tree to MVC. Regards, Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS Processing Framework
On Tue, Jun 21, 2011 at 9:31 AM, Julien Malik julien.ma...@c-s.fr wrote: One point somewhere in this thread was about having (in the future) the framework in core, implemented in C++, with a Python binding on top of it. This would go against it, but I'm not sure now whether the C++ side is a must-have or not. All the tools listed for possible inclusion in this framework are either in Python or have Python wrapper on top of them (I was claiming for C++ support in the past, this is now history, and the OTB-Qgis glue can and will be done in Python). Same for me-- wanted to interface to SAGA with C++ first. Now I am happy I am doing it in Python. :) Don't think C++ is a requisite. Good thing about traits is, it does not depend on any GUI. Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Re: SAGA Interface for QGIS - Weekly report
This week the Framework's design saw many changes. Julien has started to experiment with interfacing it to the Orfeo Toolbox, and from the ensuing discussion the conclusions of creating a separate plugin for the framwork's gui, sort of a module manager, now called processingplugin and removing some unnecessary classes were drawn. These things were implemented. Also, a model-view interface will be used for the module list. Some bugs were also fixed. A few new parameter types introduced. (String, Boolean, Choice). The UI has imporved a bit. Apropos, no screenshot this week, but, the good news is you can see for yourself how it is coming along, since the **very experimental** plugins are now available through the faunalia.it repo[1]. Note that you have to install processingplugin for the SAGA plugin to work. Many thanks to Giuseppe Paolo for their help. Any comments welcome! Next week I hope to catch up with validators, and move the module list to model-view. As always, past reports are available at the project's wiki.[2] Regards, Camilo [1] http://www.faunalia.it/qgis/plugins.xml [2] https://github.com/polymeris/qgis/wiki/Reports ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Re: python plugin and layer properties window
On Thu, Jun 9, 2011 at 5:18 AM, Michael Pfeiffer michael.pfeif...@bd.so.ch wrote: Hi everybody, no hints for this problem? I have the same problem with the mapcomposer window. When closing the mapcomposer window I want to get the close signal or close event of the window. I need this because I want to switch of some things in the map canvas automatically which I switched on when the user clicked the Map Button in the GUI. Hello, I am not sure I understand the question correctly, but: Do none of the provided signals work for you, like QMainWindow::destroyed() or QgsComposerView::finished() perhaps? Or just QDialog::finished(int) in the case of the Layer Properties dialog? You can get a pointer to those structures through QgsAppInterface, I think. There is the activeComposers list, and, of course, the mainWindow pointer. Regards, Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS Processing Framework
On Mon, Jun 13, 2011 at 10:15 AM, MALIK Julien julien.ma...@c-s.fr wrote: Hello, Hello, Julien. You bring up some very important points. Here are some remarks : - It's good to have deleted the Library class. I had no use of it. This makes the code much more simpler. - Is the Plugin class really necessary ? It does nothing now. Maybe it's better to remove it also, so each plugin can do what he wants during the import (maybe also create a specific gui for its own general configuration). The only thing important to be a processing plugin would be to register itself to the framework during initGui() and deregister itself in unload(). I think it would be more coherent with the way Qgis manages plugins (you could more easily enable/disable one of the implementations in the plugin manager, probably better for updates too) Yes, you are correct, the processing.Plugin class does nothing -- does no harm either, but agree on removing it. - I think a lot currently happen in the constructors and during the different module imports (loading of all the modules with their description/params/etc), and it would be good to lower it down. Currently we register modules to the framework. Could we instead register one main object which can be queried for a list of available modules (their names, description, tags, docs,...), for a list of general info to keep track of its provenance (is it Saga, OTB, ..., so that the framework knows easily how to differenciate them), and can create actual ModuleInstance on demand ? The idea would be that the framework ask things to the different implementations when it needs to, and not the other way around (as it is a singleton, i think it is safer that way) Also, IMHO the details of the different parameters of a module should not be taken into account as long as we don't create an instance of this module. Also remove the arguments from the processing. Module constructor, and have e.g. saga.Module override paramters(), name(), tags(), etc, so that the relevant code only gets executed when necessary. Each plugin would then be responsible for registering/deregistering it's modules. Either passing a list or a callback to the framework. On the provenance: I just had the saga implementation add a 'saga' tag to every module. I think that's the simplest solution. It doesn't show up currently, because, every module having that tag it is deemed irrelevant by the framework. - about the gui part : should it be possible to create the specific widget for a parameter for which the framework does not provide a default ? i think so. Maybe it would make sense that each ModuleInstance can be queried for the widget, a default implementation being provided for all standard types. Even for the standard provided widgets, it could be nice to be able to simply subclass them to add our own things (not sure about this). Implement parameter.widget(value) in a subclass if you want custom widgets. That function should get called by processingplugin.Dialog.widgetByType(), if present. Haven't tried it yet, though. Open for discussion if you think this is not the best way to handle this. - is there a need for keeping 2 modules (processing and processingplugin) ? can a plugin depend on another plugin (in my otb plugin can I import processingplugin) ? if yes, putting everything in one plugin will make it more easy to distribute a version of the code (as long as it is python...). But, YOU introduced 'processingplugin'! :D I think it is a good idea to keep them both: QGIS plugins are inherently GUI-related, they have a initGui method, after all. But, the QGIS processing framework should work in a GUI agnostic way, so that it will be useful in other environments, too. Having processing for the logic processingplugin for the GUI, forces us to keep both aspects separated. Perhaps the names are too similar, confusing... rename processingplugin to processingPanel or processingGUI or something? - the panel should be more tied to the framework singleton : when a new plugin is loaded/unloaded, it should be possible to update the Panel for example (putting the gui initialization outside of the Panel constructor may help) I am not sure of what you mean: I precisely tried to separate the framework from the panel. What would be A Good Thing, I think, is reimplementing the panel with QTreeView and the framework as a ItemModel. That way the panel would get updated whenever the framework changes. What do you think? - the panel does not provide an easy way to differenciate between the different implementations (saga/otb...). Maybe a tag could be used for it, or maybe it should be given a different meaning (like the main tag). For later, you might want to add an easy way to enable/disable all the OTB/Saga/Gdal/ by just clicking on an icon ? Agree: tags. Standard tags for now, I think. If we see the need to introduce 'special tags' we can always do that later. - I/O : how will this
Re: [Qgis-developer] Fwd: SAGA Interface for QGIS - Weekly report
On Sat, Jun 4, 2011 at 9:06 PM, Nathan Woodrow madman...@gmail.com wrote: Looking good. My hope onces this is all done is to be able to rewrite all the tools in fTools to use the framework. That way eventually everything can be linked together and called in the same way. - Nathan Thanks. Any comments on the code or API? Things you would need for fTools? Regards, Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Fwd: SAGA Interface for QGIS - Weekly report
Hello, This week, I coded a GUI list of modules, sorted by tag (which in the case of SAGA are determined programmatically), plus the basics of a 'run module' dialog. I have started working on the parameter passing aspect of the framework. I also set out to handle class generation for the GUI installation of python files from cmake. Being inexperienced in cmake, this wil require further study work. Next week I intend to (as per the timeline), add GUI elements for the simplest cases of parameters and get the build system working. A screenshot, links prior reports are available through [2] Regards, Camilo [1] https://github.com/polymeris/qgis/wiki/QGIS-Processing-Framework [2] https://github.com/polymeris/qgis/wiki/Reports [3] https://github.com/polymeris/qgis ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS Processing Framework
- Even though its clear that the main objective is to have this framework well integrated in Qgis, it would be nice if it could be accessed without running Qgis, at least for the back end part. Being able to access it through a standard Python shell would be very usefull. I think it converges with Paolo's idea of having a scriptable Qgis. I will try to keep separeted what depends on QGIS-Core and what depends on QGIS-GUI. One reason to move everything UI-related to the QGis side is precisely that: so the backends will be usable in other contexts. - Having the backend accessible through a C/C++ interface would then be great , so that we can access it not only from Python, but also from other non-Python-compatible langages/applications (say Java for example, to be able to integrate it in current state of the art WPS implementations) - Being able to run each module GUI independently, outside Qgis, would be nice also. Less sure on this one... At least not the priority. Could be done, I guess, would just need a non-QGIS reimplementation of the front-end that talks to the modules through the same API. E.g. web or command-line frontend is very plausible, but would need a lot of work, of couse. For the OTB modules we have some other target applications where we would like to push our modules. I'm now seeing things in a much wider scope thanks to this discussion, and I'm telling myself we should handle things one step above : it is probably the Qgis framework that we will want to wrap in other applications. As already said, using as much manpower as possible from the open source community is important so that it becomes a success story. Feedback from other application's developers that could wrap this frontend would be appreciated, to see if the current incarnation of the design fits their needs. Of course, the primary goal is to make it work for QGIS, but flexibility is a good thing, IMO. The design document is, as always, here: https://github.com/polymeris/qgis/wiki/QGIS-Processing-Framework And I have started writing Python stubs, here: https://github.com/polymeris/qgis/tree/master/python/processing Please, correct or comment. Regards, Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS Processing Framework
On Fri, Apr 29, 2011 at 7:31 AM, Julien Malik julien.ma...@c-s.fr wrote: Hi Martin ! The point is actually not to provide every possible parameter type in the framework. IMO we should have a base parameter type with several common types such as integer, string, vector layer, enumeration. Such types are used widely and QGIS would come with default edit widgets for them. Then, each library might require some additional parameter types that might also require special editing widgets. The plugin implementing support for such library will provide these types and editing widgets, however they will stay opaque for QGIS. So in the result QGIS will just know there is a parameter and it will know what widget to show in the form, nothing more. Of course such custom types would not be usable across various libraries, but that fine. OK, it seems a good balance. Yes. Sounds good. Is this good time to begin laying down this list somewhere ? I am still trying to keep this thing updated with the insights from this thread, at least, things I think there is somewhat of a consensus. https://github.com/polymeris/qgis/wiki/QGIS-Processing-Framework Anyone is welcome to edit the page. Any idea about how to handle the 'non Qgis supported' parameters types for the Python API ? Keep them opaque. Implementation responsible for supplying python functions to handle them, if desired. . Here QGIS would provide default GUI for a module based on the description, with the possibility for the developer to improve the basic behavior using Qt signals and slots for a better user experience. Are signals and slots sufficient ? Maybe being able to provide a subclass of the default Qgis supported widgets would be cool ? Both, but in general signals should be enough, I think. Most parameters are enumerations, numeric values, etc. after all. Therefore I tend to think about the whole procesing framework in two levels: 1. backend - similar to WPS: an interface for description of modules, querying the modules and running them 2. gui - built on top of the backend, enhancing the usability and experience for the user: Agreed. GUI on the QGIS side, unless necessary. Maybe doing band selection and region of interest selection on input rasters is general enough to be supported by the framework I was calling the later a Rect parameter. This is a list of parameters I think could be supported by the framework (much more thought can be put into it, this is just a starting point): Raster = OTB Image = SAGA Grid Vector = OTB vector data = SAGA Shape URL = OTB File name = OTB Directory name = SAGA FilePath String = OTB String = SAGA String = SAGA Text = default for everything not covered Boolean = OTB Boolean = SAGA Bool Number = OTB Numeric = OTB Radius = SAGA Int = SAGA Double Enumeration = OTB Choice = SAGA Choice Tuple = OTB Origin = OTB Size = SAGA Range Rect = OTB Region = SAGA Rect Point = OTB Point/Index = SAGA Point List = OTB Parameter group = SAGA Grid List, Shapes_List, etc. (from https://github.com/polymeris/qgis/wiki/List-of-parameters) I completely agree that many times the dependencies between the parameters are far too complex to be modelled in a declarative way. I hope my answer above clarifies this: you as a developer of the orthorectification module would be allowed to watch for changes in the form (using Qt signals) and update other parameters - or do whatever you want. Yes, exactly! I have updated my mock-up API to reflect this. Yes it's more clear. We should consider not only being able to update the parameters values, but also the GUI part (changing some widget settings, eventually even changing the widget class somehow ?). You could actually even remove parameters and add others, change the state of the module, etc. Everything that is possible in other contexts. Then fire a signal to tell the framework to re-read what has changed. If I'm not wrong, SAGA has this also (it's called Node). Camilo ? You are right. Also we want to have parameters shown only depending on a combobox value, for example. So a choice parameter value is declared with both what to show in the combobox, and an associated parameter group. This would be implemented like this: Upon change of combobox value the implementation is signaled and can change its parameters. The implementation then signals the framework to reread the parameter list and rebuild the GUI accordingly. Do you agree with such an approach? If you have a good idea to model that in a simpler way, I'll take it. Flat parameter model, but the GUI can rearrange/show/hide them dynamically ? See above. I'm OK with the idea of limiting this to 2 levels max for example (no groups inside groups). If we implement parameter groups, there is no reason to limit the number of levels, IMO, except as a convention to keep the GUI and Python API more or less usable. Regards, Camilo.
Re: [Qgis-developer] QGIS Processing Framework
Well, you're not alone :) Paolo is right! Yes, I have noted there is a great deal of interest in this project! Thanks for all the support, Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS Processing Framework
Thanks, Martin, for your well-thought-out response! https://github.com/polymeris/qgis/wiki/QGIS-Processing-Framework Would that more or less fit what you have in mind? Please comment/criticize. The discussion was not going into implementation details, we were mostly collecting the ideas how the things should work. Yes. I wrote that API description not so much thinking it would be the actual interface, but as a way of reflecting on what issues could arise and how to solve them. Framework implementation: as you write in the proposal, ideally it should be implemented in C++ with Python bindings. I would suggest you to start the implementation in Python and skip C++ coding at least at the beginning. Ok. I think that's a good idea. I'll start with Python and later see when (and if) migration to C++ makes sense. Forms/Parameters: I would start with with generic input fields (line edit / spin box) for integers, floats, strings that can be constrained with a range (numbers) or regular expressions (strings) - easily achieved with QValidator classes. Then some custom widgets can be added for better handling of some types: layer selector, enumeration etc. The framework may be extensible so that if a library often uses a particular custom type, the plugin integrating the library could add a custom widget for it. Agreed. In general I think it may be a good idea to keep the GUI stuff in QGIS and have the implementations only care about interface to the various systems. BTW, in the document linked above I use the term library for a collection of modules, as opposed to implementation for a given interface to a system (GRASS, SAGA, OTB). There may be more than one library per implementation. Just to clarify-- terminology can be changed, of course. I don't even know if the title (Processing Framework) is accurate. Perhaps Analysis is a better name. Advanced parameters: some modules may allow users set lots of parameters. Although this is handy, many times the default values work well and only few basic parameters are changed regularly. It should be possible to mark some parameters as advanced and they would be hidden by default, they would show up after clicking a checkbox or a button. For example, when creating a vector buffer, the distance would be a basic parameter while the number of segments per quadrant would be advanced parameter. Good point. SAGA, as far as I know, does not provide information on which parameters are considered basic and which are advanced. Perhaps a list of parameters considered advanced can be included with the plugin. Not very elegant, because it would be out-of-sync with SAGA, but practical. Categorization: currently we are starting to face some trouble with organization of plugins and the modules they provide. We thought about creating fixed categories as in GRASS (e.g. Raster, Vector, Database) where the modules would be placed. We also considered custom categories and subcategories. The general problem with categories is that many modules do not suit them well if they are not coming from a well-organized library such as grass, saga or otb. The conclusion that I recall from the discussion at hackfest is that tagging is probably the only way to go: each module could have several tags assigned to it, then the list of modules would be a tree with top level items containing tags and modules would be shown inside these tags. Bigger libraries requiring deeper hierarchy might come with hierarchical tags like SAGA/Grid - Tools. The names of tags will be left for developers' creativity. This list of processing modules should later get some advanced functionality like searching, favourite modules or even attaching most used modules on a toolbar, but that is something for the future, we are not expecting you to do that during the summer :-) A simple tree listing tags and modules assigned to them will suffice. Again, SAGA provides no tag information. It would have to be generated programatically from library/module name description or provided in a list. Any thoughts on the GUI for that tree? More like SAGA's module tree or more like GIMP's filter menu? I don't think the search/filter/favorites/frequently used part is very hard.. but still, I will keep things simple. Feedback: many modules are able to return some feedback - either in the form of a progress to indicate how long the process will take - or to return some messages that will be shown to user. Support for cancelling a running module would be helpful too, but not really necessary right now. Related topics: * Interactive modules. I had this more or less resolved for SAGA (I think), but designing a more generic solution could prove difficult. * Pushing pipelining to the implementation: Potentially more efficient, but less generic. * Parameter value serialization: load and save presets to file * Undo redo ability. I am eager to see what the OTB team has come up with. I am not very
Re: [Qgis-developer] QGIS Processing Framework
On Wed, Apr 27, 2011 at 4:58 PM, Mayeul Kauffmann mayeul.kauffm...@free.fr wrote: Le mercredi 27 avril 2011 à 20:46 +0200, Paolo Cavallini a écrit : Il giorno mer, 27/04/2011 alle 12.00 -0400, Camilo Polymeris ha scritto: Good point. SAGA, as far as I know, does not provide information on which parameters are considered basic and which are advanced. Perhaps a list of parameters considered advanced can be included with the plugin. Not very elegant, because it would be out-of-sync with SAGA, but practical. It is the same approach used in GRASS: in fact, it is better (even if not elegant, I agree) to be able to decide which options should be exposed as default, and which ones as advanced). In fact it would be also good to add a general option user/power user; in the first case only default options will be exposed, in the second the full options. +1 for the concept of a user/power user checkbox. You could call it Always show advanced options which is more neutral (does not make any judgement on the user) and describes exactly what it does. Agreed. Would be great to have an Advanced options checkbox on each window anyway, to be able to switch their visibility on a case by case basis. If it is a check-box, tab or toggle button would have to be considered. I am under the impression that the latter is more common, but I don't know the rationale behind. In addition, where relevant (functions that use command-line tools or have command-line tools equivalent) and in advanced mode only, it would be great to have the GUI generate the command line corresponding to the options chosen in the GUI; the GUI would show this command line and let the user edit it (or run it as it is). There are many advantages: - the user knows exactly what is going to be executed; advanced QGIS users will be able to use the GUI but benefit from existing help targeted at the command-line users; debugging, sharing questions and ideas in a forum or saving/automating a frequent task is facilitated Very good idea. It could even work both ways, and use that for saving/loading parameter presets. - you do not have to put very rare options in the GUI (power users can still add the options here when they need it, which should be rare). The GUI would be auto-generated, so adding parameters means no extra programming effort. Not putting things on the GUI would, thus, be a UI design decision, to keep it from being cluttered. Wow. This is getting more and more ambitious. Will have to see what fits in only 1 summer :) Thanks, Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Summer of Code GSoC 2011 - QGIS Accepted Projects
Best of luck to all who weren't accepted this year... there are many Summers of Code to come -- but you can take the opportunity to get involved in your projects-of-choice NOW-- I wouldn't be surprised if some of you delivered better code and more contributions to QGIS than those of us who were selected. I am afraid, GSoC participation will always be an imperfect choice, as it is limited to only a few participants, while actually you are all welcome to contribute and take part of this project. Regards, Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] pyQT combo box QGIS plug-in signal argumentquestion
It's not very elegant, but you could use QObject.sender(), see http://doc.qt.nokia.com/4.7/qobject.html#sender Regards, Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Re: some notes on building SAGA and its python bindings under Windows (to test and use Qgis-SAGA plugin)
On Wed, Apr 13, 2011 at 5:21 AM, G. Allegri gioha...@gmail.com wrote: As soon as I find a minute for it, I will publish my experience on a wiki page (where? I will see...). Add it to the same wiki at github if you want. On an unrelated note: Do you know if a particular python version is defined as target for QGIS plugins? I believe I read 2.3 somewhere, but can't find the source. Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Re: some notes on building SAGA and its python bindings under Windows (to test and use Qgis-SAGA plugin)
Hi Camilo. Could you please start a wiki page, accumulating the info so far? Thanks. Sure. I had stated to keep links (to APIs, forum threads, etc.) and some notes here: http://github.com/polymeris/qgis/wiki I can move some of that to the QGIS wiki and add the info I find in the threads. Is that what you mean? If so, an admin would have to create an account for me. Else, I can expand the above wiki. Regards, Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Auto-complete QGIS lib under WING IDE
But I don’t any auto-completion for the QGIS libraries. Wing doc explain to use a *.pi file but I can’t translate core.pyd or gui.pyd to core.pi or gui.pi … pi files or Python Interface files describe the interface of binary only python modules. Wing ships with a script that extracts pi files from pyd: generate_pi.py Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Re: some notes on building SAGA and its python bindings under Windows (to test and use Qgis-SAGA plugin)
Just for the record, under linux I had to pass the following options to the configure script: --enable-python --enable-unicode The first is to build the python modules (could be done by hand, too). The second forces saga to use unicode, so it matches debian's wx packages. No problems otherwise, (so far) Regards, Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] qgis orfeo GSoC
Hello Rashad, I don't wish to be rude, and your proposal does sound interesting. Still, I find it strange that you copied such a great part of my own proposal [1] verbatim, including the project plan: list of deliverables and timeline (down to the dates). I understand you may be under time pressure to submit a proposal quickly, but suggest you study those aspects of the proposal again, and update with your own. My plan may not apply exactly to your project. Regards, Camilo [1] http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/polymeris/1001 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] qgis orfeo GSoC
On Thu, Apr 7, 2011 at 11:38 PM, Mohammed Rashad mohammedrasha...@gmail.com wrote: sorry sorry sorry I am using net from outside so to do not miss deadline i did so I am at home now and changing the timeline sorry again No problem. I understand -- and as I said, your project seems very interesting. Good luck. Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] add form elements dynamically - qgis python plugin
I would try any of the following: self.dlg.comboBoxNew = QtGui.QComboBox() - set the Combobox's parent to the dialog or layout: self.dlg.comboBoxNew = QtGui.QComboBox(self.dlg) self.dlg.comboBoxNew.setObjectName(comboBox) self.dlg.comboBoxNew.setItemText(1, QtGui.QApplication.translate(Form, bw, None, QtGui.QApplication.UnicodeUTF8)) - add the combobox to the dialog's layout after that: self.dlg.layout().addWidget(self.dlg.comboBoxNew) Does that help? Regards, Camilo ___ 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
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
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
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
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] A new public git repository of qgis trunk, with auto daily update
What about: https://github.com/qgis/qgis Is that repo official/maintained? It was updated a month ago. I forked from that, should I rather switch to Francesco's, then? Regards Camilo ___ 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
[Qgis-developer] SAGA Interface
Hello everyone, I am considering implementing this idea: http://www.qgis.org/wiki/SAGA_Toolbox_for_QGIS I use SAGA often and would like to see a modern interface to it. I have no experience with the QGIS code, though. The last few days I have been coding a little, just to get a feeling of how difficult that integration would be and get to know the QGIS code. So far the plugin only fumbles a little with qguis' GUI and loads SAGA libraries. The next step will be to display a list of modules and their parameters. I'd like to do this in context of GSoC 2011, for that purpose, and if you're still interested, I'll submit a proposal during the week. I started using SAGAs Pyhon interface, which I am more familiar with, but switched to C++ now. I think the whole C++ - Python - Swig - C++ route is too complicated. C++ to C++ is just cleaner. What is your opinion? Do you believe that it is feasible to do the whole implementation during 1 GSoC? Else, what aspects should I focus on? (And what could be left to post-GSoc) GUI: Any ideas? So far I think I'll just clone SAGA's. Distribution: Would SAGA's modules and/or the SAGA API be distributed with QGIS? Finally, which do you think will be greatest hurdles or pitfalls I would face in this project? Any particularities of qgis I should be aware of? (Data formats?) Thanks for your comments, Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
