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

[Vaclav Petras]

On Thu, Mar 6, 2014 at 12:12 PM, Rashad M <mohammedrashadkm at gmail.com>
 wrote:

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

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

You need to use Python to really reuse the classes. And do also a large
refactoring of wxGUI code to make them reusable (although some improvements
were already made). How much you can reuse? How much you want to reuse?
This is probably hard to answer, easier might be which functionality do we
want in web GUI? Only modules and map visualization? Or also digitizers,
animations, map swipe, ...?

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.


This is what previously mentioned GTK+ Broadway is doing. I'm not sure how
does this compare to Ulteo and to whatever rollapp.com is using. noVNC is
VNC where client runs in web browser. The advantage of these is that you
don't write any new GUI code.

https://developer.gnome.org/gtk3/stable/gtk-broadway.html
http://blogs.gnome.org/alexl/2012/12/27/broadway-multi-process-suppor/
http://kolyakosenko.wordpress.com/2013/07/18/wxwidgets-2-9-5/
https://www.youtube.com/watch?v=P6lzZpS5M4g

http://en.wikipedia.org/wiki/Ulteo_Open_Virtual_Desktop
http://www.ulteo.com/
http://kanaka.github.io/noVNC/
https://www.youtube.com/watch?v=ZiIxtoHa9bU (rollapp.com)


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

I though that the goal is to have something like Google Docs but for GIS.
Which could be provided by GRASS community but more importantly, everyone
would be able to setup his or her own server. I'm not concern about license
of data, in terms of security, I'm concern about users accidentally
deleting each other data or somebody running some evil processes on my
server. And in terms of usability, some data upload/download functions are
needed, management, ideally also sharing and perhaps publishing through web
services by forwarding then to some map server.

On Thu, Mar 6, 2014 at 12:12 PM, Rashad M <mohammedrashadkm at gmail.com>
 wrote:

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

How much code are these applications? I somewhere accessible? How much
development was in Wt since than? Some improvements, e.g. for Android?


>> 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 hope too but my point is that we should do it the right way this time
because now it is really needed. For some things like improvements of
modules, I'm not concerned. It will prevail once it is in the source code,
module is needed, improvement is needed, this is clear. But we can create a
web GUI and it will be forgotten or superseded by something better in few
years. For example, Gimp was not writing a web based GUI but now I can use
Gimp on web using rollapp.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20140306/8b544ceb/attachment.html>