search

qgis / QGIS-Enhancement-Proposals

QEP's (QGIS Enhancement Proposals) are used in the process of creating and discussing new enhancements for QGIS
117 stars 37 forks source link

Drop Official Support for GRASS C++ Plugin #234

Open PeterPetrik opened 2 years ago

PeterPetrik commented 2 years ago

QGIS Enhancement: Drop GRASS C++ Plugin

Date 2021/10/05

Author Peter Petrik (@PeterPetrik )

Contact peter dot petrik at lutraconsulting dot co dot uk

maintainer @PeterPetrik

Version QGIS 3.24+

Summary

Maintained GRASS Processing Provider and the modern GRASS-GIS covers the functionality that was previously covered by native C++ GRASS Plugin

Currently, the code section receives minimal attention from the developers. Also, it is not fixed in the regular bug-fix sprints before releases (at least from 2019 we reply to issues to use QGIS Processing and that plugin is unmaintained).

Proposed Solution

From QGIS 3.24:

From QGIS 4.0

Affected Files

https://github.com/qgis/QGIS/tree/master/src/plugins/grass

Further Considerations/Improvements

Backwards Compatibility

n/a

Issue Tracking ID(s)

https://github.com/qgis/QGIS/issues?q=is%3Aissue+is%3Aopen+-label%3AFeedback+label%3A%22GRASS%22+-label%3A%22Processing%22

Votes

ping @blazek

esnyder-rve commented 2 years ago

Similar to:

gioman commented 2 years ago

It seems no one wants to comment this first :) So I take my chance here, and I vote yes. If this will happen it will be an important moment without doubt, but give the state of the GRASS plugin (not maintained) and the fact that it has lost most of its importance since we can run GRASS tools in Processing (even if they are slow with large datasets, because of the in/out to/from GRASS locations/mapsets done on the fly at each run of a GRASS tool). Also I'm not sure than anyone has ever used the GRASS vector editing capabilities and styling (but maybe that would not be part of the removal of the plugin?). What is important is to keep the ability to read GRASS locations/mapsets and use the GRASS layers as normal inputs in QGIS tools. Not sure if is compatible with the removal but it would be very nice to be able to launch a GRASS console from within QGIS (but as it is part of the GRASS plugin functionality I understand that maybe this will not be possible).

blazek commented 2 years ago

There is GRASS plugin and GRASS vector/raster provider. It should be clarified if this proposal is about plugin only or about both plugin and providers.

esnyder-rve commented 2 years ago

because of the in/out to/from GRASS locations/mapsets done on the fly

If I recall, there is work being done in GRASS to fix this. There supposedly is a plan (I think in GRASS 8) to remove the need to create a location and mapset.

esnyder-rve commented 2 years ago

@blazek It appears to be referring to the plugin, not the provider.

PeterPetrik commented 2 years ago

yep, this is only about plugin. Provider & processing should is not part of this QEP

nyalldawson commented 2 years ago

So I would say a super-safe approach could be this:

  1. Allow GRASS processing algorithms to be run DIRECTLY on grass layers (either those loaded in the project, or by selecting "browse for layer" and expanding out a grass map set directory). Similarly allow the results to be stored as their original grass datasets, without conversion to other formats.
  2. Move the functionality to create a new grass mapset/layer from out of the grass plugin to to the grass provider's browser provider. (currently you have to have the plugin enabled in order to create a new mapset).

We could then safely drop the plugin without any minimal loss of functionality -- the algorithms would be available via processing, and just like the plugin versions could be run directly as "pure" grass tools. Users could still create/load grass layers into projects too (as the grass provider will remain), and interact/manage them via the browser.

The only lost functionality then that I can see is that the interactive console would be dropped.

ninsbl commented 2 years ago

@nyalldawson That sounds like a very reasonable approach to me and in fact as a enhancement (and not just a loss in functionality).

@esnyder-rve I am not aware of any plan to drop the location/mapset concept (apart form discussions on terminology). That said, there are some also new features in GRASS 8 that can speedup the current processing approach quite a bit...

So a question for me is, what is the time frame for this QEP? As GRASS 8 is approaching, it might be good to coordinate, but only is schedules match I guess...

esnyder-rve commented 2 years ago

I am not aware of any plan to drop the location/mapset concept (apart form discussions on terminology). That said, there are some also new features in GRASS 8 that can speedup the current processing approach quite a bit...

Thank you for clarifying. I saw the FOSS4G 2021 GRASS progress presentation on YouTube shortly after writing that. I had thought they were dropping those concepts, but they're just cleaning up the startup process.

gioman commented 2 years ago

As GRASS 8 is approaching, it might be good to coordinate, but only is schedules match I guess

@ninsbl side question, would the GRASS project take over the management and maintenance of the GRASS plugin for the QGIS/Processing toolbox?

mlennert commented 2 years ago

As GRASS 8 is approaching, it might be good to coordinate, but only is schedules match I guess

@ninsbl side question, would the GRASS project take over the management and maintenance of the GRASS plugin for the QGIS/Processing toolbox?

Just to avoid any ambiguity here (as the ticket is about removing the plugin) could you explain what exactly you mean by "GRASS plugin for the QGIS/Processing toolbox" ? You mean the GRASS processing provider ?

gioman commented 2 years ago

Just to avoid any ambiguity here (as the ticket is about removing the plugin) could you explain what exactly you mean by "GRASS plugin for the QGIS/Processing toolbox" ? You mean the GRASS processing provider ?

@mlennert the GRASS Processing provider has been recently separated into a (core) QGIS plugin (as well as the SAGA one and OTB)

https://github.com/qgis/QGIS/tree/master/python/plugins

also because there is the plan (for QGIS 4 I think/hope) to move non native providers out of QGIS. See for example https://github.com/qgis/QGIS-Enhancement-Proposals/issues/226

This will leave up in the air who will take care of such plugins (something that will need some discussion before it happens), where the ideal scenario (in my opinion) would be the original projects take care of them.

mlennert commented 2 years ago

Thanks for the clarification @gioman. IIRC the decision at the time was that GRASS was considered sufficiently central to be maintained by the QGIS team. So this is up for discussion again ?

gioman commented 2 years ago

So this is up for discussion again ?

I'll leave the main Processing developers and maintainers to intervene here :) @alexbruy @nyalldawson

nyalldawson commented 2 years ago

IIRC the decision at the time was that GRASS was considered sufficiently central to be maintained by the QGIS team.

It hasn't been decided fully yet. I personally think GDAL + GRASS are too valuable (and are sufficiently low maintenance) to move out of the default install, but I believe @alexbruy would like to see this happen.

In the specific case of the GRASS algorithms, we've always seen a very nice steady stream of contributions from the community adding fixes and new GRASS algorithms. And that's even with the code sitting in the main QGIS repo, with all the learning curve and difficulties associated with contributing to that!

Based on this I don't think there'd be any need for the actual GRASS team to take up maintenance of this code, and have full confidence in the wider QGIS user community's ability to maintain it.

(as opposed to say the SAGA algorithms, where no-one in the QGIS user community seems interested in contributing anything aside from complaints when things break :upside_down_face: )

alexbruy commented 2 years ago

I believe @alexbruy would like to see this happen.

I fully agree that there is no sense in moving GDAL from the default install, as QGIS anyway depends on GDAL and this provider is well-tested and maintenance overhead is low.

However, I don't have strong opinion about GRASS provider. Maybe having it as a 3rd party plugin will give users and developers more freedom. I mean this way it can be updated independently from QGIS and more closely follow development of the upstream project. But pushing it out of the default install is not my goal and I have nothing against having well-maintained provider in the core. Especially now when it is already a separate plugin whose breakage will not affect Processing functionality.

In case if we decide to move GRASS out of the QGIS, I will be happy to give a hand with maintenance.

PeterPetrik commented 2 years ago

I would like to note that this proposal is only and only about the GRASS plugin. My proposition was to drop unmaintained GRASS plugin. GRASS provider, GRASS processing plugin and definitely SAGA or GDAL is out of the scope of this QEP

:)