[GRASSLIST:7497] Re: First reactions

[David Finlayson]

I am all for GUIs on things I use infrequently or where I just don't
want to spend weeks learning how they work. Let an expert set things
up and I will take their advise. I wouldn't use Linux, for example, 
if it didn't have GUIs for things like printer and network
configuration, firewalls, etc. But in my area of expertise I want a
command line, I want full control. I AM the expert.

I think the division of QGIS and GRASS falls neatly into that
paradigm. If you are a casual GIS user, don't want to invest two weeks
into a program just to make a map. Use QGIS, that's what it's for. If,
on the other hand, you need to crunch gigabytes of complicated spatial
data, use GRASS. That's what it's for. The GUI/CLI debate is really
about meeting the needs of the casual vs hard-core users. Nobody is
hard-core about everything, but then again no one is causal about
everything either.

My 2 cents.

David












On 7/7/05, Martin Wegmann <wegmann at biozentrum.uni-wuerzburg.de> wrote:
> Hello Ned,
> 
> thanks for your commendations, critics, proposals. It is indeed very helpful
> to get to know the first impression because many users/developers are already
> used to command-line & certain structures of GRASS which are entirely
> incomprehensible for new users.
> 
> On Thursday 07 July 2005 18:42, you wrote:
> [...]
> >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.
> 
> I totally agree!
> Installing GRASS on linux is quit easy, but for Windows an *.exe file is
> missing. I am not familiar with the software-build problems, but as far as I
> am aware of it, it is a license problem. Somebody has to pursue the exe-build
> program. Please correct me if I am wrong.
> 
> [...]
> > 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.[...]
> 
> > 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.
> 
> Of course it is possible to enter a previously setup mapset and choose import
> a raster into a newly generated one. However I fancy your proposal that the
> user should be able to choose to look at the image first (r.in.gdal + d.mon
> x0 + d.rast XY) without entering a location/mapset followed by an "generate
> location/mapset"  for the respective raster.
> 
> I don't know how easy it is to accomplish this "wish" but to zoom in and just
> select a subset for import might be very interesting as well.
> 
> For other quick-looks tasks I would recommend QGIS.
> 
> > 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.
> 
> the d.m tcltk interface brings a pretty intuitive menu structure to GRASS
> (compared to the former one) but to produce real "eye candy" a e.g. QT4 UI
> project should be initialised.
> Perhaps we should announce that we are looking for motivated OpenSource qt
> programmer. ,-)
> 
> > 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.
> 
> Event though I am already used to r.mapcalc and love how it works, a
> calculator-like interface would lower the learning curve.
> 
> > 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.
> 
> Especially a recurring series of tasks is easily accomplished by GRASS using a
> script - just mail if I shall send you an example script.
> 
> I think the most important thing GRASS needs are programmers who start helping
> on solving bugs, wishes -- hopefully GRASS will attract them as well.
> 
> best regards, Martin
> 
> 
> --
> Martin Wegmann
> 
> DLR - German Aerospace Center
> German Remote Sensing Data Center
> @
> Dept.of Geography
> Remote Sensing and Biodiversity Unit
> University of Wuerzburg
> Am Hubland
> 97074 Würzburg
> 
> phone: +49-(0)931 - 888 4797
> fax:   +49-(0)931 - 888 4961
> http://www.biota-africa.org
> http://www.biogis.de
> 
> 


-- 
David Finlayson
Marine Geology & Geophysics
School of Oceanography
Box 357940
University of Washington
Seattle, WA  98195-7940
USA

Office: Marine Sciences Building, Room 112
Phone: (206) 616-9407
Web: http://students.washington.edu/dfinlays