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 <[email protected]>: >> 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 _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
