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

2018-02-10 Thread Paolo Cavallini 
Il 10/02/2018 14:38, Anita Graser ha scritto:
> On Fri, Feb 9, 2018 at 11:01 AM, Richard
> Duivenvoorde > wrote:
> 
> Maybe at a hackfest, foss4g or other meeting it is good to come together
> face to face so it is easier to actually SHOW each other the
> bears/problems we see?
> 
> 
> Since Madeira is just around the corner, let's organize a round table
> discussion on this issue. I've started a section here:
> 
> https://github.com/qgis/QGIS/wiki/DeveloperMeetingMadeira2018#future-of-processing-providers
> 
> Please add yourself to the list if you are interested in participating
> on-site or remotely. We'll then try to find a time slot that works for
> everyone. 

thanks Anita for setting it up.
Please all interested parties add your name to the list.
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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2018-02-09 Thread Vaclav Petras 
Dear Nyall and all,

here are some of my thoughts mostly relating to GRASS GIS (although it may
not express views of the whole GRASS GIS developer team).

On Thu, Feb 8, 2018 at 8:55 PM, Nyall Dawson  wrote:
>
> Here's the situation as I see it:
>
> 
> The past
> ---
>
> We (the QGIS project) have struggled to keep a bunch of providers
> stable and available with the base QGIS install, and the current
> maintainers (Alex and Victor, others) have (understandably) struggled
> with the burden of maintaining these alone and the time commitment
> required to do so. Users have been frustrated by breakage which occurs
> when the algorithms they depend on break due to changes in underlying
> libraries for which the processing providers have not been adapted.
>
> Despite this, I'd say overall it's worked OK-ish up to now, but
> definitely with lots of room for improvement.
>
> -
> The goals
> -
>
> I think everyone involved is in agreement that processing's strength
> comes when there's many providers available and it's able to tie
> together processes regardless of which provider or library they come
> from. So I'd say our common goals are:
>
> 1. Encourage development of as many processing providers as possible
> 2. Make it easy for developers to create and maintain these providers
> 3. Make it easy for users to be able to use the providers
> 4. Make everything stable and painfree for users
>
> Any disagreements? No? Good ;)
>
> So if we agree that those are the end goals, we should be using them
> to drive this discussion.
>
> ---
> The questions
> ---
>
> The open, debatable questions are:
>
> - Which is the best approach for allowing easy maintenance of
> providers (*regardless* of whether the provider is maintained by the
> core QGIS team or a 3rd party)? Is it keeping the code in the master
> codebase and locking to QGIS releases, or publishing via plugins and
> having independent release schedules? Which approach will encourage
> more active maintenance of these providers and share the burden of
> this maintenance?

One thing is where to keep the code, however I'm not sure what code are we
talking about and I would like to talk about this first. I think that
recent post by Moritz is bringing this up as well:

https://lists.osgeo.org/pipermail/grass-dev/2018-February/087420.html

As far as I know, QGIS Processing has a text file for each GRASS module
describing its interface and maintenance of these takes time. However,
every GRASS module can tell about itself when called with
--interface-description parameter. If this is used, individual parameters
don't need to be maintained and any, even user provided module can be
executed in processing.

The --interface-description parameter gives XML which would need to be
converted or a new parameter, let's say --qgis-description, would need to
be added for a QGIS-specific format, there is for example --script for
GRASS GIS interface description for scripts. --qgis-description would need
to be in GRASS GIS code base while the conversion can be anywhere. See
emails from Rashad discussing a possible implementation with the
--qgis-description way and the OTB way:

https://lists.osgeo.org/pipermail/grass-dev/2018-February/087362.html
https://lists.osgeo.org/pipermail/grass-dev/2018-February/087390.html

The was discussed in the past and in fact, it is used in the QGIS GRASS
plugin as Radim explains in this older email:

https://lists.osgeo.org/pipermail/grass-dev/2015-March/074629.html

However, it is not using the --interface-description XML only, but it is
also using the qgm files to supply some additional information which means
that this system still requires updates which are separate from the updates
of GRASS modules. This can be avoided if the necessary information is
updated upstream or sometimes even GRASS --interface-description format or
the individual module descriptions are extended to include that what is
needed by QGIS Processing. Here is a thread which disuses this issues
although diverges into the following:

https://lists.osgeo.org/pipermail/grass-dev/2015-September/076138.html

One issue which is creating differences between QGIS Processing
representation of the module and the GRASS one is the issue of advanced
parameters. GRASS itself has mechanism to organize the parameters into
groups and marks the required ones. This is of course something which is
constantly being refined and it can be used and changed also for QGIS
Processing as discussed in this 2015 post:

https://lists.osgeo.org/pipermail/grass-dev/2015-December/078000.html

Other issues besides the interface include list of GRASS modules usable and
unusable in QGIS Processing, thematic tree of these modules, splitting
modules and more. Many of these are discussed in this recent post:

https://lists.osgeo.org/pipermail/grass-dev/2018-February/087388.html

One of the issues is issue of formats

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

2018-02-09 Thread Paolo Cavallini 
Il 09/02/2018 09:34, Rashad Kanavath ha scritto:
> I am giving up on this contribution as it seems impossible to get small
> changes like this.
> Thanks for all your time.

Hi Rashad,
please be patient: bear with us, and we'll find the most efficient
solution. In QGIS we have a very friendly environment, even when tech
discussion may seem harsh and lengthy. I'm sure there is ample room for
profitable cooperation.
All the best, and thanks for your work.

-- 
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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2018-02-09 Thread Rashad Kanavath 
On Thu, Feb 8, 2018 at 5:51 PM, Paolo Cavallini 
wrote:

> Il 08/02/2018 13:43, Rashad Kanavath ha scritto:
>
> > But aside all decision making stuff, can you check what is to be done in
> > this PR?
> > https://github.com/qgis/QGIS/pull/6272
> > It is something worthy a discussion and not a plugin or not. I was
> > asking because QGIS 3 is near and diff is not that big.
> > If there is something extra need to be done to get this merged, I would
> > happy to hear about it.
>
> agreed, this is an important and urgent point.
> please some qgis dev could check this?
> thanks.
>

I am giving up on this contribution as it seems impossible to get small
changes like this.
Thanks for all your time.


> --
> 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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2018-02-08 Thread Paolo Cavallini 
Il 08/02/2018 13:43, Rashad Kanavath ha scritto:

> But aside all decision making stuff, can you check what is to be done in
> this PR?
> https://github.com/qgis/QGIS/pull/6272
> It is something worthy a discussion and not a plugin or not. I was
> asking because QGIS 3 is near and diff is not that big.
> If there is something extra need to be done to get this merged, I would
> happy to hear about it.

agreed, this is an important and urgent point.
please some qgis dev could check this?
thanks.
-- 
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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2018-02-08 Thread Moritz Lennert 

On 08/02/18 13:43, Rashad Kanavath wrote:



On Thu, Feb 8, 2018 at 11:32 AM, Victor Olaya > wrote:


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. Users can install a plugin with the provider, and
then that provider can have the logic to automatically download OTB,
install it, or do whatever is needed in case OTB is not found
already installed.

I think is is good to educate our users a little bit. We are talking
about people that will be using complex algorithms for performing
advanced analysis. I guess we can expect that they can install a
plugin themselves and it is not a traumatic experience for them...
Looks like installing a separate plugin it's some sort of cruel
chinese torture...when it takes just 3 mouse clicks.

I agree with Giovanni, there is no need to provide something that
has everything installed out-of the box. Also, take into account
that reading the files that contain the algorithm descriptions takes
time (plus, there might be some additional checks performed when
populating the toolbox). People not doing analysis should not have
to suffer that extra loading time...


QGIS increases no of algorithms for a provider. It is simple as that. 
OTB has less than 80 applications and coming to QGIS, it will be 100 or 
150. (no interest to count them in qgis)
  And OTB was reading descriptor from xml which is going to be now csv 
like others.
Given all that info, I won't be surprised if it takes more time in 
future because of new algorithms added to providers. If QGIS was reading 
proper way or even open to accepting fixes.


The entire proposal/request to put back OTB was that decision was made 
on OLD code. when the update code is there, it has less problems.
Based on concerns raised by other developers no matter if you can fix 
it, they can't be put back. This single point was fueling this and other 
threads.
Also discussion wasn't started with "why no providers are included?". It 
was why some of them are removed even if there is an offer to help!


I don't care enough to continue this discussion about plugin or not plugin.



Warning: I don't claim any knowledge of the actual QGIS provider code, 
but I'm afraid that this is the case for many external SW developers, so 
please bear with me and correct me where I'm wrong.


However, I do have the feeling that part of the debate is due to 
fuzzyness of the actual subject. AFAIU, there a different issues here, 
and only if we clarify what we are talking about exactly, and what the 
actual issues are, can we advance. So, here's my understanding:


1) the descriptor files of the different algorithms in external SW

It seems that at least from OTB and GRASS side, willingness has been 
signaled to take over the handling of those.


2) the code that allows to launch these algorithms from within QGIS

IIUC this is again subdivided into two parts:

- a generic class within QGIS code for creating a provider
- the specific external SW related instances of these classes

The first part is definitely part of QGIS core.

The current debate (again AFAIU) is mostly about the second part. And 
one question linked to this is how much of the handling can be done by 
the generic class code, and how much is SW-specific. IOW, would it be 
possible to have exactly the same format of descriptor files for all SW, 
and a generic API to interpret those, or are the idiosyncrasies of the 
different SW such that API and descriptor files will have to be SW 
specific ?


A second question is how much within the second part (the SW specific 
provider) depends on evolutions of QGIS code, i.e. when QGIS moves from 
one version to the next, will the code in this part have to change, or 
will it remain stable, and how much depends on evolutions in the 
external SW code. If changes in external SW happen more often than it 
seems to make sense to keep this part of the code away from QGIS core, 
but if changes in QGIS happen more often than the opposite would seem 
better.


Another issue is that current expertise on how to code these providers 
is within the QGIS development team. If you decide to put these 
providers into plugins, _and_ to no longer ensure the maintenance of 
these plugins, this would mean that the development teams of the 
external SW have to acquire the necessary knowledge. Looking at general 
scarcity of human power in all of the teams, I'm not sure this will 
happen easily.


Do I understand things correctly ?

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2018-02-08 Thread Rashad Kanavath 
On Thu, Feb 8, 2018 at 11:32 AM, Victor Olaya  wrote:

>
>
>>
>> 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. Users can install a plugin with the provider, and then that
> provider can have the logic to automatically download OTB, install it, or
> do whatever is needed in case OTB is not found already installed.
>
> I think is is good to educate our users a little bit. We are talking about
> people that will be using complex algorithms for performing advanced
> analysis. I guess we can expect that they can install a plugin themselves
> and it is not a traumatic experience for them... Looks like installing a
> separate plugin it's some sort of cruel chinese torture...when it takes
> just 3 mouse clicks.
>
> I agree with Giovanni, there is no need to provide something that has
> everything installed out-of the box. Also, take into account that reading
> the files that contain the algorithm descriptions takes time (plus, there
> might be some additional checks performed when populating the toolbox).
> People not doing analysis should not have to suffer that extra loading
> time...
>

QGIS increases no of algorithms for a provider. It is simple as that. OTB
has less than 80 applications and coming to QGIS, it will be 100 or 150.
(no interest to count them in qgis)
 And OTB was reading descriptor from xml which is going to be now csv like
others.
Given all that info, I won't be surprised if it takes more time in future
because of new algorithms added to providers. If QGIS was reading proper
way or even open to accepting fixes.

The entire proposal/request to put back OTB was that decision was made on
OLD code. when the update code is there, it has less problems.
Based on concerns raised by other developers no matter if you can fix it,
they can't be put back. This single point was fueling this and other
threads.
Also discussion wasn't started with "why no providers are included?". It
was why some of them are removed even if there is an offer to help!

I don't care enough to continue this discussion about plugin or not plugin.

But aside all decision making stuff, can you check what is to be done in
this PR?
https://github.com/qgis/QGIS/pull/6272
It is something worthy a discussion and not a plugin or not. I was asking
because QGIS 3 is near and diff is not that big.
If there is something extra need to be done to get this merged, I would
happy to hear about it.


> About the R plugin not being available now...well, it's in a separate repo
> and can be adapted to QGIS 3, packaged and published. No one has taken care
> of that, it's true, but that only means we have no R support. If the R
> provider was be in core, it would mean that we would have a dead or
> malfunctioning provider being shipped with QGIS. That is a much worse
> option. And I dont see why, if someone is willing to fix that R provider,
> having it in core will make it easier.
>
> Cheers!
>



-- 
Regards,
   Rashad
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2018-02-08 Thread Rashad Kanavath 
On Thu, Feb 8, 2018 at 10:15 AM, Stefan Blumentrath <
stefan.blumentr...@nina.no> wrote:

> Hi,
>
> Regarding the negative effect of algorithms getting lost I fully agree
> with you Paolo.
>
> However, it might simplify the discussion if we try separate user
> experience and development (and packaging) solutions as well as means and
> ends...
>
> Aim should be to have the different back-ends available for user in a way
> that is as straight forward as possible. From my point of view that
> includes that possibly available providers are not hidden from users who
> just install bare QGIS. If they want to activate them, but don`t have the
> backends installed (and possibly a plugin) then they should get a notice
> that they have to install them (and I don`t see a problem with installing
> provider + plugin compared to just provider).
>

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.


> And if that sort of user experience is guaranteed I - as a user - would
> not care about where the code is maintained (in QGIS core, in the provider
> core, or in a separate plugin). My impression is that Victors arguments for
> an out-of-core solution are very valid, esp. given effects of the
> independent release cycles of the backends and QGIS on packaging needs (at
> least for the GRASS plugin).
> The only difference I see is that additional packages would be needed for
> a plugin solution. But that is probably not too bad or even an advantage...
>
> Finally, if there is interest in keeping the processing integration alive
> (and it obviously is) having it in an independent repo should not be a show
> stopper. Only negative effect I can see is that this produces additional
> repos, where access rights have to be managed. But that should not be a
> major issue either...
>
> Cheers
> Stefan
>
> P.S.: Just a pity that this discussion starts after medspx just put down
> all this work:
> https://github.com/qgis/QGIS/pull/5603
> https://github.com/qgis/QGIS/pull/5968
> https://github.com/qgis/QGIS/pull/5426
>
> -Original Message-
> From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of
> Paolo Cavallini
> Sent: torsdag 8. februar 2018 09.04
> To: G. Allegri <gioha...@gmail.com>
> Cc: qgis-developer <qgis-develo...@lists.osgeo.org>;
> saga-gis-develo...@lists.sourceforge.net; grass-dev <
> grass-dev@lists.osgeo.org>; Victor Olaya <vola...@gmail.com>
> Subject: Re: [GRASS-dev] [QGIS-Developer] External providers in QGIS
>
> Hi all,
> I disagree heartily: without GRASS and SAGA QGIS is currently unsuitable
> for serious, comprehensive GIS analysis work. Full stop.
> Missing one specific alg, even if not used daily, means having to switch
> to other software.
> We have already removed R provider: even if used by a tiny minority, and
> certainly not perfect, the previous situation was better than the current
> one, without the option of using R from QGIS.
> I think we have to be extra cautious on this ground.
> All the best.
>
> Il 07/02/2018 19:07, G. Allegri ha scritto:
>
> > - 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!
>
> --
> 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
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 
Regards,
   Rashad
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2018-02-08 Thread G. Allegri 
What I ment is that, from my perspective, we shouldn't seek to make QGIS a
do-it-all software by default, because the GIS/EO/RS/Data Analysis fields
are so wide that, from that point of view, everything could go into QGIS
and it would be an overwhelmin experience for users.
Any generic sw I know offers extensions, plugins, for specialized use
cases.  From my experience a user prefers few tools that match their needs,
instead of digging into a long list of (mostly) obscure algs...

Anyway, I don't want to stress on this...
Giovanni

2018-02-08 10:15 GMT+01:00 Stefan Blumentrath <stefan.blumentr...@nina.no>:

> Hi,
>
> Regarding the negative effect of algorithms getting lost I fully agree
> with you Paolo.
>
> However, it might simplify the discussion if we try separate user
> experience and development (and packaging) solutions as well as means and
> ends...
>
> Aim should be to have the different back-ends available for user in a way
> that is as straight forward as possible. From my point of view that
> includes that possibly available providers are not hidden from users who
> just install bare QGIS. If they want to activate them, but don`t have the
> backends installed (and possibly a plugin) then they should get a notice
> that they have to install them (and I don`t see a problem with installing
> provider + plugin compared to just provider).
>
> And if that sort of user experience is guaranteed I - as a user - would
> not care about where the code is maintained (in QGIS core, in the provider
> core, or in a separate plugin). My impression is that Victors arguments for
> an out-of-core solution are very valid, esp. given effects of the
> independent release cycles of the backends and QGIS on packaging needs (at
> least for the GRASS plugin).
> The only difference I see is that additional packages would be needed for
> a plugin solution. But that is probably not too bad or even an advantage...
>
> Finally, if there is interest in keeping the processing integration alive
> (and it obviously is) having it in an independent repo should not be a show
> stopper. Only negative effect I can see is that this produces additional
> repos, where access rights have to be managed. But that should not be a
> major issue either...
>
> Cheers
> Stefan
>
> P.S.: Just a pity that this discussion starts after medspx just put down
> all this work:
> https://github.com/qgis/QGIS/pull/5603
> https://github.com/qgis/QGIS/pull/5968
> https://github.com/qgis/QGIS/pull/5426
>
> -Original Message-
> From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of
> Paolo Cavallini
> Sent: torsdag 8. februar 2018 09.04
> To: G. Allegri <gioha...@gmail.com>
> Cc: qgis-developer <qgis-develo...@lists.osgeo.org>;
> saga-gis-develo...@lists.sourceforge.net; grass-dev <
> grass-dev@lists.osgeo.org>; Victor Olaya <vola...@gmail.com>
> Subject: Re: [GRASS-dev] [QGIS-Developer] External providers in QGIS
>
> Hi all,
> I disagree heartily: without GRASS and SAGA QGIS is currently unsuitable
> for serious, comprehensive GIS analysis work. Full stop.
> Missing one specific alg, even if not used daily, means having to switch
> to other software.
> We have already removed R provider: even if used by a tiny minority, and
> certainly not perfect, the previous situation was better than the current
> one, without the option of using R from QGIS.
> I think we have to be extra cautious on this ground.
> All the best.
>
> Il 07/02/2018 19:07, G. Allegri ha scritto:
>
> > - 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!
>
> --
> 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
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2018-02-08 Thread Stefan Blumentrath 
Hi,

Regarding the negative effect of algorithms getting lost I fully agree with you 
Paolo.

However, it might simplify the discussion if we try separate user experience 
and development (and packaging) solutions as well as means and ends...

Aim should be to have the different back-ends available for user in a way that 
is as straight forward as possible. From my point of view that includes that 
possibly available providers are not hidden from users who just install bare 
QGIS. If they want to activate them, but don`t have the backends installed (and 
possibly a plugin) then they should get a notice that they have to install them 
(and I don`t see a problem with installing provider + plugin compared to just 
provider).

And if that sort of user experience is guaranteed I - as a user - would not 
care about where the code is maintained (in QGIS core, in the provider core, or 
in a separate plugin). My impression is that Victors arguments for an 
out-of-core solution are very valid, esp. given effects of the independent 
release cycles of the backends and QGIS on packaging needs (at least for the 
GRASS plugin).
The only difference I see is that additional packages would be needed for a 
plugin solution. But that is probably not too bad or even an advantage...

Finally, if there is interest in keeping the processing integration alive (and 
it obviously is) having it in an independent repo should not be a show stopper. 
Only negative effect I can see is that this produces additional repos, where 
access rights have to be managed. But that should not be a major issue either...

Cheers
Stefan

P.S.: Just a pity that this discussion starts after medspx just put down all 
this work:
https://github.com/qgis/QGIS/pull/5603
https://github.com/qgis/QGIS/pull/5968
https://github.com/qgis/QGIS/pull/5426

-Original Message-
From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Paolo 
Cavallini
Sent: torsdag 8. februar 2018 09.04
To: G. Allegri <gioha...@gmail.com>
Cc: qgis-developer <qgis-develo...@lists.osgeo.org>; 
saga-gis-develo...@lists.sourceforge.net; grass-dev 
<grass-dev@lists.osgeo.org>; Victor Olaya <vola...@gmail.com>
Subject: Re: [GRASS-dev] [QGIS-Developer] External providers in QGIS

Hi all,
I disagree heartily: without GRASS and SAGA QGIS is currently unsuitable for 
serious, comprehensive GIS analysis work. Full stop.
Missing one specific alg, even if not used daily, means having to switch to 
other software.
We have already removed R provider: even if used by a tiny minority, and 
certainly not perfect, the previous situation was better than the current one, 
without the option of using R from QGIS.
I think we have to be extra cautious on this ground.
All the best.

Il 07/02/2018 19:07, G. Allegri ha scritto:

> - 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!

--
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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2018-02-08 Thread Rashad Kanavath 
On Wed, Feb 7, 2018 at 7:07 PM, G. Allegri  wrote:

> 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
>

Do you have these toolboxes installed during training? OTB, SAGA, GRASS
etc..
OTB is focused on remote sensing. Unless you have a training or course that
area, your statistics on them being not needed is pretty unreliable. Don't
you think?
What QGIS uses to run a classification/segmentation algorithm without OTB
and GRASS GIS.


> - 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-develo...@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 
Regards,
   Rashad
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2018-02-08 Thread Paolo Cavallini 
Hi all,
I disagree heartily: without GRASS and SAGA QGIS is currently unsuitable
for serious, comprehensive GIS analysis work. Full stop.
Missing one specific alg, even if not used daily, means having to switch
to other software.
We have already removed R provider: even if used by a tiny minority, and
certainly not perfect, the previous situation was better than the
current one, without the option of using R from QGIS.
I think we have to be extra cautious on this ground.
All the best.

Il 07/02/2018 19:07, G. Allegri ha scritto:

> - 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!

-- 
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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2018-02-07 Thread 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-develo...@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev