Re: [QGIS-Developer] Processing Help system

[matteo]

Hi devs,

I want to share a super brief summary of the brainstorming we had on
this topic. I think it is better to speak about it in Madeira with all
the interested people.

There are some small issues with the Help system and Processing (sphinx
related): that is, URLs build from the Help system are (sometimes)
different from those generated from Sphinx.

Differences are:

* Help system build URL with providerId/groupId/algorithmName.html
* provider "native" is not present in sphinx
* Help system concatenates words (eventually) while sphinx puts `-`
between words

At the end, for some algorithm, we have documentation already merged,
but unreachable from the UI of Processing, e.g.:

1. Help system URL:

https://docs.qgis.org/testing/en/docs/user_manual/processing_algs/native/vectoroverlay.html#lineintersections

2. doc URL:

https://docs.qgis.org/testing/en/docs/user_manual/processing_algs/qgis/vector_overlay_tools.html#line-intersections

I hope interested people can jump in this discussion on share some thoughts!

Cheers

Matteo


___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Plugin [793] Multi Ring Buffer approval notification.

[noreply]

Plugin Multi Ring Buffer approval by pcav.
The plugin version "[793] Multi Ring Buffer 1.0" is now approved
Link: http://plugins.qgis.org/plugins/Multi_Ring_Buffer/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Plugin [970] TUFLOW approval notification.

[noreply]

Plugin TUFLOW approval by pcav.
The plugin version "[970] TUFLOW 1.4.0" is now approved
Link: http://plugins.qgis.org/plugins/tuflow/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS3: Python QgsFeatureRenderer subclass problem

[Chris Crook]

Continued: Ok, understand a bit more now.  Still not sure where the clone 
should be created but if the same renderer is called from more than one thread, 
as the first time startRender is called it sets the thread id for the 
rendererer, and thereafter cannot be called with a different thread id.  So 
issue could either be if startRender does not invoke super.startRender (to set 
thread id) or if called from two threads.

From: QGIS-Developer [qgis-developer-boun...@lists.osgeo.org] on behalf of 
Chris Crook
Sent: 08 February 2018 08:45
To: qgis-developer@lists.osgeo.org
Subject: [QGIS-Developer] QGIS3: Python QgsFeatureRenderer subclass problem

I am converting a python  plugin the implements a subclass of 
QgsFeatureRenderer.  At the moment the plugin is dying on the startRender 
function with the message (from the base class)

"ASSERT failure in QgsFeatureRenderer::renderFeature: \"renderFeature called in 
a different thread - use a cloned renderer instead\"

I can't see where I should be creating the cloned renderer for the rendering.  
I had a look at the QgsSingleSymbolRenderer C++ code and I can't see anything 
there, so I'm wondering if the python implementation in some way corrupts the 
multiprocessing implementation.  Can anyone offer any suggestions



This message contains information, which may be in confidence and may be 
subject to legal privilege. If you are not the intended recipient, you must not 
peruse, use, disseminate, distribute or copy this message. If you have received 
this message in error, please notify us immediately (Phone 0800 665 463 or 
i...@linz.govt.nz) and destroy the original message. LINZ accepts no 
responsibility for changes to this email, or for any attachments, after its 
transmission from LINZ. Thank You.
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Rule based renderer question

[matteo]

Hi Nyall,

> It's been a feature request for a while - see
> https://issues.qgis.org/issues/10479

I missed that. Thanks!

Matteo
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QgsLayout LoadFromTemplate & substitutionMap

[Nyall Dawson]

On 8 February 2018 at 08:10, Marc Ducobu  wrote:

>
> With QgsComposition, it was possible to pass a "substitution map" to the
> method loadFromTemplate : the substitution map was a map/associative
> array such that when loading the template, strings like "[key]" were
> replaced by the value associated to the key ( see
> https://qgis.org/api/2.18/qgscomposition_8cpp_source.html#l01107 ).
>
> With QgsLayout, I have the impression that this feature has disappear.
> Do you know if it exists an alternative way to obtain an equivalent result ?
>
> Thanks a lot.

Yes - I removed that argument as it was unused in the code and looked
like a legacy leftover. My thoughts are that these substitutions would
be better performed now by placing expressions and through use of
expression variables directly inside the layout elements themselves -
e.g. instead of using the substitution to replace a label's text, put
an expression directly inside the label text and use the built in
expression functions or variables to evaluate to the desired text.

Alternatively, given that the argument was API only and not exposed to
users anywhere, it could also be done directly using built in python
replace methods prior to calling loadFromTemplate.

Nyall
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QgsLayout LoadFromTemplate & substitutionMap

[Tim Sutton]

Hi




> On 08 Feb 2018, at 00:10, Marc Ducobu  wrote:
> 
> Hello,
> 
> With QgsComposition, it was possible to pass a "substitution map" to the
> method loadFromTemplate : the substitution map was a map/associative
> array such that when loading the template, strings like "[key]" were
> replaced by the value associated to the key ( see
> https://qgis.org/api/2.18/qgscomposition_8cpp_source.html#l01107 ).
> 
> With QgsLayout, I have the impression that this feature has disappear.
> Do you know if it exists an alternative way to obtain an equivalent result ?


Eish I hope we didn't lose it too ... we use this heavily….though I guess you 
could do similar things with variables and expressions now…

Regards

Tim

> 
> Thanks a lot.
> 
> Marc
> 
> 
> 
> 
> On 2018-02-07 22:53, Nyall Dawson wrote:
>> 2018-02-08 0:22 GMT+10:00 Marc Ducobu :
>>> -BEGIN PGP MESSAGE-
>>> 
>>> hQEMAwq3T6TpWbvPAQf+N5YzqrBzxjmEIwEjuodMGCOvUtoaxlzbt91dV7sWOxm9
>>> -END PGP MESSAGE-
>> Can you send a non-encoded version of this message please? The subject
>> looks interesting, but I can't read it.
>> 
>> Nyall
> 
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

—







Tim Sutton

Co-founder: Kartoza
Project chair: QGIS.org

Visit http://kartoza.com  to find out about open source:

Desktop GIS programming services
Geospatial web development
GIS Training
Consulting Services

Skype: timlinux
IRC: timlinux on #qgis at freenode.net



signature.asc
Description: Message signed with OpenPGP
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [Qgis-psc] Nominations for the QGIS Board and a short announcement from your Board Chair

[Tim Sutton]

Hi

Thanks so much for your kind comment Nyall, Giovanni and Paolo!

Regards

Tim

> On 08 Feb 2018, at 00:01, Nyall Dawson  wrote:
> 
> On 7 February 2018 at 01:16, Tim Sutton  wrote:
>> On a personal note I would like to share that I will be standing down from 
>> the Board and PSC at the end of my tenure as chair
> 
> Tim -
> 
> It's with much sadness that I read this, but I can also totally
> understand your decision in doing so. Under your leadership the QGIS
> project has grown and gone from strength to strength, and I believe
> that a HUGE part of this is directly due to your guidance of the
> project. You've been everything we could possibly dream of in a chair.
> 
> I'd also like to say that I've found your welcoming attitude a great
> inspiration. Just watching you at hackfests I've seen endless
> occasions of how you always give everyone time and attention, how you
> actively seek out new members of the community and take time to learn
> their stories, and how courteous and respectful you are of everyone's
> opinions.
> 
> The whole open-source software ecosystem would be a much better place
> if we had more people like you in leadership!



> 
> Nyall

—







Tim Sutton

Co-founder: Kartoza
Project chair: QGIS.org

Visit http://kartoza.com  to find out about open source:

Desktop GIS programming services
Geospatial web development
GIS Training
Consulting Services

Skype: timlinux
IRC: timlinux on #qgis at freenode.net



signature.asc
Description: Message signed with OpenPGP
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QgsLayout LoadFromTemplate & substitutionMap

[Marc Ducobu]

Hello,

Sorry about that.

Here is the non-encoded version.

Marc




Hello,

With QgsComposition, it was possible to pass a "substitution map" to the
method loadFromTemplate : the substitution map was a map/associative
array such that when loading the template, strings like "[key]" were
replaced by the value associated to the key ( see
https://qgis.org/api/2.18/qgscomposition_8cpp_source.html#l01107 ).

With QgsLayout, I have the impression that this feature has disappear.
Do you know if it exists an alternative way to obtain an equivalent result ?

Thanks a lot.

Marc




On 2018-02-07 22:53, Nyall Dawson wrote:
> 2018-02-08 0:22 GMT+10:00 Marc Ducobu :
>> -BEGIN PGP MESSAGE-
>>
>> hQEMAwq3T6TpWbvPAQf+N5YzqrBzxjmEIwEjuodMGCOvUtoaxlzbt91dV7sWOxm9
>> -END PGP MESSAGE-
> Can you send a non-encoded version of this message please? The subject
> looks interesting, but I can't read it.
>
> Nyall

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [Qgis-psc] Nominations for the QGIS Board and a short announcement from your Board Chair

[Nyall Dawson]

On 7 February 2018 at 01:16, Tim Sutton  wrote:
> On a personal note I would like to share that I will be standing down from 
> the Board and PSC at the end of my tenure as chair

Tim -

It's with much sadness that I read this, but I can also totally
understand your decision in doing so. Under your leadership the QGIS
project has grown and gone from strength to strength, and I believe
that a HUGE part of this is directly due to your guidance of the
project. You've been everything we could possibly dream of in a chair.

I'd also like to say that I've found your welcoming attitude a great
inspiration. Just watching you at hackfests I've seen endless
occasions of how you always give everyone time and attention, how you
actively seek out new members of the community and take time to learn
their stories, and how courteous and respectful you are of everyone's
opinions.

The whole open-source software ecosystem would be a much better place
if we had more people like you in leadership!

Nyall
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QgsLayout LoadFromTemplate & substitutionMap

[Nyall Dawson]

2018-02-08 0:22 GMT+10:00 Marc Ducobu :
> -BEGIN PGP MESSAGE-
>
> hQEMAwq3T6TpWbvPAQf+N5YzqrBzxjmEIwEjuodMGCOvUtoaxlzbt91dV7sWOxm9

> -END PGP MESSAGE-

Can you send a non-encoded version of this message please? The subject
looks interesting, but I can't read it.

Nyall
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS3: Python QgsFeatureRenderer subclass problem

[Nyall Dawson]

On 8 February 2018 at 05:44, Chris Crook  wrote:
> I am converting a python  plugin the implements a subclass of 
> QgsFeatureRenderer.  At the moment the plugin is dying on the startRender 
> function with the message (from the base class)
>
> "ASSERT failure in QgsFeatureRenderer::renderFeature: \"renderFeature called 
> in a different thread - use a cloned renderer instead\"
>
> I can't see where I should be creating the cloned renderer for the rendering. 
>  I had a look at the QgsSingleSymbolRenderer C++ code and I can't see 
> anything there, so I'm wondering if the python implementation in some way 
> corrupts the multiprocessing implementation.  Can anyone offer any suggestions
>

Interesting - is your code public anywhere? I'll take a look.

Nyall
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] External providers in QGIS

[G. Allegri]

I'm much more in favour for out of core providers, for the same reasons
reported by Victor. Having only GDAL and QGIS algorithms in core will
reduce the number of available algorithms out of the box, but:

- from my experience - comprising years of feedbacks from the courses I
teach - the most frequently used algs are available within the GDAL and
QGIS algs list

- a few generic and widely used algs are from GRASS and SAGA. We would miss
them - out of the box - but it could also be an opportunity to port them.
For examples v.to.points, transects, profiles.
Anyway we would have the plugins for GRASS and SAGA, in case...

- specific algs are for specialized users. Here I think plugins are best
suited (OTB, R, TauDEM, etc.). Tomorrow a new sw could be added to the
list, consistently with the others approach.

I appreciate a lot the work from Richard, I hope this discussion is not
understood as to belittle its effort!

my 2 cents...
Giovanni

Il 7 feb 2018 18:25, "Paolo Cavallini"  ha scritto:

> Il 07/02/2018 11:18, Victor Olaya ha scritto:
> > I dont see the advantage in having providers in core.
>
> I see the following:
> * tests (already available in our infrastructure)
> * translations
> * more exposure
> * documentation
>
> > And if there is an
> > advantage, it's clearly not in how easy it is going to be to maintain
> > the plugin.
>
> until now it has been maintained somehow; if more resources are needed,
> we can find a way
>
> > 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 have write access?
>
> why not granting them write access?
>
> > Better in a separate repo. Also, they can
> > release whenever there are changes, without having to wait for a new
> > release. That way, the plugin will always be in sync with new releases
> > of the backend app.
>
> this is certainly true; AFAICT OTB people has proposed a solution
>
> > If we put them in core...why putting only this big ones (which in some
> > cases require installing external apps manually by the user), and not
> > put other plugins that exist and contain Processing providers?
>
> I'd be in favour of adding anything important for users.
>
> Thanks for your thoughts.
>
> When in Madeira we can have a discussion about this. It would be good if
> all interested parties could meet, locally and remotely.
>
> All the best.
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] External providers in QGIS

[Paolo Cavallini]

Il 07/02/2018 11:18, Victor Olaya ha scritto:
> I dont see the advantage in having providers in core.

I see the following:
* tests (already available in our infrastructure)
* translations
* more exposure
* documentation

> And if there is an
> advantage, it's clearly not in how easy it is going to be to maintain
> the plugin.

until now it has been maintained somehow; if more resources are needed,
we can find a way

> 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 have write access?

why not granting them write access?

> Better in a separate repo. Also, they can
> release whenever there are changes, without having to wait for a new
> release. That way, the plugin will always be in sync with new releases
> of the backend app.

this is certainly true; AFAICT OTB people has proposed a solution

> If we put them in core...why putting only this big ones (which in some
> cases require installing external apps manually by the user), and not
> put other plugins that exist and contain Processing providers? 

I'd be in favour of adding anything important for users.

Thanks for your thoughts.

When in Madeira we can have a discussion about this. It would be good if
all interested parties could meet, locally and remotely.

All the best.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] GSoC idea: improve QGIS-GRASS GIS algs provider

[Paolo Cavallini]

Il 07/02/2018 00:23, Helmut Kudrnovsky ha scritto:
> As a follow-up of the long discussion how to proceed with alg providers in
> QGIS, have a look at:
> 
> https://trac.osgeo.org/grass/wiki/GSoC/2018#ImproveGRASSintegrationinQGIS3
> 
> It should be seen as an starting point to collect ideas, and to sharpen the
> technical interface and requirements for such an Integration of external alg
> providers.
> 
> And it should be also understood as a starting contribution of the GRASS
> community for a deeper proactively inter-project communication and
> collaboration.

good idea, thanks Helmut

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Plugin [1397] Point to Polygon approval notification.

[noreply]

Plugin Point to Polygon approval by pcav.
The plugin version "[1397] Point to Polygon 0.6 Experimental" is now approved
Link: http://plugins.qgis.org/plugins/PointToPolygon/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Plugin [1305] Calidad-CAR approval notification.

[noreply]

Plugin Calidad-CAR approval by pcav.
The plugin version "[1305] Calidad-CAR 1.0.1" is now approved
Link: http://plugins.qgis.org/plugins/CalidadCAR/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Victor Olaya]

Thanks! Looks like i was using an older version, not up to date, and the
button was not there.

good to see that some one else is using this as well :-)

Thanks again!

2018-02-06 9:04 GMT+01:00 Tudor Barascu :

> Hi Victor,
>
> I had the same problem in finding where to put the python logic in QGIS 3.
> Here you go: python_logic.jpg
> 
>
> python_logic.jpg
>
> Shared with Dropbox
> 
>
> 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:
>
>
> 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
> by
> Nathan, in which it disconnects the default 'accepted' signal from the
> 'dialog.accept' slot. I tried that, but it doesnt seem to be working. It
> runs the validation function that I connect to that signal, but even if I
> dont accept the dialog in that function, it closes it.
>
> I also tried using the disconnectButtonBox() method of the
> QgsAttributeForm class, but it does nothing. The buttons still do their
> work.
>
> Is this a bug, or I am doing something wrong?
>
> In QGIS3, it seems that now only the ui file can be provided, but not a
> python file with the form logic. How is that added now?
>
> Thanks!
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] QgsLayout LoadFromTemplate & substitutionMap

[Marc Ducobu]

binIVmfPaggOU.bin
Description: PGP/MIME version identification


encrypted.asc
Description: OpenPGP encrypted message
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] External providers in QGIS

[Rashad Kanavath]

On Wed, Feb 7, 2018 at 3:03 PM, Victor Olaya  wrote:

> I dont think that it is possible to make it more generic. It's not only
> descriptors with only outputs and inputs. Each backend app has its own
> logic. GRASS needs outputs to be converted to its own format. SAGA accepts
> only SHP for vector layers and generates its own SDAT format for raster
> outputs. Parameters are also not passed in the same way to all apps. SAGA
> has extent parameters splitted in 4 params with bbox coordinates. Each
> provider has a different way of indicating a boolean value in the console
> call. In short, the logic must be there somehow, specific for the provider,
>

can you confirm that a GRASS input/output parameter can solve their issue?.
Still there is SAGA and other stuff. So generic provider is not something
QGIS team can do. But I would like to know about this on GRASS issue.


> What is the difference between maintaining a set of descriptor files (as
> you propose) and a set of descriptor files + a class extending
> GeoAlgorithmProvider with the logic (as it happens now)?. I think it is
> easier to have a solid provider class for OTB and then do not ever change
> it (assuming OTB syntax will never change), than having a generic provider,
> which looks rather unfeasible.
>
> Still OTB requires some changes in processing plugin to work. the old way
of twisting application only for QGIS must be avoided.
Without such a change there is no long-term existence even as plugin. Or
worse, it exists and will be broken.
QGIS must recognize such a behavior and avoid adding  burden on external
toolboxes' developer teams by asking for splitting applications. Be it OTB,
GRASS, SAGA whatever.

While I was at it, I saw there is less stuff to be managed and can be done
using a customwidgetwrapper for OTB. because a custom widget wrapper works
in a special way only for one provider.
Hence the idea of generic provider came up!.  In  case of GRASS its
input/output parameter, for OTB it is selection list parameter.

Thanks for your valuable feedback on this. I am sure an idea of generic
provider came up sometime during your work on processing plugin.
It tough and need more expert work and safe is to avoid it totally. I agree
on that part.



> As you say, there is the risk for dead code. In that case, i think it is
> much better to have the provider outside of QGIS core, as a plugin. There
> are dozens of dead plugins, and that is not nice, but it's kinda
> acceptable. Having dead code in QGIS it's a much bigger issue, and we must
> avoid that.
>
> Cheers
>
>
>
> 2018-02-07 14:41 GMT+01:00 Rashad Kanavath :
>
>> Hello victor,
>>
>> Do you see a possibility of a generic processing provider?. One that can
>> read descriptor files and run algorithms!.
>> I see processing as a single plugin (included in QGIS or not). And if it
>> can avoid need to have sub-plugin managed by all those other development
>> team. That's even better!.
>> Whichever toolbox want to be integrated into processing plugin can
>> provide and maintain descriptor files individually. No QGIS developers need
>> to be involved.
>> This way, external toolboxes' team or qgis does not need to maintain/fix
>> qgis--provider-plugin.
>>
>> search -> download -> install plugin will be changed to configure
>> providers install location.
>> If needed QGIS can control list of available providers (just names).
>>
>> External tools' dev team needs to know something such as spec of
>> descriptor files, how to mention name of executable etc.
>> They don't need to know stuff like how qgis run a processing algorithm,
>> and things working of modeler, running with other algorithms.
>>
>> Anyway, this is just an idea and don't know what will be technically
>> challenging issues?
>>
>> The other way of putting processing plugin into core and providers
>> classified as external plugins can avoid maintenance on qgis.
>> But this "strategy" can result in dead code and users complaining on both
>> projects. Because, at some developers cannot manage project release + a
>> plugin for qgis, another plugin for matlab or whatever
>> Putting all stuff in qgis tree and taking no responsibility 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
>> both community benefit best of both worlds.
>>
>>
>> On Wed, Feb 7, 2018 at 11:18 AM, Victor Olaya  wrote:
>>
>>> 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
>>> have write access? Better in a separate repo. Also, 

Re: [QGIS-Developer] External providers in QGIS

[Victor Olaya]

I dont think that it is possible to make it more generic. It's not only
descriptors with only outputs and inputs. Each backend app has its own
logic. GRASS needs outputs to be converted to its own format. SAGA accepts
only SHP for vector layers and generates its own SDAT format for raster
outputs. Parameters are also not passed in the same way to all apps. SAGA
has extent parameters splitted in 4 params with bbox coordinates. Each
provider has a different way of indicating a boolean value in the console
call. In short, the logic must be there somehow, specific for the provider,

What is the difference between maintaining a set of descriptor files (as
you propose) and a set of descriptor files + a class extending
GeoAlgorithmProvider with the logic (as it happens now)?. I think it is
easier to have a solid provider class for OTB and then do not ever change
it (assuming OTB syntax will never change), than having a generic provider,
which looks rather unfeasible.

As you say, there is the risk for dead code. In that case, i think it is
much better to have the provider outside of QGIS core, as a plugin. There
are dozens of dead plugins, and that is not nice, but it's kinda
acceptable. Having dead code in QGIS it's a much bigger issue, and we must
avoid that.

Cheers



2018-02-07 14:41 GMT+01:00 Rashad Kanavath :

> Hello victor,
>
> Do you see a possibility of a generic processing provider?. One that can
> read descriptor files and run algorithms!.
> I see processing as a single plugin (included in QGIS or not). And if it
> can avoid need to have sub-plugin managed by all those other development
> team. That's even better!.
> Whichever toolbox want to be integrated into processing plugin can provide
> and maintain descriptor files individually. No QGIS developers need to be
> involved.
> This way, external toolboxes' team or qgis does not need to maintain/fix
> qgis--provider-plugin.
>
> search -> download -> install plugin will be changed to configure
> providers install location.
> If needed QGIS can control list of available providers (just names).
>
> External tools' dev team needs to know something such as spec of
> descriptor files, how to mention name of executable etc.
> They don't need to know stuff like how qgis run a processing algorithm,
> and things working of modeler, running with other algorithms.
>
> Anyway, this is just an idea and don't know what will be technically
> challenging issues?
>
> The other way of putting processing plugin into core and providers
> classified as external plugins can avoid maintenance on qgis.
> But this "strategy" can result in dead code and users complaining on both
> projects. Because, at some developers cannot manage project release + a
> plugin for qgis, another plugin for matlab or whatever
> Putting all stuff in qgis tree and taking no responsibility 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
> both community benefit best of both worlds.
>
>
> On Wed, Feb 7, 2018 at 11:18 AM, Victor Olaya  wrote:
>
>> 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
>> have write access? Better in a separate repo. Also, they can release
>> whenever there are changes, without having to wait for a new release. That
>> way, the plugin will always be in sync with new releases of the backend app.
>>
>> If we put them in core...why putting only this big ones (which in some
>> cases require installing external apps manually by the user), and not put
>> other plugins that exist and contain Processing providers?
>>
>> I thought the idea was to not have core plugins and avoid them if
>> possible. I don't see why we have to treat plugins that have Processing
>> provider in a different way. Specially considering how easy it is to
>> install a plugin in QGIS.
>>
>> Cheers
>>
>>
>>
>> 2018-02-06 18:57 GMT+01:00 Paolo Cavallini :
>>
>>> Hi all,
>>> following the discussion on qgis-dev ML:
>>> https://lists.osgeo.org/pipermail/qgis-developer/2018-Januar
>>> y/051701.html
>>> it has been proposed to remove all external providers (namely OTB,
>>> already removed, GRASS, and SAGA) from Processing in QGIS2 (GDAL will
>>> remain as QGIS cannot be built without). This raised a number of
>>> concerns, so PSC decided not to rush removing them from the upcoming 3.0
>>> release, and to open a wider discussions about this, involving all the
>>> interested parties, to find an optimal solution.
>>> If volunteers outside QGIS core team, ideally from the 

Re: [QGIS-Developer] External providers in QGIS

[Alexander Bruy]

Hi Rashad,

2018-02-07 15:41 GMT+02:00 Rashad Kanavath :
> Do you see a possibility of a generic processing provider?. One that can
> read descriptor files and run algorithms!.

This is possible in the ideal world of ponies and rainbows. In real
world we need
to deal with different types of the inputs, with different
representation of the same
thing in the different programs, different logics.

-- 
Alexander Bruy
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Rule based renderer question

[matteo]

Hi all,

simple question for the refining the rule-based renderer.

Suppose you have an admin layer (all word countries) and you categorized
it depending on the continent belonging (e.g. 5 categories - 5 colors).

Switch to the rule-based rendered and refine the rule (only for the
continent e.g. Africa) by adding sub-categories to style each African
country with other random colors.

When choosing the category column in the sub-rendered, it filters for
**all** world countries and not for just the African ones.

The same happens when adding an interval for the rule (so min and max
values are calculated considering the values of the whole layer).

I don't know if this behavior is intended, but I was expecting to have
listed just the sub-categories of the main one.

But maybe I'm missing something, so I'm just asking :)

Thanks for any feedback

Cheers

Matteo


___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] External providers in QGIS

[Rashad Kanavath]

Hello victor,

Do you see a possibility of a generic processing provider?. One that can
read descriptor files and run algorithms!.
I see processing as a single plugin (included in QGIS or not). And if it
can avoid need to have sub-plugin managed by all those other development
team. That's even better!.
Whichever toolbox want to be integrated into processing plugin can provide
and maintain descriptor files individually. No QGIS developers need to be
involved.
This way, external toolboxes' team or qgis does not need to maintain/fix
qgis--provider-plugin.

search -> download -> install plugin will be changed to configure providers
install location.
If needed QGIS can control list of available providers (just names).

External tools' dev team needs to know something such as spec of descriptor
files, how to mention name of executable etc.
They don't need to know stuff like how qgis run a processing algorithm, and
things working of modeler, running with other algorithms.

Anyway, this is just an idea and don't know what will be technically
challenging issues?

The other way of putting processing plugin into core and providers
classified as external plugins can avoid maintenance on qgis.
But this "strategy" can result in dead code and users complaining on both
projects. Because, at some developers cannot manage project release + a
plugin for qgis, another plugin for matlab or whatever
Putting all stuff in qgis tree and taking no responsibility 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
both community benefit best of both worlds.


On Wed, Feb 7, 2018 at 11:18 AM, Victor Olaya  wrote:

> 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
> have write access? Better in a separate repo. Also, they can release
> whenever there are changes, without having to wait for a new release. That
> way, the plugin will always be in sync with new releases of the backend app.
>
> If we put them in core...why putting only this big ones (which in some
> cases require installing external apps manually by the user), and not put
> other plugins that exist and contain Processing providers?
>
> I thought the idea was to not have core plugins and avoid them if
> possible. I don't see why we have to treat plugins that have Processing
> provider in a different way. Specially considering how easy it is to
> install a plugin in QGIS.
>
> Cheers
>
>
>
> 2018-02-06 18:57 GMT+01:00 Paolo Cavallini :
>
>> Hi all,
>> following the discussion on qgis-dev ML:
>> https://lists.osgeo.org/pipermail/qgis-developer/2018-January/051701.html
>> it has been proposed to remove all external providers (namely OTB,
>> already removed, GRASS, and SAGA) from Processing in QGIS2 (GDAL will
>> remain as QGIS cannot be built without). This raised a number of
>> concerns, so PSC decided not to rush removing them from the upcoming 3.0
>> release, and to open a wider discussions about this, involving all the
>> interested parties, to find an optimal solution.
>> If volunteers outside QGIS core team, ideally from the respective
>> backends, could take the maintenance of these providers, not much would
>> change for the end user. If not, this will mean effectively missing
>> hundreds of algs from QGIS.
>> I personally propose to reinstate the OTB plugin with Rashad (from OTB)
>> as maintainer.
>> QGIS.ORG will seek to support any decision made with funding where
>> possible.
>> Looking forward for your feedback.
>> All the best.
>> --
>> Paolo Cavallini - www.faunalia.eu
>> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
>> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
>>
>
>


-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] External providers in QGIS

[Victor Olaya]

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
have write access? Better in a separate repo. Also, they can release
whenever there are changes, without having to wait for a new release. That
way, the plugin will always be in sync with new releases of the backend app.

If we put them in core...why putting only this big ones (which in some
cases require installing external apps manually by the user), and not put
other plugins that exist and contain Processing providers?

I thought the idea was to not have core plugins and avoid them if possible.
I don't see why we have to treat plugins that have Processing provider in a
different way. Specially considering how easy it is to install a plugin in
QGIS.

Cheers



2018-02-06 18:57 GMT+01:00 Paolo Cavallini :

> Hi all,
> following the discussion on qgis-dev ML:
> https://lists.osgeo.org/pipermail/qgis-developer/2018-January/051701.html
> it has been proposed to remove all external providers (namely OTB,
> already removed, GRASS, and SAGA) from Processing in QGIS2 (GDAL will
> remain as QGIS cannot be built without). This raised a number of
> concerns, so PSC decided not to rush removing them from the upcoming 3.0
> release, and to open a wider discussions about this, involving all the
> interested parties, to find an optimal solution.
> If volunteers outside QGIS core team, ideally from the respective
> backends, could take the maintenance of these providers, not much would
> change for the end user. If not, this will mean effectively missing
> hundreds of algs from QGIS.
> I personally propose to reinstate the OTB plugin with Rashad (from OTB)
> as maintainer.
> QGIS.ORG will seek to support any decision made with funding where
> possible.
> Looking forward for your feedback.
> All the best.
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer