[GRASSLIST:7501] Re: First reactions

[Hamish]

Hi Ned,


> 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.


If you have the chance, I highly recommend trying out the Mac OSX
version of GRASS prepared by Lorenzo Moretti. The installation & user
experience is as smooth as it gets. GRASS is inherently UNIX software
and it is a small miracle that it works with Windows at all. Most of the
developers use Linux, a number use the Mac, but I think only one uses
Windows.

A single click Windows install & runtime would have to contain cygwin &
all its warts. A couple of people have put together CDs containing both
GRASS and Cygwin with an install script for the whole lot. I have a
script for starting GRASS from an icon on the Windows desktop, but doing
so makes cygwin a GRASS slave.

But do try the Mac version if you have the chance. It is lightyears
ahead.


> 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

Please explain this more.


> and the process for defining a location is unnecessarily complicated.

It is designed to be explicit and reduce ambiguities down the road.
Having said that I'd love for it to be reworked into some sort of GUI
wizard with pull-down menus and things.


> 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.
[...]
> 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.

If this is all you want to do, QGIS is much better as a data viewer for
GRASS and other GIS map formats.

Granted being able to see some progress soon after you start the program
is a great hook, but it only takes a minute with Markus's or Lorenzo's
tutorials to figure out how to bring up a map. (The g.region step isn't
intuitive at first though)


> Also, dealing with EPSG codes directly is somewhat cumbersome.

But a Godsend if you already know the code. Saves you from the
unnecessarily complicated process for defining a location. It's a useful
way of bypassing the location setup if you have the code. Another trick
is to use the r.in.gdal or v.in.ogr "location" options to setup a new
location based on a geo-coded import file.

 
> I expect this location/mapset restriction is the reason it is
> necessary to restart GRASS 3 times when geocoding a scanned map.

Yup. It does tend to keep you honest and your data tidy though.


> There must be a more straightforward way to geocode images. 

gdal_translate and gdalwarp from gdal.org, which probably got installed
when you installed GRASS or OpenEV. e.g. I have written a script to do
thin plate spline rectification as a drop-in replacement for i.rectify
(i.warp -- not ready for prime time). 


> 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. 

You should have seen it nine months ago! Yikes. The GUI is still young
and is getting better rapidly. Efforts are underway that lets QGIS use
GRASS as a backend to do simple processing & GIS commands.



regards,
Hamish

ps - try the Mac version.