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

Sat May 22 11:11:57 EDT 2010

Interesting ideas. Thanks for your input on this. I hope this continues to stimulate discussion and ideas.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity 
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 	480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax:          480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On May 22, 2010, at 2:52 AM, Soeren Gebbert wrote:

> 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