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

[Cefn Hoile]

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
>