[GRASSLIST:4559] Re: GRASS Marketing

[Chavoux Luyt]

Hi

Just  some comments as a newbie.

Jim Plante
<jimplante at charter.net> wrote:

> I live in the state of Tennessee, USA. At present, our state property 
> tax assessment division is embracing GIS for mapping and maintaining 
> property assessment records. Implementation deadline is 2008. Their 
> platform? Windows (ugh!) Their GIS choice? ArcView/ArcInfo ($$!!). 
> GRASS wasn't even considered, despite budget constraints at every level.
>
> In order to make inroads into this massive market, GRASS needs to be 
> more user friendly, and 7.0 seems to be a good starting point. More 
> needs to be done, though. A brand-new GIS user needs to be able to 
> download, convert, and display free data at county level. These data 
> are already freely available from USGS (DEM's & DOQ's) and the Census 
> Bureau. Inexpensive DRG and DOQQ data are readily available. I've been 
> toying (as opposed to "working") with GRASS since 5.0, and I still 
> have not had the time to "figure out" how to import TIGR data so as to 
> get the roads, as well as the street names, out of TIGR data.
>
> If you're taking guidance from OpenOffice, look at the import filters. 
> You open Writer, tell it to "Open..." an Excel or Word file, and it 
> simply does. One need not specify that the Word document is 51.34 
> pages long, contains 3000 words, 15 illustrations, and is formatted 
> for 8.5 x 11" paper. It just opens. GRASS will have to at least 
> approach this level of utility in order to take the lead in the GIS 
> field. One should need only to select Import, and aim 5.7 at a TIGR 
> file. A dialog should offer one the option to import only a few of the 
> layers (by selection) or all of them. The end user doesn't care 
> whether the data are vector or raster, and probably doesn't know the 
> difference. One should be able to point GRASS at a folder of .e00 
> files, and select the ones to import.
>
> The database connectivity should be more user friendly as well. One 
> should see the words "ODBC" and "JDBC" only under the "Advanced" tab 
> of the database selection dialog. (I know -- at present there is no 
> database selection dialog. GRASS needs one. Again, OpenOffice shows a 
> good way to approach this.)
>
> At present, the full utility and power of GRASS is available mostly to 
> those of advanced education and of comfortable familiarity with 
> programming. Someone reports a problem, and a helpful user responds 
> with, "Oh, just change the $GISBASE_CONFUSION constant to a float and 
> recompile." The questioner is entirely comfortable with the solution, 
> and gratefully implements it. To expand in popularity, you must 
> remember that most potential users of GIS at the office/clerical level 
> don't know a constant from a float, and have no clue how to recompile.
>
> The level of support for GRASS is truly astounding. I wouldn't be as 
> far along as I am (which isn't very far due to time constraints) 
> without people like Marcus Neteler and Lorenzo Moretti. For other 
> users, Hamish, Michael Barton, and others have responded to some 
> tremendously complex requests (complex to me, at least) with fixes 
> posted to CVS sometimes the same day.
>
> But to really make inroads into the GIS market, a GUI similar to 
> OpenOffice in ease of use is necessary. GRASS is so powerful that it's 
> overwhelming to a newbie. Take this question: How do I trim the 
> borders from my maps? Answer: v.patch in=thisfile, thatfile 
> out=anotherfile anotherControl=5 and many other parameters. All this 
> is transparent to the skilled *nix user, but is incomprehensible to 
> one whose experience is limited to GUI's.
>
> Why not have a menu selection that works like this: Open-->(select 
> mapset). Edit-->Zoom (set region). Edit-->Combine maps::Select 
> additional map (v.patch). Displayed map now shows two maps, joined at 
> the correct edge. Layers-->add layer::Select layer.
>
> End users should not see a command-line unless they want one--and it's 
> important that the CLI be retained as an option.  The Tcl/Tk interface 
> works, but an integrated interface is needed.
>
> Jim Plante
> <jimplante at charter.net>


1. It might be that Quantum GIS with GRASS support would  be better for 
most newbie users... I don't know because I haven't tried it yet, but 
from what I've read it looks  like an effort to make a more interactive 
GUI-based GIS.
2. I think many old-time GRASS users are unwilling to loose the power 
from bash scripting that is availble in the command-line. I kind of 
remember that a user-friendly GUI was low on the priority list from 
previous questionares about what GRASS users want in future versions. I 
think one of the reasons for this is that most GRASS users has already 
gone through the painfull process of learning the basic GRASS user 
interface. I think there are a whole bunch of GIS users who simply got 
scared off by the old CLI of GRASS and who might have become GRASS users 
if it was more user-friendly. Obviously we won't get their input if we 
asked about future priorities for GRASS. In other words: we who are 
already comfortable with the present user interface of GRASS might be 
the wrong people to ask about the priority of an integrated GUI.
3. Compared to many commercial GIS's GRASS is really powerfull! The more 
I use it the more possible uses open up. For most present users (and 
developers?) of GRASS the extension of GRASS capabilities remains the 
priority. This might still be the best road for GRASS if another project 
(e.g. Quantum GIS) would take it on themselves to create a basic, 
user-friendly and goodlooking interface to GRASS data. For simple 
mapping, import/export of different GIS formats and projections, and 
interactive selection of data (similar to Map-Info or Arc/View on 
Windows) this alternative can be used, while GRASS can be used for 
"real" GIS analysis, models, imageanalysis, database queries, map server 
etc.

Regards
Chavoux Luyt