[Qgis-developer] [GRASS-dev] GRASS & QGIS: the future

[Sören Gebbert]

Hi Paolo,

2014-03-27 11:18 GMT+01:00 Paolo Cavallini <cavallini at faunalia.it>:
> Hi all.
> I learned during dinner that GRASS7 RC1 is due very soon. This opens the
> issue of its functioning in QGIS. IMHO:
>
> * the qgis-grass-plugin might stop working (this has to be tested)

Yes, it will stop working, since the API in GRASS7 has changed (Raster
API functions have now "Rast_" as prefix). Besides of that must the
cmake files be modified to detect GRASS7.

> * some of the module options will be different
> * new modules will not be available in QGIS.

Yes, but this shouldn't be a problem if the module interface
description created by the GRASS modules itself was used to generate
the module interface in QGIS. New and modified modules will not work
if the interfaces are handcrafted.

> I think we can deal with this in several ways:
>
> * dropping the plugin, and concentrate the work on Processing

That is IMHO not a good idea. I think to provide the full
functionality of GRASS7 to QGIS user, this plugin should be maintained
and updated to support the new GRASS7 API. Handling and processing of
massive datasets, especially time series, is only meaningful if GRASS
is used as data storage as well. The processing interface will add
massively overhead in data processing. The temporary location/mapset
creation approach is not well suited to process massive data, even
though r.external and v.external are used to link external data
temporary into GRASS.

> * upgrading both the plugin and Processing.

Yes, that's the way to go.

>
> In the first case, we have two major issues:
>
> * upgrading Processing GRASS modules
> * changing the current Processing behaviour, avoiding the import-export
> phase when piping consecutive GRASS commands; this makes GRASS modules
> slower than the equivalent commands of other backends.
>
> While the first issue can be solved easily by a couple of people in a
> few days, the second one is more tricky, and requires hard coding skills.
> In addition, we'll no longer be able to edit GRASS vectors directly.
>
> In the second case, we'll have more work, and a not-so-nice duplication.
>
> I would like to have an open discussion on this, avoiding things to just
> happen, with the possible negative consequences.

My suggestion would be:

Full integration of the GRASS7 into QGIS via C++ or Python plugin.
This includes the temporal GIS capabilities as well.
The existing plugin is a very good start point, lots its functionality
can be reused, especially the vector editing, grass shell and map
management.

But there is a major problem with the GRASS QGIS plugin: it links
directly to the grass libraries and calls plenty of functions that can
QGIS cause to crash in case of an error. We face the same problem in
GRASS with the vector editing tools. My solution would be to use a RPC
(Remote Procedure Call) interface to calls GRASS library functions in
a remote process using binary data for inter-process communication.

IMHO the best tool for this is apache thrift[1] which allows us to
implement a RPC interface in GRASS7 to the needed library functions.
IMHO the number of RPC functions is limited since only vector editing,
raster map rendering and some map/stds management functions are needed
for direct access, all other functionality is provided by GRASS
modules.

So the first step is to implement an RPC interface in GRASS7, that
supports C/C++, Java, Python and JavaScript on the client side out of
the box. This interface can be used by the GRASS GUI itself to
implement exit safe vector editing and it can be used by QGIS and
other nice GIS desktop systems to provide GRASS database access, fast
raster rendering and vector edit functionality.

The beauty of this approach is, that the client side (the QGIS plugin
for example) do not need to link against GRASS libraries, since it
will communicate via pipes or sockets with one or several persistent
GRASS7 processes, which can be restarted in case of a fatal error. The
client side do not need to be updated in case the GRASS7 API changes
again, only the server side which will be implemented in GRASS7 must
be updated.

Implementation effort In case of the QGIS plugin:
All direct GRASS dependencies and function calls must be removed and
replaced by the client RPC solution. Hence the provider classes needs
to be rewritten, the C++ plugin code itself needs to be modified to
support the new interface datatypes that are used for inter-process
communication. Access to the temporal GIS functionality must be
implemented to list space time datasets.


What do you think about this approach?

Best regards
Soeren

[1] https://thrift.apache.org/

>
> All the best.
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev