Re: [GRASS-dev] External providers in QGIS

[Moritz Lennert]

On 09/02/18 02:55, Nyall Dawson wrote:

On 9 February 2018 at 00:20, Moritz Lennert
 wrote:

On 08/02/18 15:08, Nikos Alexandris wrote:


I guess, there are numerous cases like this one. What would,
effectively, mean a removal of external providers (in this case GRASS
GIS)?



Let's make it clear once and for all: noone is speaking about the complete
removal of external providers. The issue is where, how and by whom they
should be maintained, i.e. within the QGIS core code base, or as plugins.



Yes, this is a great point. I think this discussion has got
sidetracked with some misunderstandings.

Here's the situation as I see it:


The past
---

We (the QGIS project) have struggled to keep a bunch of providers
stable and available with the base QGIS install, and the current
maintainers (Alex and Victor, others) have (understandably) struggled
with the burden of maintaining these alone and the time commitment
required to do so. Users have been frustrated by breakage which occurs
when the algorithms they depend on break due to changes in underlying
libraries for which the processing providers have not been adapted.

Despite this, I'd say overall it's worked OK-ish up to now, but
definitely with lots of room for improvement.

-
The goals
-

I think everyone involved is in agreement that processing's strength
comes when there's many providers available and it's able to tie
together processes regardless of which provider or library they come
from. So I'd say our common goals are:

1. Encourage development of as many processing providers as possible
2. Make it easy for developers to create and maintain these providers
3. Make it easy for users to be able to use the providers
4. Make everything stable and painfree for users

Any disagreements? No? Good ;)

So if we agree that those are the end goals, we should be using them
to drive this discussion.

---
The questions
---

The open, debatable questions are:

- Which is the best approach for allowing easy maintenance of
providers (*regardless* of whether the provider is maintained by the
core QGIS team or a 3rd party)? Is it keeping the code in the master
codebase and locking to QGIS releases, or publishing via plugins and
having independent release schedules? Which approach will encourage
more active maintenance of these providers and share the burden of
this maintenance?

- Who should be responsible for maintaining the providers? Should
maintenance be done by the QGIS core developer team or by 3rd parties?

- How do we make these tools available for ALL interested users? How
can we ensure that 3rd party dependencies are always available and
have a consistent feature set, regardless of which platform the user
is running? Does having the QGIS team or 3rd parties maintain the
provider help make the tools more readily available? Does having the
providers in master or plugins make the 3rd party dependencies more
readily available or not?

- How can we ensure that providers are well tested and don't break
with changes in QGIS OR from 3rd party library updates? Does having
the QGIS team or 3rd parties affect this stability? Does having the
providers in master or plugins affect this stability?

- Is it a core requirement that 3rd party providers are installed with
EVERY QGIS install, or is it acceptable to require interested users to
manually install the tools which they find useful? If the second
option is preferred, then how can we ensure that users are aware of
the availability of these tools?

- Does it make it easier for everyone involved if we just delete all
the python bindings for processing and only allow core, native, c++
algorithms, and merge all our codebases into a single unified
QGIS+SAGA+GRASS+OTB+R mega package? (I joke... ;)

This isn't an easy discussion, but please, let's keep the discussion
civil, factual, and informed, and driven by the above goals.



Thanks for this summary, Nyall. It overlaps my summary in a parallel thread:

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

Moritz

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

Re: [GRASS-dev] External providers in QGIS

[Helmut Kudrnovsky]

pcav wrote
> Il 08/02/2018 15:49, Nikos Alexandris ha scritto:
>> * Moritz Lennert 

> mlennert@.worldonline

>  [2018-02-08 15:20:14
>> +0100]:
>> 
>>> On 08/02/18 15:08, Nikos Alexandris wrote:
 I guess, there are numerous cases like this one. What would,
 effectively, mean a removal of external providers (in this case GRASS
 GIS)?
>>>
>>> Let's make it clear once and for all: noone is speaking about the
>>> complete removal of external providers. The issue is where, how and by
>>> whom they should be maintained, i.e. within the QGIS core code base,
>>> or as plugins.
>> 
>> 
>> Thank you the heads-up Moritz.
> 
> true, but removal from core would mean the external plugin has to be
> created, maintained, tested, and documented by someone. If this is
> missing, the external plugin simply wil not appear. This is what
> happened with R. Once a provider is out and unmaintained, it becomes
> less visible, and less likely to attract attention. The work to bring it
> back to life, with all the above, will be much higher than when in core,
> and increasing over time.
> All the best.
> 
> -- 
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
> ___
> grass-dev mailing list

> grass-dev@.osgeo

> https://lists.osgeo.org/mailman/listinfo/grass-dev

this touches Moritz' questions listed here:

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





-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] External providers in QGIS

[Paolo Cavallini]

Il 08/02/2018 15:49, Nikos Alexandris ha scritto:
> * Moritz Lennert  [2018-02-08 15:20:14
> +0100]:
> 
>> On 08/02/18 15:08, Nikos Alexandris wrote:
>>> I guess, there are numerous cases like this one. What would,
>>> effectively, mean a removal of external providers (in this case GRASS
>>> GIS)?
>>
>> Let's make it clear once and for all: noone is speaking about the
>> complete removal of external providers. The issue is where, how and by
>> whom they should be maintained, i.e. within the QGIS core code base,
>> or as plugins.
> 
> 
> Thank you the heads-up Moritz.

true, but removal from core would mean the external plugin has to be
created, maintained, tested, and documented by someone. If this is
missing, the external plugin simply wil not appear. This is what
happened with R. Once a provider is out and unmaintained, it becomes
less visible, and less likely to attract attention. The work to bring it
back to life, with all the above, will be much higher than when in core,
and increasing over time.
All the best.

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

Re: [GRASS-dev] External providers in QGIS

[Paolo Cavallini]

Il 08/02/2018 10:31, Rashad Kanavath ha scritto:

> I don't know what these developers are going to do with a bugfix after a
> new release. That's some kind of mystery unsolved to me.

we are doing regular point releases, an approach which has proven very
successful IMHO

> I hope there will be zero bugs after releases.

I hope you are joking :)

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

Re: [GRASS-dev] External providers in QGIS

[Nikos Alexandris]

* Moritz Lennert  [2018-02-08 15:20:14 +0100]:


On 08/02/18 15:08, Nikos Alexandris wrote:

I guess, there are numerous cases like this one. What would,
effectively, mean a removal of external providers (in this case GRASS
GIS)?


Let's make it clear once and for all: noone is speaking about the 
complete removal of external providers. The issue is where, how and by 
whom they should be maintained, i.e. within the QGIS core code base, 
or as plugins.



Thank you the heads-up Moritz.

Nikos


signature.asc
Description: PGP signature
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] External providers in QGIS

[Moritz Lennert]

On 08/02/18 15:08, Nikos Alexandris wrote:

I guess, there are numerous cases like this one. What would,
effectively, mean a removal of external providers (in this case GRASS
GIS)?


Let's make it clear once and for all: noone is speaking about the 
complete removal of external providers. The issue is where, how and by 
whom they should be maintained, i.e. within the QGIS core code base, or 
as plugins.


Moritz


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

Re: [GRASS-dev] External providers in QGIS

[Nikos Alexandris]

Dear all,

a case somewhat relevant to the discussion.

I am tasked by a client to work with and on some existing scripts that derive
maps related to recreational areas. These scripts use GRASS GIS.
Hence, it is naturally to shape a GRASS GIS Add-on.

The add-on will eventually be of interest for many, and mostly non
GIS-experts.  The whole idea was to expose the Add-on to QGIS and
eventually train and practice with it persons who are not experienced
GIS users.

Both QGIS and GRASS GIS, in this case, and the whole OSGeo ecosystem,
have things to gain, while offering small tools that interest many.

I guess, there are numerous cases like this one. What would,
effectively, mean a removal of external providers (in this case GRASS
GIS)?

Among the, indeed, many algorithms that might appear, or be
overwhelming, there are always here and there tools that make life
easier for people who don't have the time or the need to dive deep into
special concepts of GRASS, SAGA or OTB.  And QGIS is for the the
reference.

Thanks, Nikos



* Paolo Cavallini  [2018-02-06 18:57:17 +0100]:


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


--
Nikos Alexandris | Remote Sensing & Geomatics
GPG Key Fingerprint 6F9D4506F3CA28380974D31A9053534B693C4FB3 


signature.asc
Description: PGP signature
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] External providers in QGIS

[Rashad Kanavath]

On Wed, Feb 7, 2018 at 6:25 PM, Paolo Cavallini 
wrote:

> Il 07/02/2018 11:18, Victor Olaya ha scritto:
> > I dont see the advantage in having providers in core.
>
> I see the following:
> * tests (already available in our infrastructure)
> * translations
> * more exposure
> * documentation
>
> > And if there is an
> > advantage, it's clearly not in how easy it is going to be to maintain
> > the plugin.
>
> until now it has been maintained somehow; if more resources are needed,
> we can find a way
>
> > If the people responsible of a given backend (like OTB) are
> > going to maintain it (which makes sense), why putting it in core where
> > they don't have write access?
>
> why not granting them write access?
>
That would still need users *waiting* for QGIS release for fix in algo is
what I understood from other parts of discussion.
I don't know what these developers are going to do with a bugfix after a
new release. That's some kind of mystery unsolved to me.
I hope there will be zero bugs after releases.


>
> > Better in a separate repo. Also, they can
> > release whenever there are changes, without having to wait for a new
> > release. That way, the plugin will always be in sync with new releases
> > of the backend app.
>
> this is certainly true; AFAICT OTB people has proposed a solution


> > If we put them in core...why putting only this big ones (which in some
> > cases require installing external apps manually by the user), and not
> > put other plugins that exist and contain Processing providers?
>
> I'd be in favour of adding anything important for users.
>
> Thanks for your thoughts.
>
> When in Madeira we can have a discussion about this. It would be good if
> all interested parties could meet, locally and remotely.
>
> All the best.
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
>



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

Re: [GRASS-dev] External providers in QGIS

[Paolo Cavallini]

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

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

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

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

> If the people responsible of a given backend (like OTB) are
> going to maintain it (which makes sense), why putting it in core where
> they don't have write access?

why not granting them write access?

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

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

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

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

Thanks for your thoughts.

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

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

Re: [GRASS-dev] External providers in QGIS

[Rashad Kanavath]

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

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

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


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

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

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



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

Re: [GRASS-dev] External providers in QGIS

[Rashad Kanavath]

Hello victor,

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

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

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

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

The other way of putting processing plugin into core and providers
classified as external plugins can avoid maintenance on qgis.
But this "strategy" can result in dead code and users complaining on both
projects. Because, at some developers cannot manage project release + a
plugin for qgis, another plugin for matlab or whatever
Putting all stuff in qgis tree and taking no responsibility of providers
isn't good either.

This way, each team takes part and result in better collaboration and
contribution.
As time goes, generic descriptor provider gets better and stronger.
Toolboxes are free to add, remove, modify their applications and users from
both community benefit best of both worlds.


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

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


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

Re: [GRASS-dev] External providers in QGIS

[Rashad Kanavath]

On Tue, Feb 6, 2018 at 11:46 PM, Martin Landa 
wrote:

> 2018-02-06 23:34 GMT+01:00 Helmut Kudrnovsky :
> > yes, that is part of the 'proactively thinking' what I mean.
>
> draft of idea added [1]. Feel free to improve/extend :-)
>

I support this idea for GSoC

>
> Ma
>
> [1] https://trac.osgeo.org/grass/wiki/GSoC/2018#
> ImproveGRASSintegrationinQGIS3
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>



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

Re: [GRASS-dev] External providers in QGIS

[Martin Landa]

2018-02-06 23:34 GMT+01:00 Helmut Kudrnovsky :
> yes, that is part of the 'proactively thinking' what I mean.

draft of idea added [1]. Feel free to improve/extend :-)

Ma

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

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] External providers in QGIS

[Helmut Kudrnovsky]

Martin Landa wrote
> Hi,
> 
> 2018-02-06 23:12 GMT+01:00 Helmut Kudrnovsky 

> hellik@

> :
>> this is part of QGIS success and this question has also to be answered by
>> the QGIS community.
>>
>> This may be an indication that OSGeo's inter-project communication should
>> be
>> proactively improved in the future.
> 
> could be probably nice GSoC project too (GRASS provider in QGIS3). Ma

yes, that is part of the 'proactively thinking' what I mean. 

not all possible opportunities to improve things are considered
beforehand... 





-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] External providers in QGIS

[Martin Landa]

Hi,

2018-02-06 23:12 GMT+01:00 Helmut Kudrnovsky :
> this is part of QGIS success and this question has also to be answered by
> the QGIS community.
>
> This may be an indication that OSGeo's inter-project communication should be
> proactively improved in the future.

could be probably nice GSoC project too (GRASS provider in QGIS3). Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] External providers in QGIS

[Helmut Kudrnovsky]

Hi Paolo,


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

thanks for the follow up on this discussion.

Is there already a concrete technical documention of requirements, methods,
API, interface etc by QGIS how alg providers work/should work/be maintained?

This may ease and accelerate to start a discussion in the communities of
algs providers like OTB, GRASS, SAGA and others how to proceed in this
inter-project challenge.

>If not, this will mean effectively missing 
>hundreds of algs from QGIS. 

this is part of QGIS success and this question has also to be answered by
the QGIS community.

This may be an indication that OSGeo's inter-project communication should be
proactively improved in the future.



-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev