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

[Helmut Kudrnovsky]

pcav wrote
> Il 05/02/2018 22:03, Helmut Kudrnovsky ha scritto:
>> and see here for a follow up in the GRASS community:
>> 
>> http://osgeo-org.1560.x6.nabble.com/Keeping-GRASS-OTB-algorithm-in-qgis-processing-td5352828.html
>> http://osgeo-org.1560.x6.nabble.com/Re-GRASS-user-Keeping-GRASS-OTB-algorithm-in-qgis-processing-td5352836.html
> 
> Thank you Helmut. Following our PSC meeting, I'll start an open
> discussion with all parties involved. Looking forward for your input.
> I assumed GRASS-dev was the list to contact, but you sent it on
> GRASS-users, any special reason for this?
> 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@.osgeo

> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

And on the dev side, some ideas and discussions are floating around:

e.g.

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



-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
___
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] Keeping OTB algorithm in qgis processing

[Helmut Kudrnovsky]

Hi Paolo,


pcav wrote
> Il 05/02/2018 22:03, Helmut Kudrnovsky ha scritto:
>> and see here for a follow up in the GRASS community:
>> 
>> http://osgeo-org.1560.x6.nabble.com/Keeping-GRASS-OTB-algorithm-in-qgis-processing-td5352828.html
>> http://osgeo-org.1560.x6.nabble.com/Re-GRASS-user-Keeping-GRASS-OTB-algorithm-in-qgis-processing-td5352836.html
> 
> Thank you Helmut. Following our PSC meeting, I'll start an open
> discussion with all parties involved. Looking forward for your input.
> I assumed GRASS-dev was the list to contact, but you sent it on
> GRASS-users, any special reason for this?
> 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@.osgeo

> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

I sent it to GRASS users as it seems to me to be more a community issue than
a dev issue.

Thinking about/hearing to your user base helps you to improve decisions on
the dev side.

see 

https://trac.osgeo.org/grass/wiki/GSoC/2018#ImproveGRASSintegrationinQGIS3

as a starting point to a possible closer OSGeo inter-project communication
and collaboration.

Being an OSGeo GSoC/GCI admin now for some time, such opportunities or
similar to improve inter-project collaboration seem to be really under-used
at the moment. 

I'll start a new thread about the GSoC idea to attract new interested
people.






-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
___
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] Keeping OTB algorithm in qgis processing

[Paolo Cavallini]

Il 05/02/2018 22:03, Helmut Kudrnovsky ha scritto:
> and see here for a follow up in the GRASS community:
> 
> http://osgeo-org.1560.x6.nabble.com/Keeping-GRASS-OTB-algorithm-in-qgis-processing-td5352828.html
> http://osgeo-org.1560.x6.nabble.com/Re-GRASS-user-Keeping-GRASS-OTB-algorithm-in-qgis-processing-td5352836.html

Thank you Helmut. Following our PSC meeting, I'll start an open
discussion with all parties involved. Looking forward for your input.
I assumed GRASS-dev was the list to contact, but you sent it on
GRASS-users, any special reason for this?
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] Keeping OTB algorithm in qgis processing

[Helmut Kudrnovsky]

rashadkm wrote
> Hello all,
> 
> Here is a PR to allow integration of otb smoothly. tests are all passing,
> commits are squashed and ready to review.
> https://github.com/qgis/QGIS/pull/6272
> I did a small fix to control visibility of parameter from provider.
> Addition of specific parameter class for OTB is not included in this PR.
> 
> Thanks for feedback
> 
> On Mon, Feb 5, 2018 at 12:20 PM, Helmut Kudrnovsky 

> hellik@

>  wrote:
> 
>> >Otherwise if we don't care and just want to enable others to have QGIS
>> >intgration, they'll have to adopt the plugins.  That might work better
>> if
>> there
>> >is real interest.  But I think they usally prefer their tools to be used
>> in
>> >their own environment and don't care that much about whether it works in
>> QGIS
>> or not.  Is there solid interest of the SAGA or GRASS team to adopt
>> the
>  >providers?  Otherwise I guess they'll sooner or later will die.
>>
>> quickly screened the GRASS MLs, I can't find any entry that the GRASS
>> community was ever asked if there could be e.g. a shared attempt for an
>> automatization to create/maintain the plugin code.
>>
>> Looking at the new OSGeo website:
>>
>> *Desktop Applications*
>>
>> -QGIS Desktop
>> -GRASS GIS
>>
>> *Geospatial Libraries*
>>
>> -Orfeo ToolBox
>> -GDAL/OGR
>>
>> *Meta CRS Initiative*
>>
>> -PROJ4
>>
>> Most of the software mentioned in this thread are projects under the
>> common
>> umbrella of OSGeo.
>>
>> An option may be to ask that OSGeo plays a more proactive role in helping
>> to
>> coordinate and supporting (technically/financally/...) such inter-project
>> challenges.
>>
>> I will forward a short summary of this thread to the GRASS community.

and see here for a follow up in the GRASS community:

http://osgeo-org.1560.x6.nabble.com/Keeping-GRASS-OTB-algorithm-in-qgis-processing-td5352828.html
http://osgeo-org.1560.x6.nabble.com/Re-GRASS-user-Keeping-GRASS-OTB-algorithm-in-qgis-processing-td5352836.html




-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
___
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] Keeping OTB algorithm in qgis processing

[Paolo Cavallini]

Il 05/02/2018 18:00, Rashad Kanavath ha scritto:
> Hello all,
> 
> Here is a PR to allow integration of otb smoothly. tests are all
> passing, commits are squashed and ready to review.
> https://github.com/qgis/QGIS/pull/6272
> I did a small fix to control visibility of parameter from provider.
> Addition of specific parameter class for OTB is not included in this PR.

+1 for the general idea, pending a code review.
Thanks Rashad.

-- 
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] Keeping OTB algorithm in qgis processing

[Rashad Kanavath]

Hello all,

Here is a PR to allow integration of otb smoothly. tests are all passing,
commits are squashed and ready to review.
https://github.com/qgis/QGIS/pull/6272
I did a small fix to control visibility of parameter from provider.
Addition of specific parameter class for OTB is not included in this PR.

Thanks for feedback

On Mon, Feb 5, 2018 at 12:20 PM, Helmut Kudrnovsky  wrote:

> >Otherwise if we don't care and just want to enable others to have QGIS
> >intgration, they'll have to adopt the plugins.  That might work better if
> there
> >is real interest.  But I think they usally prefer their tools to be used
> in
> >their own environment and don't care that much about whether it works in
> QGIS
>  >providers?  Otherwise I guess they'll sooner or later will die.
>
> quickly screened the GRASS MLs, I can't find any entry that the GRASS
> community was ever asked if there could be e.g. a shared attempt for an
> automatization to create/maintain the plugin code.
>
> Looking at the new OSGeo website:
>
> *Desktop Applications*
>
> -QGIS Desktop
> -GRASS GIS
>
> *Geospatial Libraries*
>
> -Orfeo ToolBox
> -GDAL/OGR
>
> *Meta CRS Initiative*
>
> -PROJ4
>
> Most of the software mentioned in this thread are projects under the common
> umbrella of OSGeo.
>
> An option may be to ask that OSGeo plays a more proactive role in helping
> to
> coordinate and supporting (technically/financally/...) such inter-project
> challenges.
>
> I will forward a short summary of this thread to the GRASS community.
>
>
>
> -
> best regards
> Helmut
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-
> f4099106.html
> ___
> 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
>



-- 
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] Keeping OTB algorithm in qgis processing

[Helmut Kudrnovsky]

>Otherwise if we don't care and just want to enable others to have QGIS
>intgration, they'll have to adopt the plugins.  That might work better if
there
>is real interest.  But I think they usally prefer their tools to be used in
>their own environment and don't care that much about whether it works in
QGIS
providers?  Otherwise I guess they'll sooner or later will die. 

quickly screened the GRASS MLs, I can't find any entry that the GRASS
community was ever asked if there could be e.g. a shared attempt for an
automatization to create/maintain the plugin code.

Looking at the new OSGeo website:

*Desktop Applications*

-QGIS Desktop
-GRASS GIS

*Geospatial Libraries*

-Orfeo ToolBox
-GDAL/OGR

*Meta CRS Initiative*

-PROJ4

Most of the software mentioned in this thread are projects under the common
umbrella of OSGeo.

An option may be to ask that OSGeo plays a more proactive role in helping to
coordinate and supporting (technically/financally/...) such inter-project
challenges.

I will forward a short summary of this thread to the GRASS community.



-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
___
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] Keeping OTB algorithm in qgis processing

[Paolo Cavallini]

Il 04/02/2018 12:27, Rashad Kanavath ha scritto:

> If my proposal to keep otb provider in qgis was allowed, then it will be
> two simple steps. But I don't see that happening soon.

nothing is decided yet.

> Anyways, if the provider is a plugin or not, it is important to have api
> to show/hide widgets from algorithm dialog.( see my other mail on
> parameter groups)

I believe this would be useful for other backends too - what is your
opinion?

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] Keeping OTB algorithm in qgis processing

[Paolo Cavallini]

Hi Juergen,

Il 03/02/2018 16:02, Jürgen E. Fischer ha scritto:

> The question is who is the driving force behind the provider plugins.  If we
> want those algorithms in QGIS, we will probably have to maintain the plugins,
> if we don't want them to die.
> 
> Otherwise if we don't care and just want to enable others to have QGIS
> intgration, they'll have to adopt the plugins.  That might work better if 
> there
> is real interest.  But I think they usally prefer their tools to be used in
> their own environment and don't care that much about whether it works in QGIS
> or not.  Is there solid interest of the SAGA or GRASS team to adopt the
> providers?  Otherwise I guess they'll sooner or later will die.

agreed fully

> At the very least the packaging in OSGeo4W will have to adapted.  The easiest
> way would just to remove the dependencies.  This should also kill the current
> problem with the 2GB NSIS limit (GRASS depends on python2, SAGA has wxWidgets,
> OTB Qt4).
> 
> The plugins would be downloaded from within QGIS and instruct the user how
> install the rest of the binaries (eg. from OSGeo4W or other sites (like OTB)).

IMHO anything that does not work out of the box will be just
unaccessible for a large part of users. Standalone packages have been a
key of success for QGIS.
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



signature.asc
Description: OpenPGP digital signature
___
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] Keeping OTB algorithm in qgis processing

[Rashad Kanavath]

On Mon, Feb 5, 2018 at 7:31 AM, Alexander Bruy 
wrote:

> BTW, there is also another possible issue to consider. Where users
> will report tickets related to OTB algorithms and who will address
> them?


Come on!. Users already reports issue to OTB if that is the problem.
Do you know any bugs fixed in OTB processing by QGIS team?
To be fair, the processing plugin is in qgis.  And no matter how you
explain some users doesn't listen.
Are you saying this as a problem or something plugin would solve?


2018-02-05 5:43 GMT+02:00 Nyall Dawson :
> > On 4 February 2018 at 22:27, Rashad Kanavath 
> wrote:
> >
> >> Well, OTB provider plugin will be able to fetch and install otb
> binaries. So
> >> users installing plugin is the extra step needed.
> >> 1. Install QGIS
> >> 2. install otb provider plugin
> >> 3. select/download && install otb package
> >
> > This sounds great - and all the more reason why (in my opinion)
> > publishing the provider as a separate plugin is appropriate. A lot of
> > users will only have to make a couple of clicks and have a fully
> > functional OTB install and processing provider ready to go.
> >
> > On the other hand, I don't think this approach is suitable at all for
> > a core provider. What would you propose to do for Linux users? OTB may
> > or may not be available in their distro's repos (e.g. it's not
> > available for Fedora), so how would the plugin install the dependency
> > in this case? Or what about for Windows users who do not have
> > administrative rights to install software?
> >
> > I personally don't think there's any way to guarantee that OTB (or
> > SAGA for that matter) is available for all QGIS installs, even if we
> > can manually trigger a download and install via a plugin. And if they
> > aren't, then we make things harder for our users, QGIS trainers and
> > support providers -- the feature set of a standard QGIS install will
> > vary greatly depending on the platform it's installed upon and user's
> > privileges on that platform.
> >
> > 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
>
>
>
> --
> Alexander Bruy
>



-- 
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] Keeping OTB algorithm in qgis processing

[Paolo Cavallini]

Hi all,
sorry, I miss a point here: we have a dev who volunteers to maintain a
piece of code. He is quite credible. His proposal minimize the overhead
to QGIS code, and moves much of the complexity to an external sw.
Why do we suggest to keep him out of the door?
All the best.

Il 05/02/2018 06:31, Alexander Bruy ha scritto:
> BTW, there is also another possible issue to consider. Where users
> will report tickets related to OTB algorithms and who will address
> them?
> 
> 2018-02-05 5:43 GMT+02:00 Nyall Dawson :
>> On 4 February 2018 at 22:27, Rashad Kanavath  
>> wrote:
>>
>>> Well, OTB provider plugin will be able to fetch and install otb binaries. So
>>> users installing plugin is the extra step needed.
>>> 1. Install QGIS
>>> 2. install otb provider plugin
>>> 3. select/download && install otb package
>>
>> This sounds great - and all the more reason why (in my opinion)
>> publishing the provider as a separate plugin is appropriate. A lot of
>> users will only have to make a couple of clicks and have a fully
>> functional OTB install and processing provider ready to go.
>>
>> On the other hand, I don't think this approach is suitable at all for
>> a core provider. What would you propose to do for Linux users? OTB may
>> or may not be available in their distro's repos (e.g. it's not
>> available for Fedora), so how would the plugin install the dependency
>> in this case? Or what about for Windows users who do not have
>> administrative rights to install software?
>>
>> I personally don't think there's any way to guarantee that OTB (or
>> SAGA for that matter) is available for all QGIS installs, even if we
>> can manually trigger a download and install via a plugin. And if they
>> aren't, then we make things harder for our users, QGIS trainers and
>> support providers -- the feature set of a standard QGIS install will
>> vary greatly depending on the platform it's installed upon and user's
>> privileges on that platform.
>>
>> 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
> 
> 
> 


-- 
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] Keeping OTB algorithm in qgis processing

[Rashad Kanavath]

On Mon, Feb 5, 2018 at 4:43 AM, Nyall Dawson  wrote:

> On 4 February 2018 at 22:27, Rashad Kanavath 
> wrote:
>
> > Well, OTB provider plugin will be able to fetch and install otb
> binaries. So
> > users installing plugin is the extra step needed.
> > 1. Install QGIS
> > 2. install otb provider plugin
> > 3. select/download && install otb package
>
> This sounds great - and all the more reason why (in my opinion)
> publishing the provider as a separate plugin is appropriate. A lot of
> users will only have to make a couple of clicks and have a fully
> functional OTB install and processing provider ready to go.
>
> On the other hand, I don't think this approach is suitable at all for
> a core provider. What would you propose to do for Linux users? OTB may
> or may not be available in their distro's repos (e.g. it's not
> available for Fedora), so how would the plugin install the dependency
> in this case? Or what about for Windows users who do not have
> administrative rights to install software?
>

did you checked this package?
https://www.orfeo-toolbox.org//packages/OTB-6.4.0-Linux64.run
and others?
https://www.orfeo-toolbox.org//packages/

We don't need admin rights to install otb. just unzip and it works. Same
for mac and linux.
The dependency is libc and libc++ runtime. And I think any centos6 is our
reference platforms.

Issues you asked is why we introduced binary packages for OTB.


>
> I personally don't think there's any way to guarantee that OTB (or
> SAGA for that matter) is available for all QGIS installs, even if we
> can manually trigger a download and install via a plugin. And if they
> aren't, then we make things harder for our users, QGIS trainers and
> support providers -- the feature set of a standard QGIS install will
> vary greatly depending on the platform it's installed upon and user's
> privileges on that platform.
>
> Nyall
>



-- 
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] Keeping OTB algorithm in qgis processing

[Nyall Dawson]

On 4 February 2018 at 22:27, Rashad Kanavath  wrote:

> Well, OTB provider plugin will be able to fetch and install otb binaries. So
> users installing plugin is the extra step needed.
> 1. Install QGIS
> 2. install otb provider plugin
> 3. select/download && install otb package

This sounds great - and all the more reason why (in my opinion)
publishing the provider as a separate plugin is appropriate. A lot of
users will only have to make a couple of clicks and have a fully
functional OTB install and processing provider ready to go.

On the other hand, I don't think this approach is suitable at all for
a core provider. What would you propose to do for Linux users? OTB may
or may not be available in their distro's repos (e.g. it's not
available for Fedora), so how would the plugin install the dependency
in this case? Or what about for Windows users who do not have
administrative rights to install software?

I personally don't think there's any way to guarantee that OTB (or
SAGA for that matter) is available for all QGIS installs, even if we
can manually trigger a download and install via a plugin. And if they
aren't, then we make things harder for our users, QGIS trainers and
support providers -- the feature set of a standard QGIS install will
vary greatly depending on the platform it's installed upon and user's
privileges on that platform.

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] Keeping OTB algorithm in qgis processing

[Rashad Kanavath]

On Sat, Feb 3, 2018 at 5:02 PM, Jürgen E. Fischer  wrote:

> Hi Paolo,
>
> On Thu, 01. Feb 2018 at 11:57:28 +, Paolo Cavallini wrote:
> > Il 01/02/2018 11:51, Alexander Bruy ha scritto:
> > > IMHO, if it is really important for them, they should find a way to
> contact
> > > devs and support development.
>
> > > R provider was removed from core in May 2017 and as far as I can see
> nobody
> > > asked about it in mailing lists. So I suppose it is not important.
>
> > unfortunately users are often silent. but I agree, this is a way of
> > stimulating they reactions.
>
> I guess they'll start complaining once the find that GRASS and SAGA have
> been
> removed from the windows standalone.  Before hardly anyone will notice -
> just
> like nobody noticed that there were more hidden providers, because their
> dependencies were not installed and in turn nobody missed them, when they
> were
> removed again.
>
> The question is who is the driving force behind the provider plugins.  If
> we
> want those algorithms in QGIS, we will probably have to maintain the
> plugins,
> if we don't want them to die.
>
> Otherwise if we don't care and just want to enable others to have QGIS
> intgration, they'll have to adopt the plugins.  That might work better if
> there
> is real interest.  But I think they usally prefer their tools to be used in
> their own environment and don't care that much about whether it works in
> QGIS
> or not.  Is there solid interest of the SAGA or GRASS team to adopt the
> providers?  Otherwise I guess they'll sooner or later will die.
>
> At the very least the packaging in OSGeo4W will have to adapted.  The
> easiest
> way would just to remove the dependencies.  This should also kill the
> current
> problem with the 2GB NSIS limit (GRASS depends on python2, SAGA has
> wxWidgets,
> OTB Qt4).
>

Well, OTB provider plugin will be able to fetch and install otb binaries.
So users installing plugin is the extra step needed.
1. Install QGIS
2. install otb provider plugin
3. select/download && install otb package

If my proposal to keep otb provider in qgis was allowed, then it will be
two simple steps. But I don't see that happening soon.

Anyways, if the provider is a plugin or not, it is important to have api to
show/hide widgets from algorithm dialog.( see my other mail on parameter
groups)


>
> The plugins would be downloaded from within QGIS and instruct the user how
> install the rest of the binaries (eg. from OSGeo4W or other sites (like
> OTB)).
>
> There could also be processing provider plugin packages in OSGeo4W that
> have
> the providers and depend on available binaries there.  Although those
> packages
> would need to be available for all or a selection of qgis packages (qgis,
> qgis-rel-dev, qgis-ltr, qgis-ltr-dev and qgis-dev).
>
>
> Jürgen
>
> --
> Jürgen E. Fischer   norBIT GmbH Tel.
> +49-4931-918175-31
> Dipl.-Inf. (FH) Rheinstraße 13  Fax.
> +49-4931-918175-50
> Software Engineer   D-26506 Norden
> http://www.norbit.de
>
> ___
> 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
>



-- 
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] Keeping OTB algorithm in qgis processing

[Jürgen E . Fischer]

Hi Paolo,

On Thu, 01. Feb 2018 at 11:57:28 +, Paolo Cavallini wrote:
> Il 01/02/2018 11:51, Alexander Bruy ha scritto:
> > IMHO, if it is really important for them, they should find a way to contact
> > devs and support development.

> > R provider was removed from core in May 2017 and as far as I can see nobody
> > asked about it in mailing lists. So I suppose it is not important.
 
> unfortunately users are often silent. but I agree, this is a way of
> stimulating they reactions.

I guess they'll start complaining once the find that GRASS and SAGA have been
removed from the windows standalone.  Before hardly anyone will notice - just
like nobody noticed that there were more hidden providers, because their
dependencies were not installed and in turn nobody missed them, when they were
removed again.

The question is who is the driving force behind the provider plugins.  If we
want those algorithms in QGIS, we will probably have to maintain the plugins,
if we don't want them to die.

Otherwise if we don't care and just want to enable others to have QGIS
intgration, they'll have to adopt the plugins.  That might work better if there
is real interest.  But I think they usally prefer their tools to be used in
their own environment and don't care that much about whether it works in QGIS
or not.  Is there solid interest of the SAGA or GRASS team to adopt the
providers?  Otherwise I guess they'll sooner or later will die.

At the very least the packaging in OSGeo4W will have to adapted.  The easiest
way would just to remove the dependencies.  This should also kill the current
problem with the 2GB NSIS limit (GRASS depends on python2, SAGA has wxWidgets,
OTB Qt4).

The plugins would be downloaded from within QGIS and instruct the user how
install the rest of the binaries (eg. from OSGeo4W or other sites (like OTB)).

There could also be processing provider plugin packages in OSGeo4W that have
the providers and depend on available binaries there.  Although those packages
would need to be available for all or a selection of qgis packages (qgis,
qgis-rel-dev, qgis-ltr, qgis-ltr-dev and qgis-dev).


Jürgen

-- 
Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
Software Engineer   D-26506 Norden http://www.norbit.de


signature.asc
Description: PGP signature
___
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] Keeping OTB algorithm in qgis processing

[Pedro Venâncio]

 Hi all,

I think this new approach is more or less the same approach used in the
early times of Sextante, before it is ported to QGIS core and become
Processing.

I remember that Sextante at that time had a very good feature, being an
external plugin, that was the updates. They were not dependent of the QGIS
release schedule, and so bugs were solved and new versions made available
very quickly.

Having the providers as plugins, we will regain this flexibility. The
counterpart is that there may be providers that may no longer exist in
Processing, due to lack of workforce. But getting them integrated, without
this workforce, lacking maintenance, is not a good idea either.

So I think this new approach, taking pros and cons, might work well.

I understand Rashad who thinks it would be better to have all providers,
out-of-the-box, after installing QGIS, but we can not get the best of both
worlds in just one. And it seems to me, that OTB's integration into QGIS is
assured, at least as much as it depends on Rashad's will!

Best regards,
Pedro




2018-02-02 11:11 GMT+00:00 Paolo Cavallini :

> Hi Rashad,
>
> Il 02/02/2018 10:47, Rashad Kanavath ha scritto:
>
> > A user of application can select -type gaussian -type.gaussian.radius 3
> > when launching application.
> > otb application check for invalid cases such as if type is gaussian then
> > one cannot use -type.mean.radius
> > This is okay for command line, but for graphical interface one has to
> > hide /show parameters based on the value of it's parent.
> >
> > This is a limitation of qgis processing that upstream was forced to
> > split applications based on group. I am not blaming or targeting here.
> > Just saying about a missing feature for support for one provider.
>
> Very interesting. Wouldn't make sense to have it upstream? This would be
> useful also for other providers.
>
> >  QGIS users now have three application for smoothing and maybe 10 or
> > more application for TrainImagesClassifer.
>
> This was originally made on purpose, with the idea of having simplified
> atomic commands. Nowe the ecosystem is more riche, and there is room for
> more complex interfaces.
>
> Thanks for your input.
>
> --
> 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] Keeping OTB algorithm in qgis processing

[Paolo Cavallini]

Hi Rashad,

Il 02/02/2018 10:47, Rashad Kanavath ha scritto:

> A user of application can select -type gaussian -type.gaussian.radius 3
> when launching application.
> otb application check for invalid cases such as if type is gaussian then
> one cannot use -type.mean.radius
> This is okay for command line, but for graphical interface one has to
> hide /show parameters based on the value of it's parent.
> 
> This is a limitation of qgis processing that upstream was forced to
> split applications based on group. I am not blaming or targeting here.
> Just saying about a missing feature for support for one provider.

Very interesting. Wouldn't make sense to have it upstream? This would be
useful also for other providers.

>  QGIS users now have three application for smoothing and maybe 10 or
> more application for TrainImagesClassifer. 

This was originally made on purpose, with the idea of having simplified
atomic commands. Nowe the ecosystem is more riche, and there is room for
more complex interfaces.

Thanks for your input.

-- 
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] Keeping OTB algorithm in qgis processing

[Rashad Kanavath]

On Fri, Feb 2, 2018 at 12:36 AM, Nyall Dawson 
wrote:

> On 1 February 2018 at 20:01, Rashad Kanavath 
> wrote:
> > Hello,
> >
> > Processing plugin allows to integrate other toolboxes. IIUC, this was
> one of
> > the features of it.
> > So when you say integration of so and so toolboxes are total mess, you
> might
> > think back.
>
> I think there's a misunderstanding/language barrier at play here -
> no-one meant that the code is a mess, just that the end result of the
> QGIS team trying to maintain 3rd party providers resulted in an
> inferior experience all round - for users, qgis developers AND the
> underlying library developers (whom I'm sure don't appreciate being
> blamed when a QGIS processing algorithm is mis-using their API).
>
>
Can you elaborate on this QGIS processing algorithm mis-using API ?


> Yes, one of Processing's big strengths is its ability to integrate
> other toolboxes and make 3rd party libraries accessible within the
> QGIS environment and tie them together into models. Another one of
> QGIS' great strengths is its strong plugin ecosystem, which allows
> anyone the ability to create plugins and extend QGIS, and not be tied
> into the core QGIS development practices and release schedules. That's
> why plugin-based providers are the BEST solution in my opinion.
>
> > Nobody had seen new changes to otb algs so all of your comments are on
> old
> > version.  Why so rush?
> > Okay, it easy to reject stating the same reason over and over again. I
> > understand that.
>
> Just to be clear - no-one is commenting on your code quality or
> targeting OTB specifically. It's the question of whether or not
> Processing providers which depend on other libraries should be
> included in the main install or moved to plugins which we are
> debating. So please, don't take any of this as criticism of your code
> or (much appreciated) efforts.
>

I never said you commented on code quality. I said everyone should comment
on new code.
But there are comments and or decisions made on old one  codebase even the
thread started with updating and cleaning up stuff.
And I did said that all your comments about that is valid and reasonable.

Hence, I suggested that to see if all your points to keep providers out
still stands with new code. (not done yet)
For SAGA and others, I cannot speak much because I am not involved in it.
so if it feels like I was targeting OTB, this was not against anything.
But I guess saga or even grass is not planning for similar support for qgis
provider like OTB.
 And maybe this is the case for R and others. So that make sense to remove
it from plugin.

If there is one plugin provider which has mostly code tied to processing
then it will be easy for QGIS.
Consider this, OTB plugin was moved out of qgis some time ago and after
that came a lot of changes to qgis processing.
change of parameter names, moving code to c++ etc.. Now GRASS, SAGA etc got
all these changes because it was in tree.
I understand the idea behind removing otb. If this provider wasn't such a
mess to maintain it would have stayed. Even though it
attains the same complexity level as others. I don't agree that it should
be so complex.

And IMHO, the point being this providers are hard to maintain itself lies
with processing plugin and not individual providers or qgis core.
Be it OTB, GRASS , SAGA or anything.


> > What happens at end, a processing plugin with zero providers?
>
> Far from it. My vision would be:
>
> - core install: only includes the native QGIS providers (c++, Python
> and 3D) and the GDAL/OGR provider (since it's impossible to build QGIS
> without GDAL we can be 100% sure that it's always available wherever
> QGIS is installed). Maybe GRASS provider too, since GRASS is very
> heavily linked into QGIS due to the GRASS provider and c++ GRASS
> plugin.

In case of GDAL, I agree. But I (and many other users) don't have GRASS and
SAGA installed.
So this is some kind of assumption that I cannot fully agree. GRASS
provider still has all of descriptor for grass7 in your tree.
And this was/is the case of OTB for now. New changes will not need a
descriptor file in your tree.
OTB installation will provide a descriptor file in the format needed by
qgis processing!

>

- via QGIS' plugin ecosystem: a whole world of providers ready to
> install for users, including SAGA, OTB, lastools, R, PySAL, etc...
>
>
Yes. most of the concern was more with installation of external tools for
users.
>From this and other threads, keeping processing providers outside was not
related to amount or quality code or targetted at specific tool.
Just that it requires external tools. We understand that totally. But what
we don't agree is your assumption that so and so tools is already for most
of qgis users.
Even if grass or saga is installed, one has to configure it to use. So the
problem of installing something for users seems to be key here.
Now GDAL is not considered an external 

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

[Paolo Cavallini]

Il 01/02/2018 17:18, Jürgen E. Fischer ha scritto:
> Hi Paolo,
> 
> On Thu, 01. Feb 2018 at 11:04:58 +, Paolo Cavallini wrote:
>> Il 01/02/2018 11:01, Rashad Kanavath ha scritto:
>>> I think jef can do this part. I don't have access to repo
>  
>> OK, thanks. Could you please open a ticket on osgeo4w tracker?
> 
> No need.  otb has been marked _obsolete in OSGeo4W.

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



signature.asc
Description: OpenPGP digital signature
___
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] Keeping OTB algorithm in qgis processing

[Nyall Dawson]

On 1 February 2018 at 20:01, Rashad Kanavath  wrote:
> Hello,
>
> Processing plugin allows to integrate other toolboxes. IIUC, this was one of
> the features of it.
> So when you say integration of so and so toolboxes are total mess, you might
> think back.

I think there's a misunderstanding/language barrier at play here -
no-one meant that the code is a mess, just that the end result of the
QGIS team trying to maintain 3rd party providers resulted in an
inferior experience all round - for users, qgis developers AND the
underlying library developers (whom I'm sure don't appreciate being
blamed when a QGIS processing algorithm is mis-using their API).

Yes, one of Processing's big strengths is its ability to integrate
other toolboxes and make 3rd party libraries accessible within the
QGIS environment and tie them together into models. Another one of
QGIS' great strengths is its strong plugin ecosystem, which allows
anyone the ability to create plugins and extend QGIS, and not be tied
into the core QGIS development practices and release schedules. That's
why plugin-based providers are the BEST solution in my opinion.

> Nobody had seen new changes to otb algs so all of your comments are on old
> version.  Why so rush?
> Okay, it easy to reject stating the same reason over and over again. I
> understand that.

Just to be clear - no-one is commenting on your code quality or
targeting OTB specifically. It's the question of whether or not
Processing providers which depend on other libraries should be
included in the main install or moved to plugins which we are
debating. So please, don't take any of this as criticism of your code
or (much appreciated) efforts.

> What happens at end, a processing plugin with zero providers?

Far from it. My vision would be:

- core install: only includes the native QGIS providers (c++, Python
and 3D) and the GDAL/OGR provider (since it's impossible to build QGIS
without GDAL we can be 100% sure that it's always available wherever
QGIS is installed). Maybe GRASS provider too, since GRASS is very
heavily linked into QGIS due to the GRASS provider and c++ GRASS
plugin.
- via QGIS' plugin ecosystem: a whole world of providers ready to
install for users, including SAGA, OTB, lastools, R, PySAL, etc...

> Now the reason OTB had to maintain list of "supported" version is due the
> fact that processing plugin does not allow to group parameters.
> So the issue of a provider being total mess not fully related to provider
> itself. If 90% of provider algorithm which you use, cannot be even
> integrated into processing where will be the actual problem. I see a lot of
> good changes in qgis processing and providers can greatly benefit from it
> now.

Can you elaborate on this please? I'm not aware what the "group
parameters" issue is.

> All those people blindly rejecting this proposal should have waited for new
> changes.
> I mean, I just put a proposal to lower the burden as much as possible. And
> all those issues raised by Alex, Nyall and others will be considered in the
> new diff.
> Once I prepare changes, you can reject it!. You are voting -1ss on old
> plugin code something I consider a mess to work with for both teams.

Why? In the past we've always found that discussing plans upfront
benefits everyone and prevents development effort in an approach which
won't be accepted upstream.

In summary, can you please outline the reasons why you think
publishing this as a plugin is not ideal?

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] Keeping OTB algorithm in qgis processing

[Jürgen E . Fischer]

Hi Paolo,

On Thu, 01. Feb 2018 at 11:04:58 +, Paolo Cavallini wrote:
> Il 01/02/2018 11:01, Rashad Kanavath ha scritto:
> > I think jef can do this part. I don't have access to repo
 
> OK, thanks. Could you please open a ticket on osgeo4w tracker?

No need.  otb has been marked _obsolete in OSGeo4W.


Jürgen

-- 
Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
Software Engineer   D-26506 Norden http://www.norbit.de


signature.asc
Description: PGP signature
___
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] Keeping OTB algorithm in qgis processing

[Paolo Cavallini]

Il 01/02/2018 12:13, Alexander Bruy ha scritto:
> Hi Giovanni,
> 
> my point was that we still can not maintain hundreds of algorithms.

well, we did, more or less efficiently, until now.
I understand your point, however.
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] Keeping OTB algorithm in qgis processing

[Alexander Bruy]

Hi Giovanni,

my point was that we still can not maintain hundreds of algorithms.

2018-02-01 14:08 GMT+02:00 Giovanni Manghi :
> Hi Alex,
>
>> I'm afraid it is not true, there are lot of issue even with LTR SAGA, see
>> for example https://issues.qgis.org/issues/17726. There are also some
>> recent threads in developers mailing list about broked SAGA and GRASS
>> modules.
>
> ok is not perfect :) but is for sure is much better compared when we
> tried to keep the pace with SAGA changes.
>
> -- G --



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

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

[Giovanni Manghi]

Hi Alex,

> I'm afraid it is not true, there are lot of issue even with LTR SAGA, see
> for example https://issues.qgis.org/issues/17726. There are also some
> recent threads in developers mailing list about broked SAGA and GRASS
> modules.

ok is not perfect :) but is for sure is much better compared when we
tried to keep the pace with SAGA changes.

-- G --
___
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] Keeping OTB algorithm in qgis processing

[Paolo Cavallini]

Il 01/02/2018 11:51, Alexander Bruy ha scritto:
> IMHO, if it is really important for them, they should find a way
> to contact devs and support development.
> 
> R provider was removed from core in May 2017 and as far as I can see
> nobody asked about it in mailing lists. So I suppose it is not important.

unfortunately users are often silent. but I agree, this is a way of
stimulating they reactions.
perhaps we could accompany this with a crewdfunding campaing, or anyway
with a wider announcement "if you want it, do something for it".
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
___
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] Keeping OTB algorithm in qgis processing

[Alexander Bruy]

IMHO, if it is really important for them, they should find a way
to contact devs and support development.

R provider was removed from core in May 2017 and as far as I can see
nobody asked about it in mailing lists. So I suppose it is not important.

2018-02-01 13:40 GMT+02:00 Paolo Cavallini :
> Il 01/02/2018 11:37, Alexander Bruy ha scritto:
>
>> I'm not a bit R fan and user, so updating this provider to QGIS 3 for me is
>> lower priority then updating other plugins or doing some work on QGIS core.
>
> quite understandable, nobody could possibly blame you.
> the fact remains that before removal users were able to do stuff in R
> from QGIS, and now they can't.
> IMHO we should avoid the same for GRASS and SAGA.
> All the best, and 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



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

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

[Paolo Cavallini]

Il 01/02/2018 11:37, Alexander Bruy ha scritto:

> I'm not a bit R fan and user, so updating this provider to QGIS 3 for me is
> lower priority then updating other plugins or doing some work on QGIS core.

quite understandable, nobody could possibly blame you.
the fact remains that before removal users were able to do stuff in R
from QGIS, and now they can't.
IMHO we should avoid the same for GRASS and SAGA.
All the best, and 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
___
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] Keeping OTB algorithm in qgis processing

[Alexander Bruy]

2018-02-01 12:59 GMT+02:00 Paolo Cavallini :
> and also R provider, which if I understand correctly is orphaned now.
> all the best.

Well, to be precise it did not received much attention from its inclusion into
core, there were tickets filed for this Provider which was not addressed for
years, e.g. issues with R plots, handling different types of parameters.

I'm not a bit R fan and user, so updating this provider to QGIS 3 for me is
lower priority then updating other plugins or doing some work on QGIS core.

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

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

[Alexander Bruy]

2018-02-01 13:22 GMT+02:00 Giovanni Manghi :
> After having decided to support only SAGA LTR (because we know we can't keep 
> the
> pace with non LTR SAGA underlying changes) we are now finally at a
> point (at least in QGIS 2.18) where users can reliably count with this
> tools.

I'm afraid it is not true, there are lot of issue even with LTR SAGA, see
for example https://issues.qgis.org/issues/17726. There are also some
recent threads in developers mailing list about broked SAGA and GRASS
modules.


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

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

[Paolo Cavallini]

Il 01/02/2018 11:01, Rashad Kanavath ha scritto:

> I think jef can do this part. I don't have access to repo

OK, thanks. Could you please open a ticket on osgeo4w tracker?
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
___
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] Keeping OTB algorithm in qgis processing

[Rashad Kanavath]

On Thu, Feb 1, 2018 at 11:57 AM, Paolo Cavallini 
wrote:

> Il 01/02/2018 09:35, Rashad Kanavath ha scritto:
> > OTB is not using ogeo4w for a long time. So OSGeo4W users are stuck on
> > old version. We have zero interest in pushing packages back again
> > Windows users can use otb from its binary package, build from source ,
> > or maintain osgeo4w or whatever seems interest.
>
> Thanks Rashad for clarifying. In this case, I'd strongly advise removing
> OTB from osgeo4w ASAP.
> Could you or Julien please do it?
>

I think jef can do this part. I don't have access to repo


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



-- 
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] Keeping OTB algorithm in qgis processing

[Paolo Cavallini]

Il 01/02/2018 10:16, Alexander Bruy ha scritto:

> code already here:
>  - grass 
> https://github.com/qgis/QGIS/tree/master/python/plugins/processing/algs/grass7
>  - saga 
> https://github.com/qgis/QGIS/tree/master/python/plugins/processing/algs/saga
> 
> Only small updates are needed to turn it into plugins. I can turn them
> into plugins and
> publish if there is an agreement about this approach. Then I will be
> happy to transfer
> ownership to any interested person.
> 
> Some documentation about adding new algorithms to GRASS provider can be found
> in 
> https://github.com/qgis/QGIS/blob/master/python/plugins/processing/algs/grass7/grass7.txt,
> but it is slightly outdated. Same approach used for SAGA.

I agree that, in case we decide to follow this route, publishing a first
version of the providers and having a reasonably complete documentation
on how to proceed is crucial for the future of the providers.
All the best, and of course thanks Alex and others for your work on this!
-- 
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] Keeping OTB algorithm in qgis processing

[Paolo Cavallini]

Il 01/02/2018 10:00, Alexander Bruy ha scritto:

> Exactly in the same way we removed LiDAR tools provider (now
> maintained by Martin Isenburg)
> and TauDEM provider (maintained by me, along with several others
> Processing providers).

and also R provider, which if I understand correctly is orphaned now.
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] Keeping OTB algorithm in qgis processing

[Paolo Cavallini]

Il 01/02/2018 09:35, Rashad Kanavath ha scritto:
> OTB is not using ogeo4w for a long time. So OSGeo4W users are stuck on
> old version. We have zero interest in pushing packages back again
> Windows users can use otb from its binary package, build from source ,
> or maintain osgeo4w or whatever seems interest.

Thanks Rashad for clarifying. In this case, I'd strongly advise removing
OTB from osgeo4w ASAP.
Could you or Julien please do it?
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] Keeping OTB algorithm in qgis processing

[Alexander Bruy]

Hi Werner,

code already here:
 - grass 
https://github.com/qgis/QGIS/tree/master/python/plugins/processing/algs/grass7
 - saga 
https://github.com/qgis/QGIS/tree/master/python/plugins/processing/algs/saga

Only small updates are needed to turn it into plugins. I can turn them
into plugins and
publish if there is an agreement about this approach. Then I will be
happy to transfer
ownership to any interested person.

Some documentation about adding new algorithms to GRASS provider can be found
in 
https://github.com/qgis/QGIS/blob/master/python/plugins/processing/algs/grass7/grass7.txt,
but it is slightly outdated. Same approach used for SAGA.

2018-02-01 12:07 GMT+02:00 Werner Macho :
> Hi Alex,
>
> Thats exactly what I meant.
> I know that (currently) there are no plugin for SAGA and GRASS but if I
> understood everything correctly the point is to create such plugins.
> My Question was more or less if there is already code existing for it or if
> we have to wait until they are removed before the plugins can appear - but
> this is now answered.
>
> Waiting for the plugins ;)
> And hopefully good documentation howto bring new algorithms alive..
>
> thanks and kind regards
> Werner
>
>
>
> On Thu, Feb 1, 2018 at 11:00 AM, Alexander Bruy 
> wrote:
>>
>> Hi Werner,
>>
>> there are no plugins for SAGA and GRASS, but this is just because they
>> are in core.
>> Also seems we need to clarify, removal from core does not means wiping
>> all stuff,
>> this just mean that existing code will be separated into plugin and
>> published on GitHub
>> and QGIS plugins repository. Then interested people can take ownership
>> and continue
>> development and maintenance.
>>
>> Exactly in the same way we removed LiDAR tools provider (now
>> maintained by Martin Isenburg)
>> and TauDEM provider (maintained by me, along with several others
>> Processing providers).
>>
>> 2018-02-01 10:39 GMT+02:00 Werner Macho :
>> > Hi all,
>> >
>> > I am also in favour of removing all the work that is not directly
>> > related to
>> > QGIS.
>> > But I'd also like to ask if there is already a plugin available (on
>> > github?)
>> > that for e.g. readds the GRASS functionality?
>> > Furthermore I'd like to know if it is possible to create a plugin for
>> > official stable GRASS and GRASS development version, which in the best
>> > case
>> > can be installed side by side?
>> > (Same applies to SAGA and all the other providers).
>> >
>> > I am sure there is a huge possibility that an ecosystem will be created
>> > around those kind of plugins.
>> >
>> > kind regards
>> > Werner
>> >
>> > On Thu, Feb 1, 2018 at 9:33 AM, G. Allegri  wrote:
>> >>
>> >> +1 also from me to the removal of the providers from core. IMHO I would
>> >> also remove GRASS, but I understand it could be a tough decision.
>> >> The provider system + plugin architecture provide all the means to keep
>> >> them separate from the core.
>> >>
>> >> We all agree, I guess, that less is better then more, to guarantee the
>> >> highest quality we can afford.
>> >>
>> >> Giovanni
>> >>
>> >> Il 1 feb 2018 09:23, "Paolo Cavallini"  ha
>> >> scritto:
>> >>>
>> >>> Hi Rashad,
>> >>>
>> >>> Il 31/01/2018 10:43, Rashad Kanavath ha scritto:
>> >>>
>> >>> > What I can propose is to lower the burden on maintenance but the
>> >>> > code
>> >>> > should be put back to qgis if possible.
>> >>> > So qgis can focus on issue related only to that and after a while
>> >>> > things
>> >>> > will stabilize.
>> >>> >
>> >>> > Indeed, if there is something broken in this algo otb team will help
>> >>> > fix it.
>> >>>
>> >>> thanks for your offer, much appreciated. Would this include also the
>> >>> inclusion of OTB in the standalone installers for Windows? It would be
>> >>> good to make sure we always have the most appropriate version, both
>> >>> for
>> >>> 32 and 64 bit.
>> >>> 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
>> >
>> >
>> >
>> > ___
>> > QGIS-Developer mailing list
>> > QGIS-Developer@lists.osgeo.org
>> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> > Unsubscribe: 

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

[Werner Macho]

Hi Alex,

Thats exactly what I meant.
I know that (currently) there are no plugin for SAGA and GRASS but if I
understood everything correctly the point is to create such plugins.
My Question was more or less if there is already code existing for it or if
we have to wait until they are removed before the plugins can appear - but
this is now answered.

Waiting for the plugins ;)
And hopefully good documentation howto bring new algorithms alive..

thanks and kind regards
Werner



On Thu, Feb 1, 2018 at 11:00 AM, Alexander Bruy 
wrote:

> Hi Werner,
>
> there are no plugins for SAGA and GRASS, but this is just because they
> are in core.
> Also seems we need to clarify, removal from core does not means wiping
> all stuff,
> this just mean that existing code will be separated into plugin and
> published on GitHub
> and QGIS plugins repository. Then interested people can take ownership
> and continue
> development and maintenance.
>
> Exactly in the same way we removed LiDAR tools provider (now
> maintained by Martin Isenburg)
> and TauDEM provider (maintained by me, along with several others
> Processing providers).
>
> 2018-02-01 10:39 GMT+02:00 Werner Macho :
> > Hi all,
> >
> > I am also in favour of removing all the work that is not directly
> related to
> > QGIS.
> > But I'd also like to ask if there is already a plugin available (on
> github?)
> > that for e.g. readds the GRASS functionality?
> > Furthermore I'd like to know if it is possible to create a plugin for
> > official stable GRASS and GRASS development version, which in the best
> case
> > can be installed side by side?
> > (Same applies to SAGA and all the other providers).
> >
> > I am sure there is a huge possibility that an ecosystem will be created
> > around those kind of plugins.
> >
> > kind regards
> > Werner
> >
> > On Thu, Feb 1, 2018 at 9:33 AM, G. Allegri  wrote:
> >>
> >> +1 also from me to the removal of the providers from core. IMHO I would
> >> also remove GRASS, but I understand it could be a tough decision.
> >> The provider system + plugin architecture provide all the means to keep
> >> them separate from the core.
> >>
> >> We all agree, I guess, that less is better then more, to guarantee the
> >> highest quality we can afford.
> >>
> >> Giovanni
> >>
> >> Il 1 feb 2018 09:23, "Paolo Cavallini"  ha
> scritto:
> >>>
> >>> Hi Rashad,
> >>>
> >>> Il 31/01/2018 10:43, Rashad Kanavath ha scritto:
> >>>
> >>> > What I can propose is to lower the burden on maintenance but the code
> >>> > should be put back to qgis if possible.
> >>> > So qgis can focus on issue related only to that and after a while
> >>> > things
> >>> > will stabilize.
> >>> >
> >>> > Indeed, if there is something broken in this algo otb team will help
> >>> > fix it.
> >>>
> >>> thanks for your offer, much appreciated. Would this include also the
> >>> inclusion of OTB in the standalone installers for Windows? It would be
> >>> good to make sure we always have the most appropriate version, both for
> >>> 32 and 64 bit.
> >>> 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
> >
> >
> >
> > ___
> > 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
>
>
>
> --
> 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

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

[Rashad Kanavath]

Hello,

Processing plugin allows to integrate other toolboxes. IIUC, this was one
of the features of it.
So when you say integration of so and so toolboxes are total mess, you
might think back.

Nobody had seen new changes to otb algs so all of your comments are on old
version.  Why so rush?
Okay, it easy to reject stating the same reason over and over again. I
understand that.
What happens at end, a processing plugin with zero providers?

Now the reason OTB had to maintain list of "supported" version is due the
fact that processing plugin does not allow to group parameters.
So the issue of a provider being total mess not fully related to provider
itself. If 90% of provider algorithm which you use, cannot be even
integrated into processing where will be the actual problem. I see a lot of
good changes in qgis processing and providers can greatly benefit from it
now.

All those people blindly rejecting this proposal should have waited for new
changes.
I mean, I just put a proposal to lower the burden as much as possible. And
all those issues raised by Alex, Nyall and others will be considered in the
new diff.
Once I prepare changes, you can reject it!. You are voting -1ss on old
plugin code something I consider a mess to work with for both teams.

My initial question was only to see if there are other issues than the
maintenance overhead?
By now, I conclude that only issue was maintenance overhead and I proposed
it can be solved.


On Thu, Feb 1, 2018 at 12:17 AM, Nyall Dawson 
wrote:

> On 31 January 2018 at 20:23, Alexander Bruy 
> wrote:
> > Another reason to remove providers is that algorithms descriptions
> > were not updated and maintained. Even now both SAGA and GRASS
> > providers are not updated to latest stable versions of the corresponding
> > software.
> >
> > We just simply does not have enough resources to maintain more than
> > 600 algorithms from GRASS and SAGA. Situation with OTB, was even
> > worse, it requires special handling of the parameters.
> >
> > I still think that Processing should be in core with minimal set of
> algorithms
> > (native and GDAL), all other providers should be plugins and installed by
> > users. Ideally these providers also should be maintained by interested
> groups
> > of devs/users, not by QGIS devs.
>
> A big +1 to everything Alex said above, and a strong -1 to
> reintroducing any of these providers back to master (and also a +1 to
> shifting the SAGA provider to a non-default plugin).
>
> My reasons:
>
> - we have a very strong plugin infrastructure designed EXACTLY for
> these use cases. Having these providers as separate plugins, free from
> the QGIS release cycle makes a ton of sense. Plugins devs can then
> push new versions of their providers whenever new versions of the
> underlying libraries are available, and not be constrained by waiting
> until the next QGIS release.
>
> - years of experience has PROVEN that we do not have the capacity to
> maintain these providers ourselves. Numerous developers have tried,
> and just been swamped by the amount of work required to keep the
> providers stable while the underlying libraries change. The QGIS team
> is running at capacity just keeping QGIS maintained and stable - we
> CANNOT take on this extra work.


> - regardless of the approach taken, things just don't stay stable for
> us. E.g. we tried to make the SAGA provider more stable by only
> targeting the SAGA LTR release yet the SAGA upstream seem to have
> abandoned the LTR, leaving it totally broken on newer build chains. I
> cannot get SAGA LTR to run on my development platform (Fedora) as it
> constantly segfaults. End result - even if I had the time to maintain
> this provider, I would be totally unable to. (For this reason I think
> SAGA should also be moved to a separate QGIS plugin, leaving on QGIS,
> GDAL and GRASS provided in the default install. GDAL and GRASS
> (mostly) are always available wherever QGIS is.).
>
> - While QGIS 3.0 has introduced big changes for processing, these are
> likely to be the last big changes processing providers will see for
> the future. At least for the next 3-4 years (or lifetime of 3.x) the
> API will be fixed. And even following that, I'd envision any breaks
> introduced in 4.0 to be much less extreme. So while it's painful for
> plugins to update their providers for 3.0, it's a one-time pain. In
> contrast, expecting QGIS devs to follow the numerous underlying
> library changes and version breaks for multiple 3rd party dependancies
> 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
>
>
>
> >
> > 2018-01-31 12:17 GMT+02:00 Victor Olaya :
> >> The original idea was to have most providers removed...which included
> >> R, GRASS and SAGA as well. Finally, 

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

[Alexander Bruy]

Hi Werner,

there are no plugins for SAGA and GRASS, but this is just because they
are in core.
Also seems we need to clarify, removal from core does not means wiping
all stuff,
this just mean that existing code will be separated into plugin and
published on GitHub
and QGIS plugins repository. Then interested people can take ownership
and continue
development and maintenance.

Exactly in the same way we removed LiDAR tools provider (now
maintained by Martin Isenburg)
and TauDEM provider (maintained by me, along with several others
Processing providers).

2018-02-01 10:39 GMT+02:00 Werner Macho :
> Hi all,
>
> I am also in favour of removing all the work that is not directly related to
> QGIS.
> But I'd also like to ask if there is already a plugin available (on github?)
> that for e.g. readds the GRASS functionality?
> Furthermore I'd like to know if it is possible to create a plugin for
> official stable GRASS and GRASS development version, which in the best case
> can be installed side by side?
> (Same applies to SAGA and all the other providers).
>
> I am sure there is a huge possibility that an ecosystem will be created
> around those kind of plugins.
>
> kind regards
> Werner
>
> On Thu, Feb 1, 2018 at 9:33 AM, G. Allegri  wrote:
>>
>> +1 also from me to the removal of the providers from core. IMHO I would
>> also remove GRASS, but I understand it could be a tough decision.
>> The provider system + plugin architecture provide all the means to keep
>> them separate from the core.
>>
>> We all agree, I guess, that less is better then more, to guarantee the
>> highest quality we can afford.
>>
>> Giovanni
>>
>> Il 1 feb 2018 09:23, "Paolo Cavallini"  ha scritto:
>>>
>>> Hi Rashad,
>>>
>>> Il 31/01/2018 10:43, Rashad Kanavath ha scritto:
>>>
>>> > What I can propose is to lower the burden on maintenance but the code
>>> > should be put back to qgis if possible.
>>> > So qgis can focus on issue related only to that and after a while
>>> > things
>>> > will stabilize.
>>> >
>>> > Indeed, if there is something broken in this algo otb team will help
>>> > fix it.
>>>
>>> thanks for your offer, much appreciated. Would this include also the
>>> inclusion of OTB in the standalone installers for Windows? It would be
>>> good to make sure we always have the most appropriate version, both for
>>> 32 and 64 bit.
>>> 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
>
>
>
> ___
> 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



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

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

[Rashad Kanavath]

On Thu, Feb 1, 2018 at 9:32 AM, Jürgen E. Fischer  wrote:

> Hi Paolo,
>
> On Thu, 01. Feb 2018 at 08:23:30 +, Paolo Cavallini wrote:
> > thanks for your offer, much appreciated. Would this include also the
> > inclusion of OTB in the standalone installers for Windows?
>
> The standalone installers are made from OSGeo4W packages.  So otb should be
> updated there.   IIRC Julien Malik did the last update to 5.2 there.
>

OTB is not using ogeo4w for a long time. So OSGeo4W users are stuck on old
version. We have zero interest in pushing packages back again
Windows users can use otb from its binary package, build from source , or
maintain osgeo4w or whatever seems interest.

>
>
> Jürgen
>
> --
> Jürgen E. Fischer   norBIT GmbH Tel.
> +49-4931-918175-31
> Dipl.-Inf. (FH) Rheinstraße 13  Fax.
> +49-4931-918175-50
> Software Engineer   D-26506 Norden
> http://www.norbit.de
> QGIS release manager (PSC)  GermanyIRC: jef on FreeNode
>
> ___
> 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
>



-- 
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] Keeping OTB algorithm in qgis processing

[Werner Macho]

Hi all,

I am also in favour of removing all the work that is not directly related
to QGIS.
But I'd also like to ask if there is already a plugin available (on
github?) that for e.g. readds the GRASS functionality?
Furthermore I'd like to know if it is possible to create a plugin for
official stable GRASS and GRASS development version, which in the best case
can be installed side by side?
(Same applies to SAGA and all the other providers).

I am sure there is a huge possibility that an ecosystem will be created
around those kind of plugins.

kind regards
Werner

On Thu, Feb 1, 2018 at 9:33 AM, G. Allegri  wrote:

> +1 also from me to the removal of the providers from core. IMHO I would
> also remove GRASS, but I understand it could be a tough decision.
> The provider system + plugin architecture provide all the means to keep
> them separate from the core.
>
> We all agree, I guess, that less is better then more, to guarantee the
> highest quality we can afford.
>
> Giovanni
>
> Il 1 feb 2018 09:23, "Paolo Cavallini"  ha scritto:
>
>> Hi Rashad,
>>
>> Il 31/01/2018 10:43, Rashad Kanavath ha scritto:
>>
>> > What I can propose is to lower the burden on maintenance but the code
>> > should be put back to qgis if possible.
>> > So qgis can focus on issue related only to that and after a while things
>> > will stabilize.
>> >
>> > Indeed, if there is something broken in this algo otb team will help
>> fix it.
>>
>> thanks for your offer, much appreciated. Would this include also the
>> inclusion of OTB in the standalone installers for Windows? It would be
>> good to make sure we always have the most appropriate version, both for
>> 32 and 64 bit.
>> 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
>
___
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] Keeping OTB algorithm in qgis processing

[Jürgen E . Fischer]

Hi Paolo,

On Thu, 01. Feb 2018 at 08:23:30 +, Paolo Cavallini wrote:
> thanks for your offer, much appreciated. Would this include also the
> inclusion of OTB in the standalone installers for Windows?

The standalone installers are made from OSGeo4W packages.  So otb should be
updated there.   IIRC Julien Malik did the last update to 5.2 there.


Jürgen

-- 
Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
Software Engineer   D-26506 Norden http://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode


signature.asc
Description: PGP signature
___
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] Keeping OTB algorithm in qgis processing

[G. Allegri]

+1 also from me to the removal of the providers from core. IMHO I would
also remove GRASS, but I understand it could be a tough decision.
The provider system + plugin architecture provide all the means to keep
them separate from the core.

We all agree, I guess, that less is better then more, to guarantee the
highest quality we can afford.

Giovanni

Il 1 feb 2018 09:23, "Paolo Cavallini"  ha scritto:

> Hi Rashad,
>
> Il 31/01/2018 10:43, Rashad Kanavath ha scritto:
>
> > What I can propose is to lower the burden on maintenance but the code
> > should be put back to qgis if possible.
> > So qgis can focus on issue related only to that and after a while things
> > will stabilize.
> >
> > Indeed, if there is something broken in this algo otb team will help fix
> it.
>
> thanks for your offer, much appreciated. Would this include also the
> inclusion of OTB in the standalone installers for Windows? It would be
> good to make sure we always have the most appropriate version, both for
> 32 and 64 bit.
> 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] Keeping OTB algorithm in qgis processing

[Paolo Cavallini]

Il 01/02/2018 07:21, Victor Olaya ha scritto:
> +1 from me. This is exactly the reasoning behind my original proposal
> of removing providers from core. Whether the plugin is easy to
> maintain or not, it is better to do it outside. People responsible of
> the plugin can release whenever they want, and they can do changes
> without having to do PRs to the main repo (so less burden for core
> devs)
> 
> A plugin with a provider has much more to do with the provider app
> than with QGIS, and it makes sense to maintain it as a separate thing,
> and, if possible, done by the people that better know the external app
> (like the OTB team in the case of OTB)

Thanks Alex, Nyall, Victor for thoughts. It indeed makes sense.
What can happen realistically is, IMHO:
* someone will pop up taking the now orphaned providers, as it is
happening now for OTB --> success
* no one will find the resources for this, and QGIS will miss hundreds
of important algs --> failure
Of course this second possibility is scary to all those, that rely on
these algs. I am finding easier since too many years to find resources
for fancy styling and other cartographic tasks than for hard core
analyses, so I tend to be pessimistic, but let's see.
Thanks again.
-- 
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] Keeping OTB algorithm in qgis processing

[Paolo Cavallini]

Hi Rashad,

Il 31/01/2018 10:43, Rashad Kanavath ha scritto:

> What I can propose is to lower the burden on maintenance but the code
> should be put back to qgis if possible. 
> So qgis can focus on issue related only to that and after a while things
> will stabilize.
> 
> Indeed, if there is something broken in this algo otb team will help fix it.

thanks for your offer, much appreciated. Would this include also the
inclusion of OTB in the standalone installers for Windows? It would be
good to make sure we always have the most appropriate version, both for
32 and 64 bit.
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] Keeping OTB algorithm in qgis processing

[Victor Olaya]

+1 from me. This is exactly the reasoning behind my original proposal
of removing providers from core. Whether the plugin is easy to
maintain or not, it is better to do it outside. People responsible of
the plugin can release whenever they want, and they can do changes
without having to do PRs to the main repo (so less burden for core
devs)

A plugin with a provider has much more to do with the provider app
than with QGIS, and it makes sense to maintain it as a separate thing,
and, if possible, done by the people that better know the external app
(like the OTB team in the case of OTB)

Cheers

2018-02-01 0:17 GMT+01:00 Nyall Dawson :
> On 31 January 2018 at 20:23, Alexander Bruy  wrote:
>> Another reason to remove providers is that algorithms descriptions
>> were not updated and maintained. Even now both SAGA and GRASS
>> providers are not updated to latest stable versions of the corresponding
>> software.
>>
>> We just simply does not have enough resources to maintain more than
>> 600 algorithms from GRASS and SAGA. Situation with OTB, was even
>> worse, it requires special handling of the parameters.
>>
>> I still think that Processing should be in core with minimal set of 
>> algorithms
>> (native and GDAL), all other providers should be plugins and installed by
>> users. Ideally these providers also should be maintained by interested groups
>> of devs/users, not by QGIS devs.
>
> A big +1 to everything Alex said above, and a strong -1 to
> reintroducing any of these providers back to master (and also a +1 to
> shifting the SAGA provider to a non-default plugin).
>
> My reasons:
>
> - we have a very strong plugin infrastructure designed EXACTLY for
> these use cases. Having these providers as separate plugins, free from
> the QGIS release cycle makes a ton of sense. Plugins devs can then
> push new versions of their providers whenever new versions of the
> underlying libraries are available, and not be constrained by waiting
> until the next QGIS release.
>
> - years of experience has PROVEN that we do not have the capacity to
> maintain these providers ourselves. Numerous developers have tried,
> and just been swamped by the amount of work required to keep the
> providers stable while the underlying libraries change. The QGIS team
> is running at capacity just keeping QGIS maintained and stable - we
> CANNOT take on this extra work.
>
> - regardless of the approach taken, things just don't stay stable for
> us. E.g. we tried to make the SAGA provider more stable by only
> targeting the SAGA LTR release yet the SAGA upstream seem to have
> abandoned the LTR, leaving it totally broken on newer build chains. I
> cannot get SAGA LTR to run on my development platform (Fedora) as it
> constantly segfaults. End result - even if I had the time to maintain
> this provider, I would be totally unable to. (For this reason I think
> SAGA should also be moved to a separate QGIS plugin, leaving on QGIS,
> GDAL and GRASS provided in the default install. GDAL and GRASS
> (mostly) are always available wherever QGIS is.).
>
> - While QGIS 3.0 has introduced big changes for processing, these are
> likely to be the last big changes processing providers will see for
> the future. At least for the next 3-4 years (or lifetime of 3.x) the
> API will be fixed. And even following that, I'd envision any breaks
> introduced in 4.0 to be much less extreme. So while it's painful for
> plugins to update their providers for 3.0, it's a one-time pain. In
> contrast, expecting QGIS devs to follow the numerous underlying
> library changes and version breaks for multiple 3rd party dependancies
> 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
>
>
>
>>
>> 2018-01-31 12:17 GMT+02:00 Victor Olaya :
>>> The original idea was to have most providers removed...which included
>>> R, GRASS and SAGA as well. Finally, only certain providers were
>>> removed, mostly those that require dependencies not provided with QGIS
>>> (LiDAR tools, R...and OTB)
>>>
>>> If maintaining the plugin is complicated and no work is done on that,
>>> then definitely it is better to keep it as core. But we have to make
>>> sure that the user knows that the provider by itself is useless, and
>>> that OTB has to be installed separately. Otherwise, we will see
>>> confusion and i think it will not be a good idea
>>>
>>> My 2 cents
>>>
>>> 2018-01-31 11:04 GMT+01:00 Paolo Cavallini :
 Il 31/01/2018 09:50, Rashad Kanavath ha scritto:

> Thanks Paolo,
> Can you give a link to that discussion?

 I had a look to the archives, and I only found this:
 https://lists.osgeo.org/pipermail/qgis-developer/2017-May/048470.html
 Surely Victor and Alex can provide further 

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

[Nyall Dawson]

On 31 January 2018 at 20:23, Alexander Bruy  wrote:
> Another reason to remove providers is that algorithms descriptions
> were not updated and maintained. Even now both SAGA and GRASS
> providers are not updated to latest stable versions of the corresponding
> software.
>
> We just simply does not have enough resources to maintain more than
> 600 algorithms from GRASS and SAGA. Situation with OTB, was even
> worse, it requires special handling of the parameters.
>
> I still think that Processing should be in core with minimal set of algorithms
> (native and GDAL), all other providers should be plugins and installed by
> users. Ideally these providers also should be maintained by interested groups
> of devs/users, not by QGIS devs.

A big +1 to everything Alex said above, and a strong -1 to
reintroducing any of these providers back to master (and also a +1 to
shifting the SAGA provider to a non-default plugin).

My reasons:

- we have a very strong plugin infrastructure designed EXACTLY for
these use cases. Having these providers as separate plugins, free from
the QGIS release cycle makes a ton of sense. Plugins devs can then
push new versions of their providers whenever new versions of the
underlying libraries are available, and not be constrained by waiting
until the next QGIS release.

- years of experience has PROVEN that we do not have the capacity to
maintain these providers ourselves. Numerous developers have tried,
and just been swamped by the amount of work required to keep the
providers stable while the underlying libraries change. The QGIS team
is running at capacity just keeping QGIS maintained and stable - we
CANNOT take on this extra work.

- regardless of the approach taken, things just don't stay stable for
us. E.g. we tried to make the SAGA provider more stable by only
targeting the SAGA LTR release yet the SAGA upstream seem to have
abandoned the LTR, leaving it totally broken on newer build chains. I
cannot get SAGA LTR to run on my development platform (Fedora) as it
constantly segfaults. End result - even if I had the time to maintain
this provider, I would be totally unable to. (For this reason I think
SAGA should also be moved to a separate QGIS plugin, leaving on QGIS,
GDAL and GRASS provided in the default install. GDAL and GRASS
(mostly) are always available wherever QGIS is.).

- While QGIS 3.0 has introduced big changes for processing, these are
likely to be the last big changes processing providers will see for
the future. At least for the next 3-4 years (or lifetime of 3.x) the
API will be fixed. And even following that, I'd envision any breaks
introduced in 4.0 to be much less extreme. So while it's painful for
plugins to update their providers for 3.0, it's a one-time pain. In
contrast, expecting QGIS devs to follow the numerous underlying
library changes and version breaks for multiple 3rd party dependancies
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



>
> 2018-01-31 12:17 GMT+02:00 Victor Olaya :
>> The original idea was to have most providers removed...which included
>> R, GRASS and SAGA as well. Finally, only certain providers were
>> removed, mostly those that require dependencies not provided with QGIS
>> (LiDAR tools, R...and OTB)
>>
>> If maintaining the plugin is complicated and no work is done on that,
>> then definitely it is better to keep it as core. But we have to make
>> sure that the user knows that the provider by itself is useless, and
>> that OTB has to be installed separately. Otherwise, we will see
>> confusion and i think it will not be a good idea
>>
>> My 2 cents
>>
>> 2018-01-31 11:04 GMT+01:00 Paolo Cavallini :
>>> Il 31/01/2018 09:50, Rashad Kanavath ha scritto:
>>>
 Thanks Paolo,
 Can you give a link to that discussion?
>>>
>>> I had a look to the archives, and I only found this:
>>> https://lists.osgeo.org/pipermail/qgis-developer/2017-May/048470.html
>>> Surely Victor and Alex can provide further details.
>>> 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
>
>
>
> --
> 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 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] Keeping OTB algorithm in qgis processing

[Rashad Kanavath]

On Wed, Jan 31, 2018 at 11:29 AM, Paolo Cavallini 
wrote:

> Il 31/01/2018 10:26, Alexander Bruy ha scritto:
> > It is included, but this version is really outdated isn't it?
>
> we can seek additional resources to maintain it. Perhaps OTB team is
> interested in maintaining it up to date?
>

the old plugin code had lot of issue like maintain list of supported
version, keeping a backlist and whilelist for supported applications (don't
ask),
splitting of apps because groups aren't supported to name a few.
And I think this one of the blocking point for qgis and also otb. It need
to put a lot of efforts to maintain otb provider and cost is triple
compared to others
 If the plugin code was simply generic, qgis would have done maintain it
like old way. Because you only need to change plugin if there is are API
changes,
or some stuff that is made into processing itself. This one will be easy
because all source is in tree you can find places where it needs to change
like:

-from processing.core.AlgorithmProvider import AlgorithmProvider
+from qgis.core import QgsProcessingProvider

And this are back normal.

What I can propose is to lower the burden on maintenance but the code
should be put back to qgis if possible.
So qgis can focus on issue related only to that and after a while things
will stabilize.

Indeed, if there is something broken in this algo otb team will help fix it.

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] Keeping OTB algorithm in qgis processing

[Paolo Cavallini]

Il 31/01/2018 10:26, Alexander Bruy ha scritto:
> It is included, but this version is really outdated isn't it?

we can seek additional resources to maintain it. Perhaps OTB team is
interested in maintaining it up to date?
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] Keeping OTB algorithm in qgis processing

[Paolo Cavallini]

Il 31/01/2018 10:23, Alexander Bruy ha scritto:

> We just simply does not have enough resources to maintain more than
> 600 algorithms from GRASS and SAGA.

> I still think that Processing should be in core with minimal set of algorithms
> (native and GDAL), all other providers should be plugins and installed by
> users. Ideally these providers also should be maintained by interested groups
> of devs/users, not by QGIS devs.

I understand the point all too well; the big risk here is these
providers will fall into oblivion, with a big damage to QGIS as a whole.
Overall, I'm in favour of keeping these as a part of the project,
supported by it.
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] Keeping OTB algorithm in qgis processing

[Alexander Bruy]

It is included, but this version is really outdated isn't it?

2018-01-31 12:25 GMT+02:00 Paolo Cavallini :
> Il 31/01/2018 10:17, Victor Olaya ha scritto:
>
>> that OTB has to be installed separately. Otherwise, we will see
>> confusion and i think it will not be a good idea
>
> OTB is included in the standalone for win (at least for 32 bit, IMHO it
> should be also in 64 bit). In Debian this is not an issue.
> 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



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

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

[Rashad Kanavath]

On Wed, Jan 31, 2018 at 10:45 AM, Paolo Cavallini 
wrote:

> Il 31/01/2018 09:40, Rashad Kanavath ha scritto:
>
> > With that change coming, are you folks interested to put back otb algo
> > into processing/algs/otb.?
>
> I am supportive of this, even though I understand the argument that
> brought to the removal.
>

Thanks Paolo,
Can you give a link to that discussion?

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




-- 
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] Keeping OTB algorithm in qgis processing

[Paolo Cavallini]

Il 31/01/2018 09:40, Rashad Kanavath ha scritto:

> With that change coming, are you folks interested to put back otb algo
> into processing/algs/otb.?

I am supportive of this, even though I understand the argument that
brought to the removal.
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