[GRASS-dev] Future of external Processing providers in QGIS

GRASS GRASS developer
, ,
1

Hi all,
meeting has just ended. I must say it was a very interesting and
productive discussion. We are really grateful for the developers from
GRASS, SAGA and OTB for their contributions to our discussion.
I recap briefly here what I believe are the most important outcomes:
* we'll keep SAGA and GRASS Processing providers
* we'll try to update SAGA provider to the next LTR when this will be
available
* we invite OTB team to add their work to QGIS core, granting them write
access if they wish
* for OTB provider, considering that OTB binaries are not part of the
installer on Windows, we suggest this approach: OTB provider checks
whether OTB is installed, if not it suggests the user to install it, if
the user does not the provider hides itself
* While we have granted an exception to the ‘processing providers should
not be in core’ for the short term, our longer term plan is to put in
place mechanisms to ‘side load’ the dependencies (GRASS, OTB, SAGA).
When this capability is implemented, we will mandate that all providers
will be provided as plugins and then fetch these plugins on demand if an
algorithm references them
* we will not accept new providers, unless some very strict and
exceptional conditions apply (TBD; e.g. new backend of high quality and
general usage)
* for future versions we will consider moving providers to the XML
approach where appropriate, as it appears more maintainable, even at the
expense of flexibility in interface tuning; GRASS is the next candidate,
noting that this might require some modifications in GRASS core
* as a first step in we ask anybody to test thoroughly the new SAGA
provider by Alex Bruy
https://github.com/alexbruy/processing-saga
also a check from SAGA, GRASS, and OTB devs would be important, to check
whether this approach is the preferred one from all sides.
Please add if I missed something.
Overall, I think we have now a brighter future for Processing, and as a
consequence for QGIS, SAGA, GRASS and OTB altogether.
* If you want to watch the complete discussion, please be patient; video
is being uploaded.
All the best, and thanks again.
--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all&geo=IT&q=qgis,arcgis

2

Thank you, Paolo, for the summary. It was great to be part of the meeting!

···

On Fri, Feb 23, 2018 at 9:26 AM, Paolo Cavallini <cavallini@faunalia.it> wrote:

Hi all,
meeting has just ended. I must say it was a very interesting and
productive discussion. We are really grateful for the developers from
GRASS, SAGA and OTB for their contributions to our discussion.
I recap briefly here what I believe are the most important outcomes:

  • we’ll keep SAGA and GRASS Processing providers
  • we’ll try to update SAGA provider to the next LTR when this will be
    available
  • we invite OTB team to add their work to QGIS core, granting them write
    access if they wish
  • for OTB provider, considering that OTB binaries are not part of the
    installer on Windows, we suggest this approach: OTB provider checks
    whether OTB is installed, if not it suggests the user to install it, if
    the user does not the provider hides itself
  • While we have granted an exception to the ‘processing providers should
    not be in core’ for the short term, our longer term plan is to put in
    place mechanisms to ‘side load’ the dependencies (GRASS, OTB, SAGA).
    When this capability is implemented, we will mandate that all providers
    will be provided as plugins and then fetch these plugins on demand if an
    algorithm references them
  • we will not accept new providers, unless some very strict and
    exceptional conditions apply (TBD; e.g. new backend of high quality and
    general usage)
  • for future versions we will consider moving providers to the XML
    approach where appropriate, as it appears more maintainable, even at the
    expense of flexibility in interface tuning; GRASS is the next candidate,
    noting that this might require some modifications in GRASS core
  • as a first step in we ask anybody to test thoroughly the new SAGA
    provider by Alex Bruy
    https://github.com/alexbruy/processing-saga
    also a check from SAGA, GRASS, and OTB devs would be important, to check
    whether this approach is the preferred one from all sides.
    Please add if I missed something.
    Overall, I think we have now a brighter future for Processing, and as a
    consequence for QGIS, SAGA, GRASS and OTB altogether.
  • If you want to watch the complete discussion, please be patient; video
    is being uploaded.
    All the best, and thanks again.
    –
    Paolo Cavallini - www.faunalia.eu
    QGIS & PostGIS courses: http://www.faunalia.eu/training.html
    https://www.google.com/trends/explore?date=all&geo=IT&q=qgis,arcgis

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

3

Hi Paolo,

(reducing to grass-dev)

thanks for your detailed summary! I have just added a related agenda item to
https://grasswiki.osgeo.org/wiki/GRASS_GIS_Community_Sprint_Bonn_2018#Agenda_-_What_we_plan_to_do

A few more comments inline:

On Fri, Feb 23, 2018 at 3:26 PM, Paolo Cavallini <cavallini@faunalia.it> wrote:

Hi all,
meeting has just ended. I must say it was a very interesting and
productive discussion. We are really grateful for the developers from
GRASS, SAGA and OTB for their contributions to our discussion.

Glad that this discussion happened, paving the way to a continued
collaboration on the processing providers.

I recap briefly here what I believe are the most important outcomes:
* we'll keep SAGA and GRASS Processing providers

Excellent.

[... SAGA ... OTB...]

* While we have granted an exception to the ‘processing providers should
not be in core’ for the short term, our longer term plan is to put in
place mechanisms to ‘side load’ the dependencies (GRASS, OTB, SAGA).
When this capability is implemented, we will mandate that all providers
will be provided as plugins and then fetch these plugins on demand if an
algorithm references them

... I am not sure if I understand the details here but others in the
list certainly do :slight_smile:

[... about future new backends...]

* for future versions we will consider moving providers to the XML
approach where appropriate, as it appears more maintainable, even at the
expense of flexibility in interface tuning; GRASS is the next candidate,
noting that this might require some modifications in GRASS core

There was already the proposal to add --qgis-description or likewise
into the parser of GRASS, should be doable.
This we will discuss next month in Bonn.

* as a first step in we ask anybody to test thoroughly the new SAGA
provider by Alex Bruy
https://github.com/alexbruy/processing-saga
also a check from SAGA, GRASS, and OTB devs would be important, to check
whether this approach is the preferred one from all sides.

Thanks, we'll go through that.

Please add if I missed something.
Overall, I think we have now a brighter future for Processing, and as a
consequence for QGIS, SAGA, GRASS and OTB altogether.

Thanks for your efforts of summarizing the important discussion.

Best
Markus

4

Il 27/02/2018 19:59, Markus Neteler ha scritto:

Hi Paolo,

(reducing to grass-dev)

thanks for your detailed summary! I have just added a related agenda item to
https://grasswiki.osgeo.org/wiki/GRASS_GIS_Community_Sprint_Bonn_2018#Agenda_-_What_we_plan_to_do

Glad you appreciated it - I think it was an excellent example of how
things can go, democratically, in GFOSS community.
Looking forward for further progress on this. Of course I'm available
for help.
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&geo=IT&q=qgis,arcgis