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

Thu Mar 6 09:12:05 PST 2014

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/e580cc1d/attachment.html>