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

[Rashad M]

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