[GRASS-dev] GRASS & QGIS: the future

Thu Mar 27 11:28:41 PDT 2014

Hi,
This approach is pretty to what the IPython developers implemented with their HTM5+JS interface to the IPython Kernel. (IPython Notebook) 

As RPC interface, IPython is using pyzmq (based on zeromq).

IPython has a already a QtConsole with “inline plot”  that can easily replace the Qgis python shell.
This will give us inline plot to implement the ,missed d.*  capabilities of grass 5.* and 6.* 
as well as direct call to grass commands (in IPython any system call can be performed using the  prefix “!”)
and  using the “!” prefix or the %%BASH magic we can call any grass module, if the GRASS envs are properly exported.

I’m on a mac osx 64 bit, is almost 3 years i can not use grass GUI because of the WxPython interface that doesn’t support 64 bit on osx, 
and i found in this approach the only way to let me use GRASS in a productive way(now that tcltk is removed)

Recent development in IPYthon enabled the ability to build  complex widget based on query or othe r JS libs  thanks to the “interact-widget” API 

I was planning to reuse part of this technologies for the WebGRASS interface, mixing IPython and PyWT.

I’m catching a fight right now, this video is almost “old” but shows how the widget interact API works :

http://www.frequency.com/video/ipython-attributes-ofsoftware-how-they/135236136/-/5-1851523

 i like the RPC approach, and i guess we can reuse the ipython sw to implement this capabilities.

please apologize me if i went OFF topic ..

Massimo.

On Mar 27, 2014, at 11:17 AM, Sören Gebbert <soerengebbert at googlemail.com> wrote:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20140327/4b048ab8/attachment-0001.html>