[GRASS-dev] GSoC 2014: GRAS GIS Web UI

Thu Mar 6 09:45:27 PST 2014

Hi Rashad and Vaclav,

If you allow me a user comment: The video looks very, very promoising.
In our institution we are running GRASS on an Ubuntu Server which users access graphically either through either TightVNC or CYGWin-X. What I like about the Server solution is the "work where your data is" concept (even if server ressources may be smaller when shared by several users, compared to modern single user desktop PCs). I also perceive GRASS`s  mapset concept as very useful for multi-user environment and data sharing (maybe except for the ownership check which hampers usage of mapsets by groups of people (I know there are workarounds (e.g. goup users as owners or overriding the ownership check in GRASS 7)).

On the same Server we also have an RStudio-Server running which would be comparable to your webGRASS-solution.
Our experience with RStudio Server is very positive, so I would appreciate such a solution for GRASS (though TightVNC and CYGWin-X are fine too)...
The main advantage is (from my point of view) that users do not have to install additional software...

Cheers
Stefan

From: grass-dev-bounces at lists.osgeo.org [mailto:grass-dev-bounces at lists.osgeo.org] On Behalf Of Rashad M
Sent: 6. mars 2014 18:12
To: Vaclav Petras
Cc: grass-dev at lists.osgeo.org
Subject: Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI

Hi Vaclav,

On Thu, Mar 6, 2014 at 5:08 PM, Vaclav Petras <wenzeslaus at gmail.com<mailto:wenzeslaus at gmail.com>> wrote:
Hi Rashad,

web GRASS is certainly something we need and I'm very excited about that. But there are several things which should be considered to make this project successful.

First, there is already one (desktop) GUI. Do we want to have (an maintain) another GUI? Is there a possibility to share the code between the desktop and web GUI?  What about limiting the functionality of the web GUI to minimum, so that there will not much code to maintain and (as defined) nothing to add?

This is the rather important part and we do want to reuse the code from core classes.

Second, if we would decide to go the way of the full GUI (which resembles current wxGUI), wouldn't be better to use something like GTK+ GDK Broadway (1) to just reuse the desktop GUI on web, or to reuse web GUI on desktop (some web view or browser with local web pages and processes)? Although GTK+ and some wxWidgets applications can run with Broadway backend, wxPython, and especially GRASS is still far from running that way. However, there are some (perhaps even more interesting) alternatives such as Ulteo and noVNC. And I'm wondering what rollapp.com<http://rollapp.com> is using.

I am interested to use Wt, not because of C++ and its recent Python love, because the idea of Widget centric, security of Wt apps (very much safe than any other web framework), embedded platform support.  and so on. The main idea behind the birth of Wt is they want a web application to run on Web browser and embedded platforms (Android and others). The code is written in python or C++, webserver (Wthttp) renders a bunch of AJAX code and compatible with any recent browsers and it takes care of the some browser related stuff like special css prop for webkit and mozilla. And of course there is no code conversion or generation from a c++ to html/js script. Indeed I am allowed to use as much as javascript code. In the demo you can see openlayers widget!

When you write:

WButton *button = new WButton();

Wt makes the css for Wbutton which it has and provide a very decent and easy access to render it on browsers. I would rather stop here talking about Wt before it turn into a name drop of the toolkit which I dont want to do.

Third, the GUI is not the only part. The GUI is supposed to be a part of some server/cloud infrastructure. You need to upload data, sign in users... And also we are not sure what are the security issues of using GRASS on server with unlimited access (i.e. you can run anything you want as opposed to predefined processes in WPS).

IIUC, you mean security of the data right?. WebGRASS project is not about providing server infrastructure to preserve the data. Of course it wont allow to get other users data and in my plan users will have access to their own location rather than anyone can use everyone's data. And sensitivity of data uploaded is a question and you never publish such kind of data under NDA or so in public server right? And you cant access a data on server even when you render it on browser screen. That is what mapserver, Openlayers and other web map viewer are doing.

Fourth, the processing on server could be also invoked from a desktop GUI. This would require user to install the desktop GUI but the processing part would be placed on server. This is just another option.

I am not clear with this. Why do you need to invoke a desktop interface for running a webapp. I did had a the demo version running on server with no X server.

Fifth, the choice of the GUI framework is important. We don't want to tight this to some project which will not be here in few years. Wt has nice examples and your (Rashad's) experience is big plus. But there is many others such as Dabo and some of them might be better for us since they are using Python, so we could share some code with wxGUI. Results on mobile platforms must be evaluated, too.

There has been a python binding for Wt and myself and massmio had tried these successfully. The support for bindings are not much, I would say but I had a pretty much idea about how its generated which BTW is not using swig and SIP. Regarding mobile platforms I do had a working apk of another Wt application for which I got a recording on youtube[1] (offline android).  [2] is the web version. The patch required for me was very minimal as Wt compiles clean on Android. [1] also used libgdal (Android). This one just renders a shapefile and style it without OpenLayers or its friends

And finally, a sustainability of the new web GUI must be considered. What will happen after the GSoC? There already were several GRASS web interfaces starting with GRASSLinks in 1995 and also we have some web sites using GRASS in background but they are not general GRASS GUI (e.g. http://www.gapserve.ncsu.edu/segap/segap/). Minimizing duplication with the desktop GUI seems crucial and merging this to GRASS and developing other infrastructure, too.

Of course sustainability is considered and I was hoping it would last forever and becoming a good addition to GRASS GIS as previous year's GSoC projects.

I don't want you to feel overwhelmed by all of these considerations but I was thinking about this topic for some time, so I collected some ideas and now is the time to share them.

[1] https://www.youtube.com/watch?v=7giSheeVgnM  (on emulator)
[2] https://www.youtube.com/watch?v=v7jtsJXPhXU

Vaclav

PS: I just saw your video, congratulations, it looks good and responsive. Is the code somewhere online?

On Thu, Mar 6, 2014 at 4:28 AM, Rashad M <mohammedrashadkm at gmail.com<mailto:mohammedrashadkm at gmail.com>> wrote:
Hello All,

I would like to check with grass-devs about the possibility of having a web version of GRASS GIS as a part of SoC 2014. I had done some behind the scenes work for web version using C++ web toolkit Wt[1]. This involves running a grass modules online just like you do on Desktop with a UI that resembles that of wxGUI. I had been in touch with one of my juniors in my lab and he is interested to work on it. I could mentor this project as I had experience with Wt, GRASS and GSoC. I hope this web version will be very useful in both users and developers.

Comments and suggestions are most welcomed.

[1] http://www.webtoolkit.eu/wt

--
Regards,
   Rashad

_______________________________________________
grass-dev mailing list
grass-dev at lists.osgeo.org<mailto:grass-dev at lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
Regards,
   Rashad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20140306/3d679938/attachment-0001.html>