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
