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 bendu...@fastmail.fm _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev