Hi Paolo, 2014-03-27 11:18 GMT+01:00 Paolo Cavallini <[email protected]>: > 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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/grass-dev _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
