[GRASS5] Re: [Fwd: whinging about GRASS again]

[Michael Barton]

Cefn

A lot of good ideas here. I've been pushing for a much better UI for the
past year, after using GRASS for awhile and realizing that much of its power
was unavailable to many users (as you have observed, only it was much worse,
with only half of the commands in the GUI). When I realized that I could do
something to move that along, I volunteered to do so. With major
contributions from some of the other folks on the development team (like
making all commands pop up an autogenerated GUI dialog and Radim's GRASS 5.7
display manager), I managed to get the UI from where it was with 5.0.1 to
where it is now. That is, a reasonably functional and integrated UI that
actually includes all of the GRASS commands. BUT it could be much better.
What we have now finally exposes all of GRASS to the user without accessing
the command line. This can be a jumping off point for the next generation of
UI. 

Radim is proposing to move from TclTk to QT. Others have mentioned redoing
the UI in GTK. It would be great if people with more programming expertise
than me could also be a part of this effort. Markus, Radim, and the few
others who contribute to the code that actually makes GRASS tick really have
their hands full. With additional folks working on the UI in a coordinated
way, I'm sure we could have a slicker and easier to use piece of software. I
would very much like to see this. However there needs to be some kind of
overarching vision of what actually can make a complex piece of software
like this easier to use for the people who use it on a regular basis as well
as first time users. A wizard such as you describe would be helpful and
should be doable within TclTk or another interface development environment.

Another thing that would really help everybody, but especially new
users--and can be done by non-programmers--is to improve the massive
documentation. Outside of the manual pages, much has not kept up with the
rapid changes from GRASS 5 to 6. I know that Markus is working on a new
GRASS tutorial, but there is a lot to do. I know he has asked many times for
help with the html pages docs. I've seen some suggestions go across the
list, but we need people who can actually improve the pages rather than tell
Markus how they ought to be improved. A tutorial for novices would be a
GREAT idea. I'd love to point students and colleagues to such a place and
say, 'this can get you started'. Markus added a help page to the opening
screen of GRASS that is a very basic bit of information of this sort. This
would have helped you if you knew to hit the help button at the very
beginning. Check it out and see how it can be improved and expanded. Just
some ideas.

For those who just want to display maps (including overlaying different
spatial data sets) and are unconcerned with analysis, I'd also recommend
taking a look at a few other projects that are ongoing, especially, qGIS,
Thuban, and JUMPGIS.

Cheers,
Michael

______________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


> From: Cefn Hoile <grass.itc.it at cefn.com>
> Date: Mon, 31 Jan 2005 23:39:52 +0000
> To: grass devel <grass5 at grass.itc.it>
> Subject: Re: [GRASS5] Re: [Fwd: whinging about GRASS again]
> 
> I'd like to offer my support to Russell's suggestion. I'm not going to
> get into a flame war about whether I'm properly qualified to comment,
> but just so you know where I'm coming from.
> 
> * I'm a programmer
> * I'm a naive GRASS user (a week ago I had hardly touched GIS)
> 
> Last week I set myself the project to view two GIS files overlaid one
> on the other in some rendering tool. I want to explore my local area
> for good paragliding sites. I therefore need to bring together
> elevation data, roads, and possibly land use data, and be able to
> explore a 3d map produced from these data to find south facing slopes.
> 
> After getting hold of the appropriate datasets, I looked for a long
> time on the web to find a suitable rendering tool, and NViz seemed to
> incorporate the key features. It also ran on the Mac, so I started on
> my learning curve with GRASS to get to a 3d rendering. At that stage, I
> considered GRASS to be a package, since I acquired it as a single
> collection, although I recognise the distinction, Michael.
> 
> The primary value which the GRASS toolset offers me in this respect is
> that it understands a range of standards and can translate these into
> an internal representation which is consistent. Then I should be able
> to get my DTED to work with my E00 lines describing roads, all in one
> navigable 2d or 3d rendering.
> 
> I had a lot of patience for GRASS since I could see from the tutorials
> and demonstration data sets that my preferred end result (a navigable
> 3d surface) was straightforward once you had a properly imported data
> set for GRASS to read.
> 
> Let us just say that I spent a long time messing around with it,
> reading all kinds of tutorials even before I could confirm to my
> satisfaction that the GRASS toolset could properly interpret the data I
> had, let alone render it. I still can't get the roads to render
> properly, but I now have the elevation data rendering.
> 
> Doing things which I thought were practically unambiguous (starting
> with an empty project, and attempting to import data files to populate
> it) turned out to need some secret tricks to get them to do what I
> expected.
> 
> I may in the future develop my understanding of GIS tools further. I
> work for a telco, and there is an increasing adoption of GIS for
> planning, forecasting and operations, although I am not working in
> those fields at the moment.
> 
> However, my continuing with GRASS, and discovering more about its
> power, depended crucially on me being able to do an apparently really
> simple thing, using really simple steps. My first several experiences
> suggested that it was an impossible hill to climb.
> 
> Although there are a set of simple steps to facilitate it, a lot of
> understanding of GRASS and how it was built was required to understand
> what these simple steps were. If I had been presented with a 'dummies
> new project from GIS file' process. I would have been a much happier
> user. I am now beginning to recognise the power of the underlying
> approach, but I came damn close to throwing in the towel after the 20th
> failed import.
> 
> The need to specify a region I ran headlong into, leading to lots of
> blank screens. That was of course after I worked out that a display had
> to be launched and targeted, and after checking practically every
> checkbox and text entry of every menu option to see what I could
> possibly be doing wrong.
> 
> I understand totally the importance of the composition of individual
> tools which are self-contained, efficient, and can be combined together
> to build the kind of complex GIS operations which hardball GIS users
> need.
> 
> However, I can't help thinking that some default behaviour of the UI
> tool could be made more intuitive, especially where people are
> executing operations which don't make sense for well-qualified users to
> execute at all (importing files with no intersection with your current
> region, launching a rendering when there is no display).
> 
> The question is, could a straightforward modification of the UI tool be
> made to solve this problem, without threatening the generality of the
> toolset.
> 
> How about a wizard in the main menu which takes a file and renders it,
> creating a new project with the display range drawn from the file
> itself? With a project loaded, the same wizard menu item could allow
> you to import a new file to the same project, and provide you with the
> option to either, keep the region the same, or set the region according
> to the limits of the new file.
> 
>  From there (with a well-structured initial project and mapset
> targeted), GRASS users should be able to move forward learning the full
> range of capabilities with individual operations.
> 
> I appreciate what Michael has said about there being complex
> interactions between elements, which make the suggestion to change each
> program in the toolset to add this behaviour a little too complex.
> 
> However, couldn't a dummies operation be allowed into the main menu of
> the UI tool, where those playing hardball, at worse, could ignore it.
> 
> I'm sorry not to be sufficiently familiar with GIS or GRASS to be able
> to help with building such a wizard, but maybe Russell's enthusiasm
> will propel him to build one ;)
> 
> Cefn
> http://cefn.com
> 
> 
> 
> On 31 Jan 2005, at 18:12, Mark P. Line wrote:
> 
>> MB> = Michael Barton
>> RN> = Russell Nelson
>> 
>> 
>> MB> The critical question is can GIS software be made more useable for
>> MB> people who understand GIS but are not GIS professionals?
>> 
>> There is of course an enormous sub-industry that believes that the
>> answer
>> is "yes" for at least a significant fraction of GIS functionality. It
>> generally goes under the buzzword "desktop mapping", and google will
>> find
>> lots of examples (good, bad and ugly) for anybody who's interested.
>> 
>> 
>> MB> The thing that is very annoying about displaying maps in GRASS is
>> the
>> MB> need to have a display window open prior to displaying a map.
>> MB> [snip]
>> MB> Perhaps d.vect and d.rast could be modified to check to see if a
>> window
>> MB> is open and selected, and open one if not.
>> 
>> Or alternatively, wrap a monolithic GUI around GRASS that is able to
>> run a
>> GRASS display driver against one of its internal widgets.
>> 
>> 
>> MB> However, an interface initially designed commercially to manage
>> MB> Macintosh files, word processors, and spreadsheets may not be the
>> best
>> MB> one to manage complex spatial data. Is there a better way?
>> 
>> I've always been partial to a paradigm known as "visual programming".
>> To
>> construct a dataflow (equivalent to writing a script in non-visual
>> languages), you drag little boxes onto a canvas, with each box
>> representing either a data source (like a map), a data sink (like a
>> d.rast
>> process or an output file) or a data filter (which takes one or more
>> inputs from other boxes and produces one or more outputs to other
>> boxes).
>> By dragging arrows from one box to another, you construct a dataflow
>> between the boxes. Temporary files or pipes for intermediate results
>> can
>> be handled invisibly by the visual programming engine.
>> 
>> There's a pretty solid example of a visual programming interface for
>> image
>> processing in Khoros. (It's called something else and is no longer
>> maintained by Khoral, but google will find it for you.) Googling for
>> "visual programming" or "visual programming language" will find a lot
>> about the paradigm itself.
>> 
>> Building an interface like this for GRASS would not be particularly
>> hard,
>> since most of the hairy coding is already available in libraries.
>> 
>> 
>> RN> Fifty, nobody runs GRASS on a shared machine anymore.  They just
>> RN> don't.
>> 
>> I was wondering about where to find current user demographics and
>> platform
>> seat statistics for GRASS. Where did you find them?
>> 
>> 
>> RN> The concept of GRASS is that you'll
>> RN> use shell scripts to automate GRASS.  That's silly.  Nobody writes
>> RN> shell scripts anymore unless they really really have to.
>> 
>> MB> Actually I like to do shell scripts. Perhaps I'm silly, but they
>> work
>> MB> very well.
>> 
>> Actually, I think the concept of GRASS is *not* that you'll use shell
>> scripts to automate GRASS. That was the concept in the 1980's, though.
>> Today, the concept is that you'll use any scripting language you like
>> (Python, Perl or a shell like bash) to automate GRASS if you want to
>> automate GRASS.
>> 
>> 
>> RN> It would be
>> RN> much much easier for people to learn enough Python to automate
>> GRASS,
>> RN> and present GRASS to them as Python modules.
>> 
>> MB> My understanding is that you CAN use GRASS from Python and Perl.
>> So you
>> MB> have a choice of scripting environments
>> 
>> Right. I don't know why you couldn't use GRASS from Python, perl, PHP,
>> tcl, Ruby, bash, csh, ksh or sh. (There are more masochistic options as
>> well.)
>> 
>> 
>> RN> It would work like this:
>> RN>
>> RN> from grass import r, d, v
>> RN>
>> RN> display = d.monitor()
>> RN> map = r.in.gdal("stlawrencecounty.jpg")
>> RN> schooldistricts = v.in.ogr("schooldistricts.shp")
>> RN> display.add(map)
>> RN> display.add(schooldistricts)
>> RN>
>> RN> Then you'd see, on the display, a raster map of St. Lawrence
>> County,
>> RN> overlayed by a set of vectors which are the school districts.
>> 
>> MB> Uh it is pretty easy to do this using GRASS commands in a shell
>> script,
>> MB> Perl script, or Python script. The following 5 commands (same
>> number as
>> MB> you have) in script run from within GRASS would do exactly what you
>> MB> want.
>> MB>
>> MB> r.in.gdal input=stlawrencecounty.jpg output=map
>> MB> v.in.ogr dsn=[path to schooldistricts.shp] output=schooldistricts/
>> MB> layer=schooldistricts
>> MB> d.mon x0
>> MB> d.rast map
>> MB> d.vect schooldistricts
>> 
>> If it's user-friendliness for casual, naive users that we want, then
>> clearly both examples are way too geeky. What you'd need would be
>> something like this:
>> 
>> "Show me the school districts over an image of St. Lawrence County."
>> 
>> Even this would not be undoable, if the demand was there. But like I
>> said
>> earlier and Michael has reinforced, GRASS is not really intended for
>> use
>> by naive users.
>> 
>> 
>> MB> A lot of the GRASS structure and organization is there for good
>> MB> reasons. However, other aspects have just been inherited and may
>> even
>> MB> be problematic. GRASS can definitely be improved. The changes from
>> MB> 5.0 to 6.0 are substantial and show the potential of the software.
>> 
>> Absolutely. My first involvement with GRASS was when I ported GRASS
>> 3.0 to
>> a Xenix/SCO Unix derivative, back when the Earth was still cooling.
>> Over
>> the last ten years since CERL started its go-slow, the mostly unpaid,
>> mostly volunteer, mostly overworked GRASS development community has
>> taken
>> a wooden wall telephone with a hand-cranked generator and added
>> touchtone
>> functionality and state-of-the art voice quality. (They were also able
>> to
>> lose the crank.) If there are complaints that it is not small enough to
>> fit in your shirt pocket and that it doesn't have a little LCD screen
>> for
>> displaying web pages, then I guess I have to laugh. *shrug*
>> 
>> 
>> MB> You are doing the
>> MB> right thing by offering to help making improvements to the program.
>> MB> However, you also need to get sufficiently involved in the project
>> and
>> MB> learn enough GIS in order to suggest changes that can both benefit
>> the
>> MB> existing user community and encourage new users as well.
>> 
>> In all fairness, I can empathize with Russell even though I might
>> disagree
>> about specific ideas for changing GRASS. It remains rather more
>> difficult
>> than necessary for non-GIS-techies to learn enough GIS to use the tools
>> intelligently. Part of the problem lies in the way some providers of
>> proprietary GIS attempt to sell their particular user interface
>> paradigm
>> as the be-all and end-all of GIS. This extends all the way down into
>> almost any recent GIS textbook you care to look at. When confronted
>> with
>> something that looks and works differently than the system they trained
>> on, users are often either confused or convinced that the tool has a
>> broken user interface.
>> 
>> This is a sign of the continued immaturity of the GIS industry.
>> (Compared
>> to, say, the relational database industry.) Anything we can do in the
>> GRASS community to support increasing compliance with OGR-like
>> standards
>> will have the greatest leverage that I can see towards maturation of
>> the
>> industry. (Relational database theory was academic vaporware until SQL
>> was
>> invented and implemented. The enormous intellectual output of the OGC
>> needs to be turned into software, and then evolved as necessary.)
>> 
>> 
>> RN> Finally, I (obviously) think that GRASS needs a lot of changes.  I
>> RN> realize that every GRASS user has invested substantial time in
>> RN> learning how to use GRASS.  These users will resist these changes.
>> RN> Probably most GRASS developers are, in the grand tradition of open
>> RN> source, first and foremost GRASS users.
>> RN> So my hopes of having my suggestions accepted are low.
>> 
>> First, GRASS has no grand tradition of open source in the GPL sense of
>> open source. GRASS used to be in the public domain, and has only
>> (relatively) recently been placed under open source constraints.
>> 
>> Second, I'm not really sure that most GRASS developers are first and
>> foremost GRASS users. Most of the developers I'm seeing are spending
>> way
>> too much time contributing to GRASS development to be considered
>> anything
>> other than GRASS developers.
>> 
>> Third, I'm not sure what "accepted" means in the last sentence.
>> 
>> If it means that you're concerned that your code might not find its way
>> into future releases of GRASS, then I think you can rest assured that
>> your
>> code will be evaluated on its merits. As pointed out earlier, GRASS has
>> undergone enormous change during its 20-year evolution, most of which
>> has
>> been since the withdrawal of CERL. So I see no evidence that the
>> current
>> GRASS development community is unamenable to change of any kind.
>> 
>> If it means that you're concerned that you might not get help coding
>> your
>> suggested changes, then all I can say is that your ideas would live to
>> live on the miles-long wish list and be evaluated and prioritized on
>> their
>> merits, just like all the other ideas on the wish list. The active
>> developers seem to be spread pretty thin these days.
>> 
>> 
>> RN> The last time I made similar
>> RN> suggestions several years ago, instead of people saying "yes, those
>> RN> are good suggestions", people said "if that's all you want to do,
>> RN> GRASS is the wrong package".
>> 
>> One possible reason is that if they had said "yes, those are good
>> suggestions", they would have been misleading you -- even if the
>> straight
>> answer is sometimes painful to hear. Presumably, they knew a lot more
>> about GRASS and GIS than you did, were using that experience to
>> evaluate
>> your suggestions, and were concerned about precious GRASS development
>> resources being prioritized for changes that were either not
>> thought-out
>> yet or not as urgent as other tasks on the queue.
>> 
>> 
>> RN> I agree!  If all you want to do is use
>> RN> GRASS, GRASS is the wrong package.
>> 
>> I think the point is that you should select software that does what you
>> need, not decide up front that you're going to find a way, no matter
>> how
>> circuitous, to use software XYZ to meet your needs come Hell, high
>> water
>> or the tax man.
>> 
>> 
>> RN> I think that, for GRASS to achieve a larger user base (and
>> RN> consequently larger developer base), it needs changes which will
>> piss
>> RN> off all current grass users.
>> 
>> Does GRASS need a larger user base? You're assuming that the size of
>> the
>> developer base is a function of the size of the user base. But a quick
>> check of SourceForge projects would show that it is not: Lots of
>> projects
>> have more developers than GRASS, with the same number of users as
>> developers because they're the same people.
>> 
>> GRASS does need more developers, but only to the extent that scalable
>> processes for collaboration are in place. I doubt that there is a need
>> for
>> 50 people committing to gislib.
>> 
>> 
>> RN> GRASS needs to be completely refactored into a completely different
>> RN> kind of GIS system.
>> 
>> Design it, and look for people to help you code it. What's the
>> problem? If
>> your system can compete well with the old GRASS, users will flock to
>> yours
>> in droves. (Swarm to yours in flocks? Drive to yours in trucks?)
>> 
>> If you're proposing that you need to be put in charge of a major
>> redesign
>> for GRASS 7.0, I don't think I'd hold my breath. :)
>> 
>> 
>> RN> I think that, instead
>> RN> of trying to improve GRASS, it would be better to treat GRASS as
>> the
>> RN> ruins of a GIS package, to be scavenged over for useful bits of
>> code.
>> RN> In that manner, GRASS development could continue unimpeded, while
>> the
>> RN> (insert name here) package could move forward without having to
>> worry
>> RN> about backwards compatibility with current user training.
>> 
>> It has always been the case that GRASS code has been scavenged for
>> useful
>> bits, even by the providers of very well-known commercial products.
>> 
>> What is preventing you from starting to design the (insert name here)
>> package and then building it, using pieces of GRASS or any other open
>> source code you can find as you see fit?
>> 
>> 
>> RN> Am I completely kooky here?  Am I saying anything obviously stupid?
>> 
>> There is nothing stupid at all in what you say. I just think you might
>> be
>> in the wrong venue. The GRASS development community is not going to
>> stop
>> developing GRASS, and it's not going to start evolving the design of
>> GRASS
>> to fit one person's vision -- even if that one person has decades of
>> experience in GIS.
>> 
>> So rather than trying to stop the moving train here, you might be
>> better
>> served by founding a SourceForge project for your vision and proceeding
>> with your plan.
>> 
>> 
>> RN> Is there some technical requirement for GRASS to be hard to use
>> that I
>> RN> fail to comprehend?  Does anybody else feel the same way that I do?
>> 
>> GRASS is hard to use in the same way that MySQL is hard to use. People
>> who
>> need what MySQL does and can't substitute something else for it will
>> learn
>> how to use MySQL. People who need what GRASS does and can't substitute
>> something else for it will learn how to use GRASS.
>> 
>> In any event, I don't think GRASS is hard to use. I think GRASS is
>> hard to
>> learn, just like every other GIS I've ever seen.
>> 
>> 
>> RN> Or have they all left to go work on QGIS and Thuban?  I recognize
>> that
>> RN> I'm suggesting huge amounts of work, but the reward is large as
>> well.
>> RN>
>> RN> Imagine: an open source GIS package that was both capable AND
>> usable!
>> 
>> There used to be tens of thousands of people who used GRASS every day.
>> Has
>> that dwindled to just a handful while I wasn't looking?
>> 
>> 
>> -- Mark
>> 
>> Mark P. Line
>> Polymathix
>> San Antonio, TX
>> 
>> _______________________________________________
>> grass5 mailing list
>> grass5 at grass.itc.it
>> http://grass.itc.it/mailman/listinfo/grass5
>> 
>