Greetings,
I am fairly new to the GRASS list so I apologize if much of what I write has
been discussed in the past.
I recently had a renewed interest to evaluate GRASS as a remote sensing
and/or GIS tool to support our initiative to promote the use of open source
geospatial tools in conservation applications. Following are a few initial
reactions. Much of what I wrote is based on my thoughts after going through
the excellent tutorial that Markus Neteler prepared for the Open Source
Geospatial Conference recently held in Minneapolis, MN USA.
Up until this point I have been throwing most of my support behind a program
called OpenEV, primarily because it is easy to use and it handles most of
the basic visualization tasks quite well. As of GRASS version 6 I am more
seriously look at GRASS as an alternative or perhaps a compliment to OpenEV.
If I do get more involved with the GRASS community I would try to contribute
tutorials and perhaps even some software development help where needed. I
expect it will take a while for me to get a sense of who is doing what with
regard to GRASS development and where our efforts could best fit in.
I want to preface these comments by saying that they are heavily influenced
by my perception of our target audience. This audience is largely limited to
using Windows computers and the individuals' remote sensing and GIS skills
and interests are quite varied. Our intent is to provide something that
appeals to everyone, not just the "hard-core" geospatial crowd. Here are
some initial comments.
To start with, the installation goes much smoother than it used to but using
Cygwin is not an optimal solution to running GRASS on a PC. Windows users
want a look and feel that is similar to their other programs. Even
navigating for a file can be a chore for a Windows user. Using a phone modem
the installation process takes hours or days if a stable connection cannot
be maintained. Windows users want an installation that they can double-click
on and then the installation proceeds without problems. I find it easier to
run GRASS within Linux (on a Linux only computer) and that is the setup I am
using. Most of our users, however, would not want to deal with Linux.
Starting GRASS still brings up the "Data Selection" window. I find the
database / location / mapset structure to be restrictive. The benefit is
that everything is neat and tidy but there seems to be significant time and
disk space overhead and the process for defining a location is unnecessarily
complicated. Another drawback is that it is not possible to simply start
grass then open and immediately explore an image. If all image work was
based on a geographically defined area this approach might be acceptable but
for those instances (frequent for me) when you want to load an image and do
some simple processing the whole database/location framework is a pain.
Also, dealing with EPSG codes directly is somewhat cumbersome.
I expect this location/mapset restriction is the reason it is necessary to
restart GRASS 3 times when geocoding a scanned map. There must be a more
straightforward way to geocode images.
If GRASS would allow you to start the application, click on File => Open and
then have an image open in a viewer so a user could zoom, pan, read
coordinates, change bands. the interest in GRASS would increase by a factor
of 10 or more overnight. A user should not need to read a tutorial to simply
display an image of their choice. I am convinced that this instant appeal is
a critical hook to get more people interested in GRASS. The majority of
users aren't interested in the breadth of functionality offered by GRASS and
even if they are, if the most basic features are not easy to do they will
loose interest before they get into the "good" stuff. At the Open Source
Geospatial Conference Markus gave an impress presentation on GRASS 6 and
most of the people I spoke to were quite impressed. My concern is that when
those people go home and start GRASS they will be frustrated and may not
pursue it further.
Maybe the link with QGIS will fix some of this - it's hard to tell. There
was also some mention of combining some of the capabilities of GRASS with
the image processing capabilities of OSSIM. This merging of strengths would
be fantastic if indeed it is feasible. OSSIM appears to be using a state of
the art raster processing engine and GRASS had broad raster and growing
vector capabilities. I am very interested to know if anyone is following up
with this.
I realize that much of the power of GRASS is accessible through the command
line but for many people if this functionality is not available through an
intuitive menu structure then it is effectively not available.
One feature that I think would be quite useful is to add a calculator GUI to
the current map algebra option. The current r.mapcalculator work fine but in
my experience a GUI that resembles a calculator is more intuitive to use.
All in all I think GRASS has come a long way and I expect that I will begin
using it in some of our remote sensing training courses in the future. First
I need to become more proficient and knowledgeable with what GRASS can do
and how to efficiently accomplish a series of tasks.
I'll hold off additional, more specific comments until later. If anyone has
any comments or insight regarding what I wrote I would like to hear from
you.
All the best,
Ned
--
RS/GIS Program Manager
Center for Biodiversity and Conservation
American Museum of Natural History
Central Park West @ 79th St
New York, NY 10024
e-mail: horning@amnh.org
tel: 212-313-7947
fax: 212-769-5292
Home office tel: 802-382-9080
Web site: http://cbc.rs-gis.amnh.org/