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

Thu Mar 6 11:34:47 PST 2014

Hi Stefan.

On Thu, Mar 6, 2014 at 12:45 PM, Blumentrath, Stefan <
Stefan.Blumentrath at nina.no> wrote:

>  Hi Rashad and Vaclav,
>
>
>
> If you allow me a user comment:
>

User comments are not only allowed but they are needed.

> 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.
>

ssh -X, VNC etc. are of course always here, so the question is home much
more we will get from other solutions.

> 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).
>

So, it seems that you want the full fully-featured GUI, not just some basic
one.

> 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)).
>

This is what I was mentioning in other email. There could be different
requirements on data management, especially sharing, in the online
environment.

>
>
> 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)…
>

>From quick check RSStudio is written in Java. E.g. the new Java GUI
framework JavaFX allows to create desktop and web (probably client-server)
application at once. Unfortunately, nor wxPython/wxWidgets or Qt (or its
Python friends) does not allow this by themselves. JavaFX is not really an
option for use, however the concept is what I would like to have. The GUI
with the same look and (I believe) the same implementation on all desktops
and also on web.

https://www.rstudio.com/ide/screenshots/ (first four screenshots)

 The main advantage is (from my point of view) that users do not have to
> install additional software…
>

So, web-based solution is necessary for that. Which e.g. kills my
suggestion of wxGUI executing commands on server.

Thanks for your input, if you have more, please do.

Vaclav

>
> 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>
> 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 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>
> 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
> 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/4a5aa4ce/attachment-0001.html>