[GRASS-dev] Some ideas about future GRASS interface development

Sat May 22 05:52:05 EDT 2010

Hello Michael,
i would like to add my 2c. More below

2010/5/11 Michael Barton <michael.barton at asu.edu>:
> I'll start a thread on this. If there is enough interest, we should move it
> to the WIKI. If not, it can quietly fade away.
> Last month, I was at the AAG (a first for me) in sessions talking about
> advanced geospatial and other modeling, and jointly with Helena in a session
> on advances in open source tools for GI Science. Seeing some of the papers
> and talking with participants set me to thinking again about GUI concepts.
> I've tried to advocate for thinking outside the standard model in designing
> interfaces for GIS. Granted that it is difficult to get too cutting edge
> when we are all "avocational" developers away from our real jobs or studies.
> In spite of this (or perhaps because of it), I think we've done a good job
> so far in creating a flexible and very useable interface to a very
> complicated piece of software. Most people I show GRASS to are very
> impressed--and they are comparing it to the commercial market leader that
> pays a lot of money for software development. If we have such a great
> interface--and one that we've only developed to a point of stability in the
> past year--why should we think about something different.
> The reason is that the nature of computing is changing rapidly, and some of
> the changes are especially relevant for spatial technology. I've always felt
> that the normal windows/menus interface (and typing commands) is not really
> an appropriate design for software that is intended to manipulate, analyze,
> and display multidimensional geospatial data--but I've had only had a
> somewhat vague idea of what might be better. At the same time, the idea of
> ubiquitous computing and combining data from multiple sources over the
> internet is becoming a reality. The latter is especially important as
> internet-based repositories of complex geospatial data continue to grow.
> This brief intro leads me to toss out a couple of rather different ideas for
> comment. Think of them as GRASS 8 and beyond concepts.
> 1. GRASS was originally designed to access data from multiple sources and
> server. However, for most people, GRASS now lives on individual computers
> and accesses data there. But new tools in GRASS are changing that. There are
> of course initial tools to access WMS data. More interesting is Glynn's
> proposal to access all data through an r.external/v.external type interface
> linked to gdal. If we go that way, GRASS becomes much more flexible,
> accessing data wherever it is located accessible to a workstation. Some
> people still want to use GRASS remotely, but have considerable difficulty
> running our very nice GUI in that way--a GUI that is designed to run on a
> user's local computer.
> So we might want to think about making GRASS run in a browser for some
> future version. I see some kind of synergy between the kind of interface
> created by software like OpenLayers or MapServer and the data accessing
> capabilities of Glynn's idea--maybe also incorporating WMS and other such
> internet data. This might help to make GRASS transparently portable across
> all computing platforms, and reduce the amount of GUI development work
> needed for cross-platform compatibility. It also would open the possibility
> of making GRASS accessible via cloud computing.
> I don't know how we do this, but the fact that some kind of interface is
> doable in a browser via OpenLayers, MapServer, and other such internet
> mapping tools, means that this is possible. We'd need to develop a more
> sophisticated interface than is now available on existing internet mapping
> software, but the tools to do this exist and it may be worth considering.

The easiest way to make GIS GRASS available as geo-data processing
backend for many users is by supporting WPS. This approach allows the
use of GRASS functionality by any desktop GIS application on MacOS,
Windows or Linux  which supports WPS (ie: uDig, OpenJump with WPS
plugins from 52n [1] and Qgis 1.4 via WPS Python plugin from Horst
Düster[2]) or any Web framework supporting WPS.
Some of them support the download and visuailzation of WMS, WFS and
WCS data directly, so WCS and WFS data can be used as GRASS module
inputs and the results can be displayed together with WMS and WFS
data.
Hence a wide range of more or less sophisticated GUI's will be
available to access GIS GRASS functionality over WPS.

I.e.: PyWPS is available for many years to enable GIS GRASS as WPS backend.

Making GRASS easier to integrate in other existing and future WPS
server is an ongoing project of mine. I develop currently the
integration of GRASS in ZOO-WPS server and support the 52n WPS
integration.

One important step was the generation of WPS XML process description
documents by lib/gis/parser for grass7. So for any GRASS module a
valid and usable WPS XML process description can be generated.
The second important step is to provide a frame-work to start GRASS
modules without the need to care about location generation, import and
export of external data and cleaning up. This is done by the
GrassModuleStarter [3]. The r.external approach is used to minimize
the import effort and speeds up the processing.

If the module starter is usable and stable, i would like to put it
into GRASS svn. Additional dependencies may be PyXB [4] for easy XML
parsing. An example how to convert GRASS WPS XML into YAML using PyXB
is available here [5].

The WPS approach is the best way to enable cloud computing with GRASS.
I currently experiment with GRASS, ZOO-WPS, Amazon EC2 and ubuntu
images in this direction.

I will of course inform the GRASS community in case meaningful results
are available. :)

IMHO GRASS should play an important role as WPS backend.

Best regards
Soeren

References:
[1] http://52north.org/maven/project-sites/wps/52n-wps-site/

[2] http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/ZOO_WPS_Grass_integration_with_Qgis_WPS_client.png

[3] http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/WPS/GrassModuleStarter.py

[4] http://pyxb.sourceforge.net/

[5] http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/WPS/ZOO_Project/GrassXMLtoYAML.py