Hi
Just some comments as a newbie.
Jim Plante
<jimplante@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@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