Re: [QGIS-Developer] [GRASS-dev] External providers in QGIS

> > I am giving up on this contribution as it seems impossible to get small > changes like this. > Thanks for all your time. The change is not small. It might have important consequences in other parts of Processing. I gave the PR a +1, probably without having analyzed it in detail. Alex and

Re: [QGIS-Developer] [GRASS-dev] External providers in QGIS

> > OTB's proposed solution was that plugin or provider algorithm if activated > can find otb installation. If not found, there is code which will download > and install otb packages and configure it for users. > I still don't see why this cannot be done if OTB provider is a separate plugin.

Re: [QGIS-Developer] Issues with custom forms with Python (in both QGIS 2 and QGIS 3)

gt; > In the image above it's a button on the right of the Provide ui-file and > on the left of the "Show form on add feature... > > Regards, > Tudor > > > On Tuesday, February 6, 2018, 9:33:27 AM GMT+2, Victor Olaya < > vola...@gmail.com> wrote: > >

Re: [QGIS-Developer] External providers in QGIS

ponsibility of providers > isn't good either. > > This way, each team takes part and result in better collaboration and > contribution. > As time goes, generic descriptor provider gets better and stronger. > Toolboxes are free to add, remove, modify their applications and users from > bo

Re: [QGIS-Developer] External providers in QGIS

I dont see the advantage in having providers in core. And if there is an advantage, it's clearly not in how easy it is going to be to maintain the plugin. If the people responsible of a given backend (like OTB) are going to maintain it (which makes sense), why putting it in core where they don't

[QGIS-Developer] Issues with custom forms with Python (in both QGIS 2 and QGIS 3)

Hi I am writing documentation about custom forms, but I am encountering some problems. In the case of QGIS 2, it seems that there is no way of avoiding the dialog to be closed when the OK button is clicked. I read this blog post

Re: [QGIS-Developer] Keeping OTB algorithm in qgis processing

ancies > is exhausting, ongoing work. It's much more sensible for someone > intimately familiar with those libraries to maintain a plugin which > closely tracks the library development and follow best-practice API > use for that library. > > > Nyall > > > >> &g

Re: [QGIS-Developer] Get rid of Processing scripts in favour of plain alogrithms

follow Processing's history! C++ (SAGA) -> Java > (Sextante) -> Python (Processing) -> C++ (QGIS 3.0) :D > > All the best, > Giovanni > > > > 2018-01-31 8:33 GMT+01:00 Victor Olaya <vola...@gmail.com>: >> >> I like the idea, but i dont thin

Re: [QGIS-Developer] Get rid of Processing scripts in favour of plain alogrithms

I like the idea, but i dont think it will mean less code, specially for defining the parameters and outputs. Why not keeping it for those that want to use it this way? Before removing this (in case it's decided to do so), two things to notice: -- There were algorithms (built-in ones) defined

Re: [QGIS-Developer] QGIS3 - Processing : display the HTML outputs

No sure why it was decided to have it like that...but I also think that keepping it open by default is a better option. +1 from me. 2018-01-11 9:12 GMT+01:00 Anita Graser : > > > On Thu, Jan 11, 2018 at 9:06 AM, Andreas Neumann > wrote: >> >> I agree. I

Re: [QGIS-Developer] What to do with QgsTransectSample for 3.0?

I would advice to go with 1 It's not likely anyone will use this class, so it's the safest option, IMHO 2017-08-26 15:15 GMT+02:00 Nyall Dawson : > Hi all, > > I've just been doing some cleanups on the analysis lib - see > https://github.com/qgis/QGIS/pull/5078, and I'm

Re: [QGIS-Developer] Deploy plugins directly from github

I wrote this long time ago... https://github.com/volaya/github-updater I guess it might be helpful for you Cheers 2017-07-20 16:52 GMT+02:00 Olivier Dalang : > Dear List, > > Using QGIS 2.18, I'm trying to find a way to deploy plugins directly from > github using the

Re: [QGIS-Developer] Backporting support for relative SVG paths in project files

gt; On Thu, Jun 22, 2017 at 8:51 AM, Victor Olaya <vola...@gmail.com> wrote: >> Hi all, >> >> I would like to know your opinion about backporting the support for >> relative paths for marker files in project files to 2.18. It's an >> interesting feature that would be

[QGIS-Developer] Backporting support for relative SVG paths in project files

Hi all, I would like to know your opinion about backporting the support for relative paths for marker files in project files to 2.18. It's an interesting feature that would be good to have without having to depend on QGIS 3. Not sure if it is supposed to be working in 2.18 (It is not, at the

Re: [QGIS-Developer] OTB 6 and Processing

to orfeotoolbox. this is the official github account and > all devs have access to it. > > https://github.com/orfeotoolbox > > > > On Wed, May 17, 2017 at 12:04 PM, Victor Olaya <vola...@gmail.com> wrote: >> >> I agree 100% on what Alex said. >> >> Rashad, i

Re: [QGIS-Developer] OTB 6 and Processing

I agree 100% on what Alex said. Rashad, instead of adding your user, can I completely move the ownership to you or to another account that is managed by the OTB team? 2017-05-17 11:18 GMT+02:00 Alexander Bruy : > Hi Rashad, > > 2017-05-16 11:46 GMT+03:00 Rashad Kanavath

Re: [QGIS-Developer] OTB 6 and Processing

Hi The repo with the plugin already extracted and prepared is in here https://github.com/volaya/qgis-otb-plugin IT hasn't been published in the plugin repo, though. I think the OTB team was ready to take ownership, so if anyone tells me the user name or group that will accept it, i will

Re: [Qgis-developer] Basic Processing plugin questions

mmm, it should accept a list. That should be fixed, then 2017-04-05 15:02 GMT+02:00 Tom Chadwin : > volaya wrote >>> 2. Can a Processing plugin take *any* layer, rather than having to choose >>> between raster and vector? >> >> No, not at the moment. The multiple input

Re: [Qgis-developer] Basic Processing plugin questions

>> How about outputting nothing at all (in a Processing context, I mean)? I >> presume that is also acceptable? Or is the best approach in such a case to >> output the inputs, as it were? Depends on the algorithm. If the algorithm modifies a layer, it is a good idea to output that same layer, so

Re: [Qgis-developer] Basic Processing plugin questions

> > 1. Can a Processing plugin only take a single layer as input, or can it take > more? It can take several one-layer parameters (so, in the end, there is a fixed number of them), or take a multiple-layer parameter, which is a single parameter but the user can select a list with an undetermined

Re: [Qgis-developer] Processing GUI integration

I think that if the only way to show the toolbox is going to be enabling it in the "Panel" menu, that is going to be very confusing... The history can be integrated with the QGIS log maybe The commander, we should get rid of it... 2017-03-30 9:05 GMT+02:00 Paolo Cavallini

Re: [Qgis-developer] Moving Processing options?

+1. I like the idea, and I hnk that, if it is possible to add options from plugins in the settings dialog, it should be mandatory for plugins to do so, for the sake of homogeneity, instead of creating their own. 2017-02-20 10:16 GMT+01:00 Matthias Kuhn : > I once did that for

Re: [Qgis-developer] Processing algs & plugins... should we actively pull into master?

> > > One thing I am concerned about is that we guarantee some stability in the > behavior of processing. While it is true that strictly speaking new > algorithms do not represent API extensions / additions, in some level I > think they do since anyone using Python + Processing will be vulnerable

Re: [Qgis-developer] Processing algs & plugins... should we actively pull into master?

Very interesting question... IMHO, all plugins that include processing algorithms like that (just one of them or a few of them, using only native code), we should ask developers to put the code in the central QGIS repo, and then work on that through PRs. It makes more sense. In the case of a

Re: [Qgis-developer] OTB and LiDAR tools as separate plugins

Martin That might be my fault. I mentioned that, by having the LiDAR tools provider as a separate plugin, that allows to ship the tools with it (not with QGIS, but with the plugin itself, which you will manage and release whenever you want). Of course, you can still provide the downloads from

Re: [Qgis-developer] OTB and LiDAR tools as separate plugins

2017-01-30 19:00 GMT+01:00 Paolo Cavallini <cavall...@faunalia.it>: > Il 30/01/2017 14:27, Victor Olaya ha scritto: > >> If you have any comment, please let us know. > > Thanks Victor. I think this is a good improvement, giving OTB and > LASTools more flexibility to

[Qgis-developer] OTB and LiDAR tools as separate plugins

Hi all, I have set up the OTB and LiDAR tools Processing provider as separate plugins, each of them in its own repo. The idea is to have those providers that require 3rd party apps outside of the core Processing, so they can be installed separately and managed independently. Alex Bruy already did

Re: [Qgis-developer] [Processing] how to handle selections

Bernhard Ströbl <bernhard.stro...@jena.de>: > Hi Victor, > > what do you think about enhancing processing's vector.features with an > additional optional flag that returns the selection no matter if the option > is set or not? > > Bernhard > > > Am 19.01.2017 um 10

Re: [Qgis-developer] [Processing] how to handle selections

Good catch I fixed it and now it uses the selected features, regardless of the config parameter. The change is in 2.18 and master branches Thanks! 2017-01-18 10:44 GMT+01:00 Bernhard Ströbl : > Hi all, > processing sports the "Save selected features" algorithm. However

Re: [Qgis-developer] should core plugins not be available in plugin manager?

2016-12-13 10:10 GMT+01:00 Nathan Woodrow : > IMO anything core is no longer a plugin, processing included. We don't have > these options for stuff like Python console etc so it doesn't make sense to > have it for the rest. > +1. Plugins should be "extra" things. Even if

Re: [Qgis-developer] should core plugins not be available in plugin manager?

Nyall, I agree on your approach. Not all core plugins are the same. I guess I didn't want to say "Hey, Processing has to be always enabled!" :-) But yes, Processing is a particular case of a plugin, since other plugins depend on it, and now it replaces ftools, so maybe it makes sense to keep it

Re: [Qgis-developer] should core plugins not be available in plugin manager?

> > Only issue I see (and the reason I disable processing sometimes) is the > brokeness of some providers when I mix and match versions of QGIS, or run > older (compiled) versions of QGIS. A good reason to have providers as independent plugins, as I proposed in another email :-) You should be

[Qgis-developer] should core plugins not be available in plugin manager?

Hi This has been discussed in the past, but i think no decision was taken, so I want to bring back the discussion. I think that core plugins should not be visible in the plugin manager, and users should not be able to disable them. If they are core, they should be active (the menus and buttons

Re: [Qgis-developer] Processing tool log tab doesn't render HTML

It should be already fixed since a couple of days ago :-) 2016-12-09 18:55 GMT+01:00 Anita Graser : > Hi, > > The log tab of Processing tools in 2.18 does not render HTML and instead > prints the raw HTML source which makes the log pretty hard to read. > > Having this issue on

Re: [Qgis-developer] Processing NG/V2 - brainstorming

Hi, sorry for the late reply. Comments inline > > I've recently been informally chatting about possible enhancements to > processing with a few QGIS team members, and I thought it'd be worth > starting a public brainstorm about these ideas. Great to see people thinking about how to improve

Re: [Qgis-developer] Proposal: Having all Processing providers as independent components

>> This would have some advantages. Providers would be better organized, > > Can you elaborate on this? Is it just better organised because they > would be in separate repos? > Yes, mainly because of that, since all provider would be treated equal. Now the providers that are in core seem to be

Re: [Qgis-developer] Proposal: Having all Processing providers as independent components

>> Slightly off topic, but I'm not sure (yet) if we should port the >> actual algorithms themselves to c++. For my purposes (Matthias might >> disagree here) it would be sufficient to allow algorithms to be fully >> created in c++ only if required. Otherwise, I quite like having the >> algorithms

Re: [Qgis-developer] Proposal: Having all Processing providers as independent components

> Hi Victor, > about this, we need to think of upgrading process so that a user raising > QGIS version will have no choice but to also upgrade the locally installed > stuff (providers, algs, ..) to avoid version conflicts. We should probably > then have some metadata with min and max processing

[Qgis-developer] Proposal: Having all Processing providers as independent components

Hi all Before writing a QEP, I would like to discuss quickly here one idea about Processing, that I think could be interesting and feasible for 3.0 Currently, Processing has some “core” providers (those that are part of the Processing code itself and are installed with QGIS), ranging from basic

Re: [Qgis-developer] Add virtual layer equivalent in Processing

l.com>: > Victor, > > I was looking into this; it'd be nice for the "build vector layer" algorithm > would support/show geometryless layers in the parametermultiinput panel. > AFAIK, geometryless layers aren't (yet? :) ) supported by the > parametermultiinput. > >

Re: [Qgis-developer] Task Manager has landed!

Nice! Definitely, a major step ahead, and will be very important for making Processing more responsive thanks for your great work! 2016-12-05 9:04 GMT+01:00 Nyall Dawson : > Hi all, > > Thanks to tons of valuable feedback from the QGIS community and the > generous

Re: [Qgis-developer] Add virtual layer equivalent in Processing

No, there is no such functionality AFAIK, but it should be easy to add, i think Can you open a feature request? Also, the execute SQL algorithm can be modified to accept non-spatial tables. That makes sense to me Cheers 2016-12-04 22:28 GMT+01:00 Anita Graser : > Hi, > >

Re: [Qgis-developer] how to turn my plugin into a processing subplugin

If you convert your plugin functionality into Processing scripts, then it's very easy to distribute them, no need create a plugin manually and add them to it. Just create your scripts and make sure they are available in the toolbox. Then, in the "Scripts" group of the toolbox, you will find a

[Qgis-developer] issue in exported SLD for categories symbology

Hi It seems that there is an issue with SLD exports. When exporting categorical symbology in which a default value is defined (for all values not matching any of the categories) a rule-based symbology is created. However, the default category has no ELSE in it (as it should), and the default

Re: [Qgis-developer] Processing: removing support for GRASS6?

I want to add a calculator in processing that is based on QGIS classes, so is a native one, like the current raster calculator, but in processing. I hope that allows us to get rid of all the others, since it is very confusing and error prone. A good calculator that can do everything should be able

Re: [Qgis-developer] Processing takes a very long time to close the Options popup

is that on master? I detected that and found out that the grass icon, being a SVG, was causing that delay, since it was loaded hundreds of times. Replacing how it got loaded seemed to fix the issue, but apparently not in all machines, so there might be more than that 2016-10-26 16:20

Re: [Qgis-developer] Processing: removing support for GRASS6?

+1 from me 2016-10-26 16:24 GMT+02:00 Paolo Cavallini : > Hi all, > I think removing support for GRASS6 makes sense at least for QGIS 3. > This will reduce confusion among users, and will remove some bugs. > Anything against it? > All the best. > -- > Paolo Cavallini -

Re: [Qgis-developer] Processing r.mapcalc: unclear syntax

mmm, but Paolo's call already contains dtm*2, not dtm2. That's why i said that it looked correct to me. 2016-10-23 7:46 GMT+02:00 Paolo Cavallini : > Il 23/10/2016 07:44, Paolo Cavallini ha scritto: > >> thanks for the clarification. Description improved in: >>

Re: [Qgis-developer] [processing] OGR imports full of "None" strings, lately

" algorithm). > > Am I doing something wrong? Should I fix/adjust/add something to OGR > algorithms? > > Regards, > > Germán > > -- > [1] https://github.com/qgis/QGIS/commit/61a10df45283a47782bf49ac62f9c5 > e5f9b27b21#commitcomment-19464285 > > > 20

Re: [Qgis-developer] [processing] OGR imports full of "None" strings, lately

Yes, they should. I will take care of that 2016-10-18 17:48 GMT+02:00 Sandro Santilli <s...@kbt.io>: > On Tue, Oct 18, 2016 at 05:44:43PM +0200, Victor Olaya wrote: >> I just made this fix, which should solve those issues >> >> https://

Re: [Qgis-developer] [processing] OGR imports full of "None" strings, lately

I just made this fix, which should solve those issues https://github.com/qgis/QGIS/commit/d7bd5dc50705eec3f37ef82fc819b5bc47cce0f0 Let me know if we need to do something else. 2016-10-18 17:40 GMT+02:00 Sandro Santilli : > German, I think the best way would be to: > > 1) File a

Re: [Qgis-developer] [processing] OGR imports full of "None" strings, lately

> > It sounds like having getParamaterValue() always return a string > (possibly empty) would reduce regression probabilities. > > Or do you think it's important to distinguish between empty string > and None ? > sounds safe to me. And it would be nicer to make that distinction, but i think it is

Re: [Qgis-developer] [processing] OGR imports full of "None" strings, lately

I made a fix to the check that verifies if a string parameter is left blank or not. Before, it just checked that it was None, so empty strings where considered valid values. However, an empty string should be considered a null one (mainly, to raise an exception if that is used for a parameter that

Re: [Qgis-developer] processing and libpq

Yes, I have made a few fixes lately, and they are in master_2. I have to spend sometime now porting them to master and 2.14 if they apply Don't worry, i will take care of that later today Cheers 2016-10-17 11:15 GMT+02:00 Sandro Santilli : > Hi Victor, > I noticed you merged my PR

Re: [Qgis-developer] QGIS T-shirts designs for helping the QGIS project.

Awesome. The Supeman-like design is really cool :-) Great job! 2016-10-16 0:13 GMT+02:00 Alexandre Neto : > Hi! > > As a try to help QGIS project financially, I have created two designs > inspired in QGIS. You can turn those into T-shrts, hoodies, stickers, mugs, > etc...

Re: [Qgis-developer] About my plugins ...

We all know that the mechanism is not perfect and the catalog of plugins could be handled better, but I dont think that such a decision on you side helps improving it. A large (very large) part of user will never ever go to github and install a plugin manually, which means that, for them, now

Re: [Qgis-developer] gdalwarp fails, Save as... reprojected works

If the parameter is not needed, it should be optional. If anyone can confirm that, I will make it optional. Cheers 2016-10-09 23:05 GMT+02:00 Giovanni Manghi : >> Hi all, >> reprojecting a raster from 4326 to 3857 through Save as... menu works, >> whereas the same

Re: [Qgis-developer] Multiple Fields in R-Processing

ah, ok, that might be it can you check the temporary R file that is created when running the algorithm? that should tell you how the parameter is pased to R, since that is an R script You should find it in ~/.qgis2/processing regards 2016-10-01 18:21 GMT+02:00 matteo

Re: [Qgis-developer] Multiple Fields in R-Processing

mmm, it is working for me this works fine ##layer=vector ##fields=multiple field layer print fields Notice that it is "multiple field", all in lower case. You example says "multiple Field", which is wrong. Maybe is that? 2016-09-30 10:19 GMT+02:00 matteo : > Hi

Re: [Qgis-developer] Using Processing in standalone PYQGIS scripts

; layers on creation. Processing also couldn't find the layers until I >> added them to the QgsMapLayerRegistry instance, which I think means >> when I instantiate the QgsApplication in the standalone script I need >> to pass True instead of False for it to use the GUI?

Re: [Qgis-developer] Using Processing in standalone PYQGIS scripts

looks like the docs are outdated and the way to call the algorithm is now different ALGORITHM: Select by location INPUT INTERSECT PREDICATE PRECISION METHOD OUTPUT The PRECISION parameter is not documented in the help file. Hope this helps 2016-09-29 22:39

Re: [Qgis-developer] Multiple Fields in R-Processing

Sorry for the late reply The value of the multiple flieds is a string with field names separated by semicolons so, to get a list of them: fields = multiple_fields.split(";") Not sure this is what you need...maybe I am not understanding the question 2016-09-22 15:44 GMT+02:00 matteo

Re: [Qgis-developer] Peth to OTB for Processing

depends on the OS, if i remember right. In linux, i think that there isno auto-config for any provider 2016-09-23 13:31 GMT+02:00 Paolo Cavallini : > Hi all, > I thought the configuration for OTB path has been made automatic. > However I just tried, got an error, added the

Re: [Qgis-developer] Multiple Fields in R-Processing

Matteo For the multiple field you dont supply the fields or options. It takes them from the parent layer and you can select several, instead of one, as the PArameterTableField does Hope this helps 2016-09-22 14:48 GMT+02:00 matteo : > Hi guys, > > I have a small problem

Re: [Qgis-developer] Processing C++ algorithms

Not sure if it's the same...but Alex Bruy and me are thinking about wrapping core C++ plugins with Processing (mainly the heatmap/terrain analysis/interpolation plugins). So if you have something new in the form of a C++, you can also wrap it with Processing Or what you mean is that you require

Re: [Qgis-developer] About Processing documentation

The documentation for algorithms should still be in the QGIS-Documentation repo, right? Actually, I was thinking more about the usage documentation and the dev documentation, so the one that describes Processing itself, not the algorithms. But, of course, algorithm docs are also important

[Qgis-developer] About Processing documentation

Hi all There was some discussion about the Processing documentation in another thread, mainly about the one targeted at developers. I was thinking about spending some time improving/updating the documentation, both for users and devs, and most likely Alex Neto will have some time as well to help

Re: [Qgis-developer] QGIS 3 plugins - require implementation as processing algs?

> > What about improving processing's docstrings with more detail and then > including them in the QGIS docs site as Sphinx docs? > I can volunteer to help out with writing some of these docstrings, if > needed. > I will be happy to work on this as well. Notice that, however, developing a

Re: [Qgis-developer] QGIS 3 plugins - require implementation as processing algs?

> > What (I think) makes a distinction between a plugin and a processing > one, is that a plugin offers a complex interaction with the user (so gui > interaction) , while in processing the algorithm is the actual center of > gravity. > But maybe I'm wrong in this analysis. Looking at my own

Re: [Qgis-developer] QGIS 3 plugins - require implementation as processing algs?

aster/python/plugins/processing/algs/exampleprovider [3] http://docs.qgis.org/testing/en/docs/pyqgis_developer_cookbook/processing.html 2016-09-12 7:02 GMT+02:00 Vincent Picavet (ml) <vincent...@oslandia.com>: > Hello, > > On 12/09/2016 06:51, Victor Olaya wrote: >> +1 from

Re: [Qgis-developer] QGIS 3 plugins - require implementation as processing algs?

+1 from me :-) (no surprise...) I will be happy to help on this, helping developers when adapting their plugins. I can even make a short list in advance, with the current plugins that would be convenient to adapt as Processing algorithms, and help their developers implement them as such. I think

Re: [Qgis-developer] Qgis resource sharing VS processing for script sharing

I think we should deprecate the current repo for scripts and using this new one, to have everything in the same place That requires two things: 1) make sure it the Resources Sharing plugin works fine for Processing scripts :-) 2) Have the resources sharing plugin as a core plugin (otherwise,a

Re: [Qgis-developer] OTB integration in QGIS

r.b...@gmail.com>: > Hi Manuel, > > me and Victor Olaya will be in Bonn during first code sprint and some > conference days. Surely we can discuss OTB integration and work > together to improve it. > > 2016-07-28 12:23 GMT+03:00 Manuel Grizonnet <manuel.grizon...@gmail.

Re: [Qgis-developer] Number of arguments for processing gdalogr:warpreproject

thanks to you! 2016-07-22 9:42 GMT+02:00 Tom Chadwin : > Yes, all working in 8784312. Splendid! > > Many thanks once again > > Tom > > > > -- > View this message in context: >

Re: [Qgis-developer] QGIS starts a child process which immediately turns into a zombie

Processing tries to figure out the version of SAGA you have installed, and to do so it has to call SAGA. I guess that might be the source of this issue. It should correctly close that process, but it seems it is not doing so in your case... 2016-07-21 9:28 GMT+02:00 Schmid Andreas

Re: [Qgis-developer] Number of arguments for processing gdalogr:warpreproject

2016-06-28 13:34 GMT+02:00 Tom Chadwin : > I'm sorry to keep asking about this. I'm now getting this error on Travis, > against nightly (http://qgis.org/debian-nightly): > > Traceback (most recent call last): > File "/home/travis/build/tomchadwin/qgis2web/olwriter.py",

Re: [Qgis-developer] Update downloadable scripts from Processing

if they are in the repo, they should be available, sice Processing connects directly to it Maybe version numbers are wrong? 2016-07-06 15:09 GMT+02:00 matteo : > Hi all, > > I had a quick look at the download R script tool in Processing and I > noticed that some scripts

Re: [Qgis-developer] FOSS4G code sprint idea: improving SLD export and GeoServer compatibility

Andrea I will be at Bonn and I will be happy to collaborate on that. Unfortuately, i will be at the code sprint_before_ the conference, so i hope at least we ca find some time durig the conference days to discuss about this Let me know if there is something else I can do to help Cheers

Re: [Qgis-developer] Number of arguments for processing gdalogr:warpreproject

It seems that the progress indicator is None. I guess you should be passing one, or at least a SilentProgress 2016-06-28 13:34 GMT+02:00 Tom Chadwin : > I'm sorry to keep asking about this. I'm now getting this error on Travis, > against nightly

Re: [Qgis-developer] adding SAGA algorithms in Processing

In the grass folder of processing there is a file explaining the syntax, for GRASS algorithm. It is the same syntax for SAGA, so you can follow that doc 2016-06-20 9:19 GMT+02:00 matteo : > Hi all, > > I'm trying to add some missing SAGA algorithm in Processing. > > I saw

Re: [Qgis-developer] Error during while creating the help for models in Processing

yes, please Thanks! 2016-06-16 17:33 GMT+02:00 matteo : > Hi all, > just made more tests and the error seems related only for R scripts added to > the model.. > > should I open a ticket? > > thanks > > Matteo > ___ >

Re: [Qgis-developer] What's the recommended way to implement a spatial index in Processing algorithms?

i guess that the spatial index should be created as usual, but, as you say, only including selected features if the Processing settings is configured to use only those ones. I dont see any specific thing about it being a Processing algorithm, other than that. An even if you create it for the

Re: [Qgis-developer] (Yet again) SAGA support badly broken in QGIS

> > SAGA already can use OGR instead of just shapefiles. By using the > module io_gdal you can load a file through OGR into memory, do your > analysis and save using the same module to any ogr file. > It does not have to be a shape file. In the gui, try dragging and > dropping an OGR supported

Re: [Qgis-developer] (Yet again) SAGA support badly broken in QGIS

I think Johan van de Wauw is the person we should contact. Seems responsive and offered to create a LTR for SAGA. I was quite involved in the SAGA community long ago and I know the devs personally, but haven't done much with the software itself (in terms of development) since long ago. I think

Re: [Qgis-developer] (Yet again) SAGA support badly broken in QGIS

I am familiar with SAGA source code, and algorithms are independent and self contained, very modular structure, so it should be easy to use them. There is a lot of work in there, since the number of algorithms is very large, but it can be a progressive thing. Having the in the QGIS source code

Re: [Qgis-developer] (Yet again) SAGA support badly broken in QGIS

My opinion about this (and getting stronger each time, since the situation is getting worse...) is that we have only two solutions: 1) fork SAGA and have QGIS depend on that forked software, which we will (in principle) not upgrade. 2) embed a fixed version of SAGA, and use only that one. SAGA

Re: [Qgis-developer] Show your cool stuff

I would like to present the "Lessons plugin", a plugin to run interactive lessons within QGIS 2016-05-28 9:19 GMT+02:00 Nathan Woodrow : > Can someone go though my style dock stuff for me although I'm sure most know > already. > > > On Sat, 28 May 2016 5:16 pm Paolo Cavallini

Re: [Qgis-developer] [Processing] Parameters and widgets refactoring

I like this design a lot. That will give us a cleaner structure and a code that is easier to understand. Definitely this has to be in 3.0, although it will be quite a bit of work. Any additional comment from anyone? Arnaud, will you at camptocamp be able to dedicate time to this task? Let's see

Re: [Qgis-developer] Processing, Python 3 and Qt5

Awesome!! Definitely, having a good test suite will help with that. Maybe that should be one of our work priorities for the hackfest. Great work! 2016-05-23 1:07 GMT+02:00 Matthias Kuhn : > Hi, > > > A short update on porting plugins, python 3 and qt5. Today I had success >

Re: [Qgis-developer] Processing - current status of "in-between" layers while running models

Basically, layers are generated in the default format supported by the algorithm (that is, the first one in the list returned by getSupportedOutputVectorLayerExtensions() from the corresponding provider) Forcing a format for all intermediate layer will have some advantages, but also some

Re: [Qgis-developer] [Processing] GDAL - Clip raster by extent : is NODATA param optional ?

There should be no problem declaring it as optional (it is actually optional, so it fixed the decalration) What surprises me a bit is that when running from the toolbox, an empty string is accepted as a valid value...if it is not optional, it should complain Anyway, that's a different thing :-)

Re: [Qgis-developer] Processing different behaviour of selection in gdal and saga

Looks like an issue with the GDAL provider. It should only use the selected polygon. I will take a look at it Thanks for reporting! 2016-04-06 17:04 GMT+02:00 Paolo Cavallini : > Hi all, > if I select one polygon and clip raster with polygon, saga clips only > the selected

Re: [Qgis-developer] Support for QGIS variables in Processing

> > One question I have is if it's required to see variables as an isolated > topic outside of expressions. Or if whenever a variable is required, a > complete expression would offer much more flexibility. That's actually a very good idea. As I said, now I am just trying to start with this, and

[Qgis-developer] Support for QGIS variables in Processing

Hi all I am trying to add support for QGIS variables in Processing, since that can be a useful functionality. To start with, I want to add it to scripts, so you can use the @variable syntax in Processing scripts as well It is easy to implement that, but the scope here is not so clear as in other

Re: [Qgis-developer] Proposal: removing Processing from plugins repo

I wouldn't mind doing a documentation sprint as part of the next hackfest... Until now, not much time on my side to write docs :-( 2016-04-05 7:59 GMT+02:00 Paolo Cavallini <cavall...@faunalia.it>: > Il 05/04/2016 07:55, Victor Olaya ha scritto: >> I guess it's somehow

Re: [Qgis-developer] Proposal: removing Processing from plugins repo

/processing/algs/grass7/Grass7AlgorithmProvider.py#L47 that should help understand 2016-04-05 7:49 GMT+02:00 Paolo Cavallini <cavall...@faunalia.it>: > Il 05/04/2016 07:24, Victor Olaya ha scritto: >> But that's an option in the provider. Some providers should be by >> default d

Re: [Qgis-developer] Proposal: removing Processing from plugins repo

Il 04/04/2016 12:21, Victor Olaya ha scritto: >>> BTW, another issue: currently a subplugin can be deactivated (and should >>> be activated) both from plugin manager and from Processing. >>> IMHO the second step should be skipped. >>> All the best. >> &g

Re: [Qgis-developer] processing algoritm/script button?

Right, and, as Alex points out, doint it programatically you have the option to add a button as well (using the UI, not) see https://github.com/qgis/QGIS/blob/master/python/plugins/processing/gui/menus.py#L138 2016-04-04 13:18 GMT+02:00 Alexander Bruy : > Hi Richard,

Re: [Qgis-developer] processing algoritm/script button?

there is an option in Processing to add any algorithm as a menu (see in the Processing options menu), but not as a button, The "custom toolbar" plugin has that option, and will allow you to add a new toolbar and button with any Processing algorithm Hope this helps 2016-04-04 12:35 GMT+02:00

Re: [Qgis-developer] Proposal: removing Processing from plugins repo

> BTW, another issue: currently a subplugin can be deactivated (and should > be activated) both from plugin manager and from Processing. > IMHO the second step should be skipped. > All the best. Since the latest UI changes, deactivating a plugin in the Processing options doesnt mean disabling it,

  1   2   3   4   5   6   >