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

Mark P. Line mark at polymathix.com
Mon Jan 31 19:43:23 EST 2005


Cefn Hoile said:
>
> * 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.
>
> [snip]
>
> 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 don't know of any GIS in the world that has as one of its requirements
the ability to support a user with no prior knowledge of GIS who wants to
merge disparate spatial data sources into a commonly projected database.


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

Have you asked for help on the GRASS users list?


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

What you wanted to do was only apparently simple. When I taught GIS to
geography grad students, they would not have learned how to do what you're
wanting to do by the end of the semester, although they would have been
able to do the analysis you're envisioning if I'd provided them with a
clean database ready to go.


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

Did you ask questions on the GRASS user list along the way and fail to get
usable answers? The things you mention are very common newbie problems
that almost anybody could have helped you through.

In the greater scheme of things, I would not find it advantageous for the
GRASS development community to prioritize precious workhours on writing
tutorials for a handful of casual lay users at the expense of updating the
manpages for thousands of university and governmental researchers who use
GRASS every day in their work.

Of course, you yourself might be just the right person to write a tutorial
for users with no knowledge of GIS -- in which case you'd be more than
welcome to write and contribute it. :)


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

That doesn't sound too hard. It could be done in Python, perl, Tcl or
bash, perhaps, since it doesn't really involve any new functionality --
just a new way to get a location started.

Would you like to code it up and contribute it? Maybe there are lots of
potential users out there who would like to use a wizard like that the
first time around.


> 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 ;)

Oh. Well, there's the rub, then. :)

The GRASS development community is tiny and overworked in comparison to
the size of the software (currently a little over 400K lines of C in the
6.0.0beta1 source tree, not counting header files and ancillary source
material). Because the user base does not include very many people with no
background in GIS, most of the developers' time will almost certainly have
to be spent doing things that generate the most benefit for current users.

I understand the catch-22 situation that that implies: Unless more is done
to support walk-in users, the user base never *will* include very many of
them. It all boils down to what kinds of user GRASS was and is being
developed to support, and I think that's already been addressed several
times in this thread.


-- Mark

Mark P. Line
Polymathix
San Antonio, TX




More information about the grass-dev mailing list