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

[Benjamin Ducke]

One last addition to this from my side:

Since, as I mentioned, we have evaluated many of the
issues discussed in this thread in the design of the
GRASS plug-in for SEXTANTE/gvSIG CE, here are some things
you might want to take into consideration:

On 28/03/14 11:48, Paolo Cavallini wrote:
> Il 28/03/2014 08:34, Paolo Cavallini ha scritto:
> 
>> Thanks to all for the interesting comments. Obviously we have a varied
>> and rich ecosystem here, that's why I want to preserve it.
>> Obviously we all want to have all. IMHO the points are:
>>
>> * can we (GRASS+QGIS) agree on a specific course of actions?
>> * can we find the resource to implement it?
>>
>> Of course we could think of sticking with GRASS6, but I think sooner or
>> later this will be untenable (e.g. major distros will switch to GRASS7
>> once out), so better prepare now.
> 
> Quick interesting chat with Luca Delucchi and Martin Landa from GRASS
> dev team.
> One interesting option would be:
> * to add GRASS browsing capabilities in QGIS file browser

Browsing capabilities for existing GRASS mapsets would be
nice, but having the plug-in directly manipulate the data
in there leads down a difficult path (see my notes further
below).

> * to add support to direct GRASS reading (possibly writing) in
> Processing, and avoid import/export whenever possible; v.external and
> v.out.external could be used for this; this is probably the thoughest part

As far as I understand, the v.out.* modules create read-only
datasets. They also create minimal topological data structures
that are not enough for many GRASS modules (correct me if any of
these statements is no longer true). Therefore, we decided against
this path and use v.in/out.ogr instead -- with all known problems.

But r.external seems to work fine, so that at least raster I/O is
efficient enough; with the one limitation being that GRASS does not
support multi-band rasters in single files (we do not have a good
solution for working around that problem yet).

> * of course modules should be upgraded anyway
> * GRASS direct digitizing can be skipped; heavy digitizer can use GRASS
> directly

(see below)

> * keep a GRASS shell?

This only works well with the original GRASS plug-in design, not
with the one derived from SEXTANTE:

Any plug-in design that allows direct manipulation of existing
GRASS data and/or runs GRASS modules on existing mapsets is
not very compatible with the SEXTANTE/Processing on-the-fly
"import/process/export/delete temp" approach. As long as the GRASS
mapset is guaranteed to be temporary, the above chain is clean
and simple. But if you give the plug-in access to existing mapset
data, then you need a nice, thick wrapper of additional safety
checks to make sure that the final "delete" step *never* deletes
any pre-existing user data! Not only would you have to keep track
of each and every bit of data that an intermediate processing step
creates (modules that call other modules!), but also make sure
that no stale data is left in the user's mapset if processing does
not complete.

This is all very, very tricky and normally the role of the GRASS user
who knows about GRASS data management and is in full control.
I.e. if you want to make this safe, then you have to expose the GRASS
mapset and management completely to the user --> and this in turn
defeats the idea of radically simplifying the use of GRASS modules.

This is the reason why in gvSIG CE we steered clear of existing
user mapsets; our conviction being that data safety is always more
important than convenience and that advanced users can/will just run
GRASS by themselves.

Best,

Ben

> * with all the above, upgrading the plugin may probably be skipped.
> 
> Any thoughts.
> 



-- 
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  benducke at fastmail.fm