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

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.

  1. An alternative way to think about interfaces comes from conceptually melding of the kind of tactile interfaces that Helena and others have been experimenting with <http://skagit.meas.ncsu.edu/~helena/wrriwork/tangis/tangis.html> and the kind of interface that has caught on in a big way with Apple’s iPad and iPhone. The idea is that it is much more versatile and “intuitive” (if geospatial analysis can be intuitive) to be manipulating virtual landscapes and multidimensional data in a tactile/visual way than via a more standard computer interface. Imagine if you could put your hands into the screen with nviz, change the data, add and subtract layers by dragging them into or out of the view, grab a piece to analyze in any dimension, etc. I think that this kind of interface foresees the future of human-computer interaction, but is especially significant for the kind of high dimensional data and visual displays that we deal with in a GIS. While I don’t suggest that we redirect our efforts into creating a GRASS app (not that it wouldn’t be a bad idea for a future SOC project), but we might want to keep a close watch on the development of this new kind of tactile interface and see how we can incorporate it into a GIS setting in the future.

OK. I’ll stop there, but am curious what you all think about this. A final question. Should we send this to the user list too or keep it in the dev list for the moment?

Cheers
Michael


C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

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

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

2010/5/11 Michael Barton <michael.barton@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. :slight_smile:

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

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@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. :slight_smile:

IMHO GRASS should play an important role as WPS backend.

Best regards
Soeren

References:
[1] MavenHome < Documentation < Wiki

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

[3] Google Code Archive - Long-term storage for Google Code Project Hosting.

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

[5] Google Code Archive - Long-term storage for Google Code Project Hosting.