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

[Vaclav Petras]

Rashad, please basic description of your idea to

https://trac.osgeo.org/grass/wiki/GSoC/2014#Web-basedGUIforGRASSGIS

I also created a page to have ideas mentioned here stored in systematic way:

https://trac.osgeo.org/grass/wiki/GSoC/2014/WebGRASS

I will have limited possibilities to work on it in next days, so feel edit
or put some facts directly there. I hope that others will also join this
discussion which goes far behind the GSoC.

Vaclav


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

> Hi Vaclav,
>
> I think that the web UI has to be based on the GRASS library and has to
> not depend on WxWidgets or any other Desktop gui toolkit like JavaFX.
> g.parser is enough to describe the modules interface and can be used to
> automatize the build of the module form for any modules. I got your idea of
> running the same on desktop, web, embedded platforms which is theoretically
> possible but the run into deadend from time to timeas they are started for
> desktop application.
>
> Qt has webkit interface, like you said for JavaFX ( i dont know much about
> the java). The philosophy of a desktop gui toolkit is entirely different
> from a web application ui. For example message passing or Qt signals/slots
> can't be used directly. Infact these people have a different implementation
> and interpretation of signal and slot when used in web.
> It is because people had written QtWebkit, Broadway with the same idea in
> mind as you, now it possible to run these. But they can't used in a many of
> application sucessfully. For example, rendering a map on Qt and web browser
> cant be same. We have WMS, WMTS etc.. for rendering imagery and WFS for
> vector data for this reason. We can't use the everywhere used GDAL for web
> easily. Boradway or JavaFX and other friends is very much feasible for some
> projects but not all.
>
> For this idea i envision the web gui app based on :
> - mapset-location wizard
> - map canvas
> - toolbar with:
>   pan, query
>   zoom in/out/bbox to-layer to-region
> - menu bar with same layout of grass desktop
>
> Here you can use GDAL, you are not obliged to use WPS, WMS, WFS to deal
> with your data. of course you can. None will fix the data used by web
> application and you could just give a try without evening compiling etc..
> (these are some view on webgrass we both saying).
>
> Regarding the reuse of code. I am planning to use python bindings for wt
> and core classes will be reused. for parsing description file and the
> instead of sending boradway or JavaFX etc.. I will use directly a jquery
> dialog, html button, text and will have direct access to js code such that
> if i need to render a grass vector i could do it in openlayers or using wt
> itself to read the grass vector directly using gdal and draw polygons on a
> HTML5Canvas, SVG, etc..  I could use render module of grass ui to render a
> ppm or use pygrass numpy to read grass and render as before.
>
> For  Sharing data is one thing i need to think about and having a "shared
> location" like share folders could be explored.
>
> For GRASS 3D. its not possible to use opengl on web. you must use webgl.
> and I dont think the previous GTK broadway could use opengl.
>
> Also GRASS is famous for large data processing and i was exploring that
> too.  So the webUI must be behave differently when dealing with large data
> and should allow you to queue any process. Just thinking for now.
>
> And the whole idea of having webgrass will help users and developers as
> stefan was mentioning to run them on university or a company network
> without caring of operating system and Wt support Windows, Linux, OS X
> among other embedded platforms.
>
> The demo video of android was from 2012 and since then Wt improved Android
> support. In 2012 there was not automated apk. But when I checked in 2013 wt
> build system if configured for android will generate an apk for your
> application.
>
> I would ask you to think webUI as a wrapper like python, java etc.. You
> can have two gui for GRASS GIS. Remember about grass6.3 and earlier version
> which uses tcl/tk and was not used now because lack of support and or
> functionality and I am never saying Wxwidgets is not lacking a
> functionality for a desktop platform but on web perspective i think it is.
> Am I right?
>
>
> On Thu, Mar 6, 2014 at 8:42 PM, Vaclav Petras <wenzeslaus at gmail.com>wrote:
>
>>
>> On Thu, Mar 6, 2014 at 1:38 PM, epi <massimodisasha at gmail.com> wrote:
>>
>>> At the moment i’m having so much fun with IPython Notebook
>>> that is my actually my grass interface ... in this idea i can see a
>>> little room for it too :)
>>>
>>
>> IPython Notebook would be the clear choice of Python command console for
>> a web GUI written from scratch. Similarly, OpenLayers or Leaflet could
>> become a web GRASS GUI map display. The downside of things such as GTK+
>> Broadway is that these solutions are simply not available. Although they
>> can be always used inside some web view. With this we are getting to the
>> other option I was mentioning: web-based GUI used in a web view(s) on
>> desktop. This would allow us to use all highly interactive Java Script
>> visualization libraries on desktop.
>>
>> http://wxpython.org/Phoenix/docs/html/html2.WebView.html
>>
>
>
>
> --
> Regards,
>    Rashad
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20140306/04163a4f/attachment.html>